Running NI-DAQmx with RedHat Enterprise 6.x

[ksteege]

Our end goal is to be able to use the NI PCI-4461 boards with Red Hat Enterprise 6.x (preferably 6.2), which is proving to be a challenge.

The NI-DAQmx Base 3.6 drivers claim to support Red Hat 6.0 (which I'd infer as having a good shot at working with 6.2), while the NI-DAQmx 8.0.2 drivers claim to only support Red Hat 5.0.

Unfortunately for us, NI states that the PCI-4461 board is NOT supported by the Base 3.6 driver, only the 8.0.2 driver, which would imply we're stuck with RHEL 5.0 if we want to use these boards.

However, I tried installing the 8.0.2 driver on a RHEL 6.0 system, and it appeared to install with no errors.  But without an actual board we really can’t determine if this means we could successfully use the board on the RHEL 6.0 system.

Has anyone tried running the 8.0.2 driver on RHEL 6, or tried running the PCI-4461 boards with the Base 3.6 driver?  Any suggestions on what will, might, or won't work?

Thanks in advance!

[JoeFriedchicken]

ksteege wrote:

However, I tried installing the 8.0.2 driver on a RHEL 6.0 system, and it appeared to install with no errors.  But without an actual board we really can’t determine if this means we could successfully use the board on the RHEL 6.0 system.

Has anyone tried running the 8.0.2 driver on RHEL 6, or tried running the PCI-4461 boards with the Base 3.6 driver?  Any suggestions on what will, might, or won't work?

As long as the system has the build-time dependencies installed, I would expect an installation to succeed when the system has no NI hardware. Once hardware has been installed and put to work, you may find kernel oops messages or experience other unpredictable run-time behavior.

There is a howto document in this group [1] that explains how to configure a RHEL 6.x system for use with DAQmx 8.0.2. You can also find some technical history in the NI forums [2] about why DAQmx stopped supporting RHEL at version 6.

My recommendation is to evaluate the PCI-4461 with RHEL 6.2 under your deployment conditions. If it meets your requirements, then you should expect reliable operation. If it doesn't meet your requirements, I would change distributions to openSUSE 12.1 and install NI-KAL 2.3.1 [3] before installing DAQmx 8.0.2 and re-evaluate the configuration.

[1] How to install DAQmx 8.0.2 and LabVIEW 2011 under RHEL (CentOS) 6

https://decibel.ni.com/content/docs/DOC-22110

[2] 8k kernel stack prevents overflow

http://forums.ni.com/t5/Multifunction-DAQ/DAQmxBase-Acquiring-at-high-frequency/m-p/781433#M43258

[3] NI-KAL 2.3.1

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

[ksteege]

Thanks Joe for the tips.  We just received the first of our PCI-4461 boards to try out.  I installed the 8.0.2 driver on a CentOS system, and after modifying the grub.config to limit the memory to 4 GB (as per your instructions in [1]), it seems to successfully recognize the board.  I'm not sure yet if we can live with a 4 GB limitation, as our system needs to keep a tremendous amound of FFT'ed data available in system memory for immediate user recall, but I'll worry about that later.

I'm trying to find some examples or user's guides of how to use the 8.0.2 driver with this board, and I'm striking out.  I've tried some of the examples that get installed but none seem to work successfully with this board.  Is there any such guide that explains the API in detail, or working examples for this board (something simple like reading one ADC channel and dumping the data to a file)?

Thanks again for your help!
Kevin

[JoeFriedchicken]

Hi Kevin,

I'm glad to hear that you were able to install the driver. Just to make sure it has detected your card, does nilsdev report it?

ksteege wrote:

I'm trying to find some examples or user's guides of how to use the 8.0.2 driver with this board, and I'm striking out.  I've tried some of the examples that get installed but none seem to work successfully with this board.  Is there any such guide that explains the API in detail, or working examples for this board (something simple like reading one ADC channel and dumping the data to a file)?

I would expect the majority of the analog input examples to work correctly. Which have you tried, and what error messages did they report?

As far as examples or user's guides, there is some information available for the C API, but it's not as complete as the LabVIEW API. Here are a few bookmarks to make:

• Using NI-DAQmx in Text Based Programming Environments

http://www.ni.com/white-paper/5409/en

This is a high-level summary of the DAQmx API, and it explains each section of an example.

• Tasks in NI-DAQmx

http://zone.ni.com/reference/en-XX/help/370466V-01/TOC9.htm

This is a link into the DAQmx online reference for tasks, which is the fundamental unit of work for a device. A task describes the set of input channels and their settings as well as timing and trigger settings that should be used during an acquisition.

• NI PCI-4461 Supported Properties

http://zone.ni.com/reference/en-XX/help/370471W-01/cdaqmxsupp/pci-4461

This is also a link into the DAQmx online reference and describes the specific properties of a task that apply to the 4461.

These last two should be installed on your system as well -- /usr/local/natinst/nidaqmx/docs

[ksteege]

Thanks again Joe for your help.   A few more questions :

(1) Back to the 4 gig limit on the kernel memory for RHEL6.  Does this mean that if I were to use RHEL5 with a PAE kernel, and the system has 8 GB total memory, I would run into the same problem?  Or would the NI-DAQmx work on RHEL5 with a PAE kernel and more than 4 gigs?

(2) When I run nilsdev I get

NI PCI-4461: "Dev1"

(3) The first document you listed, "Using NI-DAQmx in Text Based Programming Environments", seems to provide a glimpse into what I need to do.  It appears very similar to one example I have been playing with :

/usr/local/natinst/nidaqmx/examples/ansi_c/AnalogIn/MeasureVoltage/Acq-IntClk-AnlgStart/Acq-IntClk-AnlgStart.c

When I compile and run this program, I get :

./Acq-IntClk-AnlgStart

DAQmx Error: An attempt has been made to use an invalid analog trigger source.

If you explicitly named the virtual channel using DAQmx Create Channel, you must use the name assigned to that channel.

Property: DAQmx_AnlgEdge_StartTrig_Src

Corresponding Value: APFI0

Task Name: _unnamedTask<0>

Status Code: -200265

End of program, press Enter key to quit

(4) There's gotta be some document that describes the API.  For example, it appears the example program doesn't like the call to :

DAQmxErrChk (DAQmxCfgAnlgEdgeStartTrig(taskHandle,"APFI0",DAQmx_Val_Rising,1.0));

What's the description of this function?  What does the 2nd paramter, which appears to be a char *, mean?  What other values can I pass in?  Without this description, I would be stuck having to reverse engineer the API from the examples and header files, and I highly doubt a company would require its customers to do this.  Isn't there a reference guide somewhere that describes these function calls along with their parameters?

What I need to do is to continusouly read 4 channels of analog input at a specific sample rate (thus our need for 2 boards),  process the data, and write analog output to 2 channels.   So it looks like this is the right example to build upon (at least for the reading analog data part).

[BEGIN EDIT]

I found the complete C reference guide - its referenced at almost the very last line of the 700+ line readme file.  This will help a lot.  But is there some document that shows how to put the functions together in a cohesive manner to accomplish a task?  I've caught glimpses of this in examples in other documents, but haven't found one document that explains what functions (and in what order) are needed to, say, read an analog channel.

Also, I tried changing the example above so that the 2nd parameter of the DAQmxCfgAnlgEdgeStartTrig call is NULL to indicate to use the internal clock reference, but still get the same error!  And how does it decide which of the 2 channels on the board to use?

[END EDIT]

Thanks again for any help you can provide,

Kevin.

[JoeFriedchicken]

ksteege wrote:

(1) Back to the 4 gig limit on the kernel memory for RHEL6.  Does this mean that if I were to use RHEL5 with a PAE kernel, and the system has 8 GB total memory, I would run into the same problem?  Or would the NI-DAQmx work on RHEL5 with a PAE kernel and more than 4 gigs?

I have some bad news for you on this front. The NI kernel modules won't even load if they detect any RAM with addresses higher than 4 GB. This has an even more surprising side effect: suppose you have a PAE kernel and 3 GB of memory on a 64-bit main board. It is still possible that the NI kernel modules will refuse to load. This can happen because the system BIOS may choose map regions of memory above 4 GB. The Linux kernel will accept that map, the NI kernel modules will see memory with high addresses, and they will refuse to load.

My recommendation for you is to use TCP sockets or some other means to send the data from the measurement machine to another one with a 64-bit kernel and memory to match.

(3) The first document you listed, "Using NI-DAQmx in Text Based Programming Environments", seems to provide a glimpse into what I need to do.  It appears very similar to one example I have been playing with :

/usr/local/natinst/nidaqmx/examples/ansi_c/AnalogIn/MeasureVoltage/Acq-IntClk-An lgStart/Acq-IntClk-AnlgStart.c

This example assumes the device being used is a multifunction device (60xx, 62xx, 63xx). The error message says that the example is using an incorrect analog edge start trigger source -- APFI0. The 4461 does not have this terminal and instead is capable of directly triggering from one of the channels in the task. You might try searching for "APFI0" in the example file and replacing it with "/Dev1/ai0".

But is there some document that shows how to put the functions together in a cohesive manner to accomplish a task?  I've caught glimpses of this in examples in other documents, but haven't found one document that explains what functions (and in what order) are needed to, say, read an analog channel.

For the most part, the second link in my previous post is that document. The summary is: create channels, configure timing, configure triggering, start, read, stop, clear.

1. DAQmxCreateAIVoltageChan(...)
2. DAQmxCfgSampClkTiming(...)
3. Choose one:
   • Analog edge start trigger: DAQmxCfgAnlgEdgeStartTrig(...)
   • Digital edge start trigger: DAQmxCfgDigEdgeStartTrig(...)
   • Immediate trigger when the task is started: (none)
4. DAQmxStartTask(...)
5. Loop: DAQmxReadAnalogF64(...)
6. DAQmxStopTask(...)
7. DAQmxClearTask(...)

The examples follow this order, and your only work is to decide which hardware properties you need to configure and then make the corresponding call. To determine which properties are supported by the 4461, use my third link.

[ksteege]

Thanks Joe - I was able to successfully read data from both analog input channels continuously.  We are getting a second board since I need to read 4 channels of analog input - I assume the second board will be /Dev2/ai0 and /Dev2/ai1?

We also need to write 2 channels of analog output - sometimes a waveform as short as 8 ms or as long as 9 seconds, and sometimes output a continuous tone (or output continuous random noise).  I looked at the examples in AnalogOut/GenerateVoltage, and they seem to either :

(1) output a waveform, continusouly repeating the input buffer supplied by the programmer

(2) output a waveform and then stop

(3) output data with timing controlled by the programmer

I guess I was expecting to see an example something like :

Set up output channel (with output sample rate)

repeat

  Write one batch of data to the DAC buffer #1

  Wait until DAC buffer #2 is emptied

  Write one batch of data to the DAC buffer #2

  Wait until DAC buffer #1 is emptied

end

I'm assuming then that's not the way the driver works?  From the examples, it seems that I need to configure the task for either finite or continuous samples, start the task, and then stop the task when finished, and repeat each time I need to output something - is that the way it works? 

[JoeFriedchicken]

ksteege wrote:

I assume the second board will be /Dev2/ai0 and /Dev2/ai1?

Yes. You can also give your own names using the nidaqmxconfig command line utility [1].

I'm assuming then that's not the way the driver works?  From the examples, it seems that I need to configure the task for either finite or continuous samples, start the task, and then stop the task when finished, and repeat each time I need to output something - is that the way it works? 

For this device, you're right. There are devices in the 54xx series that have hardware-preloaded waveform switching based on software or digital trigger events. For the 4461, though, I see two strategies:

1. Use a single task and configure it for continuous generation. Your application will have to keep feeding waveform data to it. If you need to generate silence, you'll need to send samples that represent a flat signal.
2. Use a finite task for each signal you need to generate. You can configure them and unreserve them to have a task "cache". When it's time to use a waveform, start the task of interest. When it is time to switch, unreserve the finished task, and start the new task of interest. Unreserving is necessary because the driver will reserve hardware resources (like the DACs or sample clock) and prevent other tasks from referencing them.

If you're doing hard or soft real-time control, you'll need to measure the jitter for each of these. The first will have a delay between signals as you wait for the hardware's FIFO to empty. The second will have a delay as you wait for the driver to reprogram the hardware.

At this point, you're past the initial setup/startup hurdles and are beginning to write your application logic. I suspect you'll have a wider audience in the NI forums -- http://forums.ni.com/t5/Dynamic-Signal-Acquisition/bd-p/100 I'm happy to continue helping, but as the focus is changing from Linux to domain expertise, I'll get out of my depth pretty quickly.

[1] Using nidaqmxconfig for NI-DAQmx 8 for Linux

http://www.ni.com/white-paper/4620/en

[ksteege]

Joe -

   Making progress thanks to your help.  A couple more items :

(1) My application can acquire data in 3 ways - from the 4461 board, from a data file, or by internally generating random noise plus a couple signals.  For the latter two, the 4461 board is not needed (and no NI-DAQmx calls are made at all during run time).  In addition to running on the target hardware, I'd like to be able to run the final application in one of these modes on a system that doesn't have a 4461 board and doesn't have the NI-DAQmx package installed.  I tried copying the .so libraries and executable to another computer, but got an error :

libnipalu.so failed to initialize.  Perhaps you need to run updateNIDrivers.

Is it pretty much impossible to run an application compiled with the NI drivers on a system that doesn't have an official NI-DAQmx installation, even if no runtime calls are made to the library?  I've done this with other hardware components, but I understand if its just not possible with the NI drivers.

(2) I'm probably now getting into the realm of the other NI forum you listed above, and will repost this question there if you think that would be best.  But here goes :

I have been able to output various waveforms and tones to the analog output building on some of the example programs.  Our application needs to output a waveform immediately (or AIAP - as immediately as possible) when some event happens.  I looked at your recommendations above, and my understanding on your #1 is that the waveform timing would be under application software control, which is just not fine enough to maintain a precise frequency, and I can't do #2 because there are virtually an infinite number of waveforms we might transmit. 

I've built a test program that does the following :

DAQmxCreateTask

DAQmxCreateAOVoltageChan

while (1)

  <Get next waveform information>

  <Create next waveform to transmit>

  DAQmxCfgSampClkTiming (FiniteSamps for a single waveform, ContSamps for a tone)

  DAQmxWriteAnalogF64 <writing the waveform created above>

  DAQmxTaskControl (Reserve)

  DAQmxTaskControl (Commit)

  <Wait for start transmit event>

  DAQmxTaskControl (Start) or DAQmxStartTask, which I believe do the same thing

  <Wait for end transmit event>

  DAQmxStopTask

end while

My questions are then :

A. Does this approach seem reasonable, or am I overlooking a different set of functions?

B. The call to DAQmxTaskControl always seems to take about 17 milliseconds.  It then seems to take an additional 3 milliseconds before the waveform starts transmitting (measuring on a scope consistantly shows about 20 ms between the transmit event and the beginning of the output waveform).  Is this expected?  Is there any way I can speed this up?  We're hoping to be less than 5 milliseconds.

C. The very first sample of the next waveform appears to be the last sample of the previously transmitted waveform.  Is this a known flaw, or am I doing something wrong?  Is there any call available to completely clear out the DAC output buffer? 

Let me know if this is more appropriate for a new topic in the forum you linked to above and I'll repost it there.

Thanks,

Kevin.

[JoeFriedchicken]

ksteege wrote:

(1) My application can acquire data in 3 ways - from the 4461 board, from a data file, or by internally generating random noise plus a couple signals.  For the latter two, the 4461 board is not needed (and no NI-DAQmx calls are made at all during run time).  In addition to running on the target hardware, I'd like to be able to run the final application in one of these modes on a system that doesn't have a 4461 board and doesn't have the NI-DAQmx package installed.  I tried copying the .so libraries and executable to another computer, but got an error :

libnipalu.so failed to initialize.  Perhaps you need to run updateNIDrivers.

Is it pretty much impossible to run an application compiled with the NI drivers on a system that doesn't have an official NI-DAQmx installation, even if no runtime calls are made to the library?  I've done this with other hardware components, but I understand if its just not possible with the NI drivers.

It sounds like you're getting into the Linux dynamic linker, ldd, realm -- it should be possible for your application to request DAQmx entry points without requiring them to be linkable at compile or at load time. In other words, there are ways to compile the application such that until the DAQmx API is called, the library isn't loaded; otherwise, it wouldn't be dynamic 😉 Of course, for a system that has DAQmx installed, some OS delay will be introduced as the library is looked-up, loaded, and then called.

Unfortunately, copying the NI-DAQmx shared object files is not sufficient. To create an end-user application, you will also need to create an installer that provides the kernel-level modules as well as the user-level libraries.

From your description, my understanding is that you're creating your analog output response on-the-fly -- in other words, you cannot pre-create the entire set of possible output waveforms upon application start.

(2) I'm probably now getting into the realm of the other NI forum you listed above, and will repost this question there if you think that would be best.  But here goes :

I have been able to output various waveforms and tones to the analog output building on some of the example programs.  Our application needs to output a waveform immediately (or AIAP - as immediately as possible) when some event happens.  I looked at your recommendations above, and my understanding on your #1 is that the waveform timing would be under application software control, which is just not fine enough to maintain a precise frequency, and I can't do #2 because there are virtually an infinite number of waveforms we might transmit. 

I've built a test program that does the following :

DAQmxCreateTask

DAQmxCreateAOVoltageChan

while (1)

  <Get next waveform information>

  <Create next waveform to transmit>

  DAQmxCfgSampClkTiming (FiniteSamps for a single waveform, ContSamps for a tone)

  DAQmxWriteAnalogF64 <writing the waveform created above>

  DAQmxTaskControl (Reserve)

  DAQmxTaskControl (Commit)

  <Wait for start transmit event>

  DAQmxTaskControl (Start) or DAQmxStartTask, which I believe do the same thing

  <Wait for end transmit event>

  DAQmxStopTask

end while

My questions are then :

A. Does this approach seem reasonable, or am I overlooking a different set of functions?

For the hardware you have chosen, I am unaware of another algorithm that will give you the behavior that you desire. Since you cannot calculate the response waveforms before the applications begins, determining the output at run-time appears to be the only option. Once you know the waveform you want generate, create the task, write to it, and start it.

I believe you should be able to create the next task while a generation is on-going, prime the new task, then stop the current generation, and start the new output.

B. The call to DAQmxTaskControl always seems to take about 17 milliseconds.  It then seems to take an additional 3 milliseconds before the waveform starts transmitting (measuring on a scope consistantly shows about 20 ms between the transmit event and the beginning of the output waveform).  Is this expected?  Is there any way I can speed this up?  We're hoping to be less than 5 milliseconds.

I haven't measured the individual time between each DAQmx task state transition, but I know that creation, reserve, and start typically take the most time: task creation because it needs to allocate memory; task reservation because it needs to lock resources in the kernel; and starting because it needs to access and program hardware.

C. The very first sample of the next waveform appears to be the last sample of the previously transmitted waveform.  Is this a known flaw, or am I doing something wrong?  Is there any call available to completely clear out the DAC output buffer? 

It sounds like the device is regenerating the last sample sent to the hardware. This is typically the expected behavior for analog output -- when the waveform ends, the DAC remains at the last sent code. You can configure the device to report an error when it completes generating the last sample sent to it.

I suspect you'll get more help if you post in the main forums for DSA hardware.

Ultimately, in my individual opinion, it sounds like you're trying to write real-time responses on an operating system that cannot guarantee a deterministic response, regardless of the underlying hardware driver or kernel. If that is the case, you might consider LabVIEW RT. which can measure the system jitter and provide programmatic constructs for guaranteeing run-time updates.