From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

M Series code for Labview

I am using the PXI-6230 on Linux.  I downloaded the MHDDK for NI-Visa, and the code uses C, along with some examples that are in C.  There are some good examples, but I need working code that will work in Labview.  Are there some examples that people have for the PXI-6230?  Or is there some way I can use the C code for Labview?  Any help is appreciated.

 

Thanks,

Thomas Pham

0 Kudos
Message 1 of 7
(6,905 Views)

Hi Thomas,

The DDK is a set of reference examples for writing a device driver from scratch. Since most write-it-yourselfers expect to be running in an uncommon environment (where LabVIEW cannot run) or need to undergo some kind of final validation or peer review (where not everyone may have LabVIEW available), a text-based implementation provides them a faster "see how it works" starting point for those purposes.

When programming for the 6230 from LabVIEW, you have a few options available.

  1. You can use the existing C++ chip objects in the DDK but manipulate them into a shared library (a .so) so that you can call the Library Function Node in LabVIEW [1].
  2. You can use the register I/O palette [2] in VISA and transcribe the C++ chip objects into LabVIEW.
  3. Expand the DAQmx Base driver [3] to make the extra RLP calls for the 623x (explained below).

All three are somewhat challenging, and you will also need some additional information about the specifics of programming for the 623x sub-family. Since they have isolated IO, some of the registers are re-purposed for enabling and disabling the isolators. There are several threads in this forum [4] about the 623x-specific calls that need to be made.

 

If you choose to exapand the DAQmx Base driver, you will find that a bug in the code will make the system think your 6230 is a 6222 [5]. In addition the 623x-specific RLP calls, you'll need to correct and differentiate the 6230 from the other M Series boards.

[1] Call Library Function Node -- LabVIEW Help
http://zone.ni.com/reference/en-XX/help/371361G-01/glang/call_library_function/

[2] Register Access Functions -- VISA Help
http://zone.ni.com/reference/en-XX/help/371361G-01/lvinstio/high_level_reg_acc_func/

 

[3] DAQmx Base 3.4 for Linux

http://joule.ni.com/nidu/cds/view/p/id/2128/lang/en

 

[4] 623x RLP Considerations
http://forums.ni.com/t5/forums/searchpage/tab/message?location=Node%3A90&q=623x#message-list

 

[5] DAQmx Base 3.4 incorrectly attaches to the 6230

http://decibel.ni.com/content/message/20827#20827

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 2 of 7
(6,896 Views)

Thanks for the reply Joe.  Seems like it won't be one easy task.  Here is what I've done so far.  In the beginning, I used high level register programming, and then use some low level register programming.  I'm unsure if this code is working cause I get no errors, but does this look good so far?

 

0 Kudos
Message 3 of 7
(6,885 Views)

More or less, that's the idea.

It looks like you're associating with a PXI-6528 (PID 0x7086) but your comments have the correct PID for the PXI-6230 (0x7177). Also, if you read the comments in osiUserCode.cpp, you'll see that VISA only allows one session for each BAR segment and that the DDK opens another session for BAR1.

The DDK maps the BAR0 and BAR1 PXI segments so that it can assign user-mode addresses to the C++ chip objects. However, you should be able to directly peek and poke using BAR1 as the base and the register offsets as the offsets once you initialize the MITE as you've done. You are of course welcome to map them in LabVIEW, but it's just an extra step of indirection.

One other suggestion I have is to make strict type defs for the register addresses and field enumerations, that will make reading and debugging the code a lot easier.

DMA will be another beast to battle, but I would say a reasonable first goal is to get software-timed digital reads and writes working. That is the simplest IO operation the board can perform. Remember to read the 6230-specific threads here when you start 😉

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 4 of 7
(6,880 Views)

Hi Joe,

 

I have started on my project and created some subvis to handle how the classes write to the registers.  I have some questions that are placed in comments section.  If you are able to answer some of my questions, that'll be great.  One question I have listed is the Gen_PWM class, which I'm unsure where I should be writing these to.  Another question, are all the registers being reset to 0 during initialization?  If softcopy is 0, then I'm assuming the registers should be set at 0 in the beginning.  Another question is, should we be reading the register to save the softcopy before the write? 

Download All
0 Kudos
Message 5 of 7
(6,785 Views)

here are some other files

Download All
0 Kudos
Message 6 of 7
(6,784 Views)

one more file

0 Kudos
Message 7 of 7
(6,783 Views)