RHEL 5 - DAQmx or DAQmx Base

[SyamCR]

Hello

We're starting off development of technical software involving data acquisition and digial/analog IO with Ni products. We use Red Hat Enterprise Linux Workstation 5.3 (32 bit) as our OS and we use multi-threaded programming with C++ (pthreads / Qt).

I hope DAQmx 8.0.1 with recently released NI-KAL 2.0 will work fine on RHEL 5.3, though I'm yet to begin actual testing.

I'd like to ask if this is the right way to move forward. Is there anything like DAQmx on Linux being obsolete/abandoned and DAQmx Base alone will be maintained in the future?

Any information/help is highly appreciated.

Thanks

[JoeFriedchicken]

If you're doing multi-threaded DAQ programming (where multiple threads make calls to DAQ hardware), then your only option is DAQmx 8.0.1 [1]. DAQmx Base [2], by comparison, is single threaded, which means only one thread can make calls to the hardware (but other threads can process the data).

If you're doing USB DAQ measurements, then your only option is DAQmx Base. DAQmx, by comparison, is PCI(e) and PXI(e) only and does not support any USB DAQ devices.

NI-KAL 2.0 supports RHEL 5.3 [3] (and you should install it before DAQmx if you choose this driver), but DAQmx expects the kernel to have an 8kB stack. RedHat sets its kernels to have a 4kB stack, and DAQmx can cause a kernel panic under certain situations and hardware (which I don't have available). So, if you choose to use DAQmx 8.0.1, rebuild your kernel with an 8kB stack or test to paranoia the default 4kB stack for your specific application. If you choose to use DAQmx Base, then no custom modifications are required: the driver works within the smaller 4kB kernel stack.

[1] NI-DAQmx 8.0.1

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

[2] NI-DAQmx 3.4 readme

http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmxbase/3.4/Linux/README.txt

[3] NI-KAL 2.0 readme

http://ftp.ni.com/support/softlib/kal/2.0/README.txt

Joe

[SyamCR]

Thanks a lot Joe.

One more doubt. Can DAQmx and DAQmx Base co-exist on a computer? i.,e. could I use DAQmx for my add-on cards and use DAQmx Base for USB devices.

NI-KAL 2.0 supports RHEL 5.3 [3] (and you should install it before DAQmx if you choose this driver), but DAQmx expects the kernel to have an 8kB stack. RedHat sets its kernels to have a 4kB stack, and DAQmx can cause a kernel panic under certain situations and hardware (which I don't have available).

So, if you choose to use DAQmx 8.0.1, rebuild your kernel with an 8kB stack or test to paranoia the default 4kB stack for your specific application.

An initial reading of this: http://kerneltrap.org/Linux/Defaulting_To_4K_Stacks tells me that a 4K stack size is not really a bad thing and the choice is by design. Is it true that I run the risk of over-flowing it only if I have an elaborate nfsd-over-xfs-over-raid setup or have ndiswrapper?

[mhoogend]

Short answer is yes, it was chosen by design, but there isn't really a consensus in the community.  There is the discussion that you linked to, and that the mainline vanilla kernel doesn't have 4k as the default size.  Red Hat Enterprise Linux is the only distribution that I'm aware of that has gone with the 4k stack (and those based on it).

Over-flowing the stack is exactly the problem you will run into with more complex drivers.  DAQmx does a lot more for you as a consumer of the driver to make it easier to program NI boards.  Depending on your use-case that complexity can over-flow the stack.

[SyamCR]

Thanks for all the info.

Couple of months back, I had installed DAQmx on RHEL 5 successfully and verified presence of a 6034 board with nilsdev. But recently, I plugged in a 6528 board. If I remember right, I re-installed NIKAL2.0  and DAQmx 8.0.1. Now, nilsdev is not showing anything.

I tried uninstalling and reinstalling everything. But no luck. Ni488 works, though.

I now have both 6034 and 6528 and they are both shown in lspci, but not in nilsdev. Any idea on how to resolve this?

[JoeFriedchicken]

Yes, DAQmx and DAQmx Base can coexist on a system with little or no extra configuration.

Moving to your device detection problem, does the 6034 return to nilsdev when you remove the 6528? Does the 6528 show up when it's the lone DAQ device? What does dmesg say in regards to NI hardware/drivers?

Joe

[SyamCR]

I haven't experimented with removing and adding cards. Will do that today and post the results here. Looking at dmesg, I see one 'nikal license taints kernel' message and one other 'missing symbol' line. I'll post the exact message today. Anyway, all modules seem to be loaded fine.

Apart from running the UNINSTALL scripts, (after stopping services and doing rmmod), what's the best way to completely uninstall DAQmx and NIKAL?

[SyamCR]

One more doubt.. where does NI-VISA fit in this scheme? Is this package required for using DAQmx with PCI add-on cards? If it is, what's the order in which these packages are to be installed?

Thanks a ton for your help..

[JoeFriedchicken]

SyamCR wrote:

Apart from running the UNINSTALL scripts, (after stopping services and doing rmmod), what's the best way to completely uninstall DAQmx and NIKAL?

The UNINSTALL scripts will do all the work.

DAQmx Base will prompt you whether or not it should also uninstall NI-VISA. Answering yes to that prompt will not only pull VISA, but also its underlying components (NI-KAL and friends). You can verify this by looking at the uninstallPackageList variable near the top of the script.

DAQmx, on the other hand, completely uninstalls itself and its underlying components without prompts when you run its UNINSTALL script. It also has an uninstallPackageList variable near the top of its script.

[JoeFriedchicken]

SyamCR wrote:

where does NI-VISA fit in this scheme? Is this package required for using DAQmx with PCI add-on cards? If it is, what's the order in which these packages are to be installed?

NI-VISA is not required for controlling PCI/PXI cards with DAQmx. DAQmx supplies its own interface to the DAQ hardware. Installation order isn't important, but my habit is to install NI-DAQmx, then NI-DAQmx Base.