Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

RTAI Linux and NI-DAQmx Base

Hi,

is it possible to use the NI-DAQmx Base C API software from a realtime linux system such as RTAI or a there problems to be expected ?

Thanks for any advice!


Best regards
Peter
0 Kudos
Message 1 of 10
(6,989 Views)
We cannot garantee that it will be working without problems because at NI we did not do any tests with this distribution yet.
Ingo Schumacher
Systems Engineering Manager CEERNational Instruments Germany
0 Kudos
Message 2 of 10
(6,979 Views)
Any update on this. I asked my postdoc to purchase a NI PCI-6229 to use with RTAI but after seeing this had him hold off. Without some encouragement, I guess I'll confine myself to the list in http://www.comedi.org/hardware.html

0 Kudos
Message 3 of 10
(6,807 Views)
Actually, there is an update on this, since we recently released NI-DAQmx for Linux. The usage of this driver with C should be a lot easier and more performant than DAQmx Base.
Nevertheless, this driver is not tested on every distribution.

National Instruments supports the following distributions and versions of Linux:

  • Mandrakelinux 10.0 Official
  • Mandrakelinux 10.1 Official
  • Red Hat Enterprise Linux WS 3
  • SUSE LINUX Professional 9.1
  • SUSE LINUX Professional 9.2
This support is provided for 32-bit, x86 platforms only. With the exception of Red Hat Enterprise Linux WS 3, National Instruments Linux support is restricted to the 2.6 kernel.

More information and the download can be found here.
Ingo Schumacher
Systems Engineering Manager CEERNational Instruments Germany
0 Kudos
Message 4 of 10
(6,795 Views)
Thanks. That sounds very promising. My only remaining worry is that I presume the NIDAQ800_RedHat.iso file does not contain the driver source so I (and future users) have to rely on driver robustness in the presence of linux variants. A little context may help. I support an open source simulation program that is widely used in the computational neuroscience community (http://www.neuron.yale.edu) and has also occasionally been used in experiments to do something called the "dynamic clamp". Basically, every time step (down to 25 microseconds), experimental cell voltage is read by an ADC, and that becomes a forcing function to a computer simulation which produces a current which is fed back to the cell as a current.  My experimental colleague, who has been using NEURON on mswin 2000 as a dynamic clamp for several years, tells me that it seems impossible to do good realtime with mswin xp and hence the switch to rtai linux. My experimental real time linux system consists of the 2.6.10 kernel patched with the rtai-3.2 /hal-linux-2.6.10-i386-r9.patch and configured starting with  what I just happened to have on my existing linux (/boot/config-2.6.12-1.1372_FC3) (I've never built the linux kernel before so I really am shaky about what I'm doing) with only the few rtai recommended changes.
NEURON runs as a user space program (it is very large and double precision is heavily used) with the LXRT api.  Everything is working fine so far and I assume a driver cannot be tested without purchasing a card. I know there are people out there who know instantly whether I am hurtleing toward a brick wall or can assure me there is light at the end of the tunnel. A word from the wise is MUCH appreciated.
0 Kudos
Message 5 of 10
(6,782 Views)
My suggestion would be to download and install the NI-DAQ 8.0 driver from the web. If the installation goes smoothly then the chances of the hardware working are very high. In most cases customers run into problems during installation when things don't work. If you can get the drivers to install with out any errors then I would go on ahead with the purchase. If you get a lot of errors during the installation then you may want to try another approach.

-Josh
0 Kudos
Message 6 of 10
(6,777 Views)
Installation of NIDAQ800_RedHat on RTAI patched 2.6.10 kernel was successful.
But now it seems the brick wall is much closer. I just read an RTAI page: "Realtime scheduling in userspace is a great advantage, but for most applications, the realtime constraint comes from interaction with hardware, with the outer world. It is not possible to use the linux device driver model from a hard realtime LXRT thread (but it is possible from soft or non realtime threads). You need to / extend/ LXRT in order to access kernel device drivers."  The page this came from,
http://people.mech.kuleuven.be/~psoetens/portingtolxrt.html
goes on to explain how to call device driver functions from user space without doing a system call (ioctl). But I assume ioctl is the only documented access to the NIDAQ drivers. From another direction, I've been reading about user space device drivers that seems a very elegant technology, e.g. http://www.schleef.org/ where usddk is:
"User-space Driver Development Kit
=================================
This package is a kernel module and library combination that allows one to easily create device drivers for PCI devices that operate from a user-space task.  There are a number of advantages in this approach, especially clean separation from the kernel and kernel space, both for crash protection and licensing issues.  It also can be much easier to debug a user-space driver.  Disadvantages are mainly due to user-space drivers being significantly different than the normal behavior of drivers -- no means to use other kernel resources or other kernel interfaces."

Of course, then I'm back to register level programming. But that might not be too bad since all I need is buffered DAC,ADC,DIO channels and a clock.
Is a register level manual available for the NI PCI-6229?



0 Kudos
Message 7 of 10
(6,761 Views)

http://sine.ni.com/nips/cds/view/p/lang/en/nid/11737 

Just click Download the Measurement Hardware DDK link.

-Josh

0 Kudos
Message 8 of 10
(6,745 Views)
What was the outcome of this discussion? Were you able to get the NI-DAQmx Base C API to function with RTAI?
0 Kudos
Message 9 of 10
(5,188 Views)
It's possible that the DAQmx Base driver may run on an RT-enhanced kernel, but the driver itself won't be deterministic. The architecture of the driver is primarily programmed I/O -- only analog input uses interrupts for DMA transfers -- and so it can't be confined with hard deadlines.

The DDK Josh linked to above is the best way to support RT on Linux.
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 10 of 10
(5,152 Views)