NIDAQmx on Fedora Core 5 How-To

[ninevoltz]

Oops, I was wrong. The modules do load ok on this new kernel and seem to work ok too. I forgot to reboot with the new kernel before I ran updateNIDrivers

[ninevoltz]

I wrote a shell script yesterday that will speed up the kernel updating process, I am attaching it here along with the fully modified nikal.c.

[ninevoltz]

From the last Fedora Core 5 kernel release "feature-removal-schedule.txt":
Long story short, NIDAQmx will break in 2008.

What:    USB driver API moves to EXPORT_SYMBOL_GPL
When:    Febuary 2008
Files:    include/linux/usb.h, drivers/usb/core/driver.c
Why:    The USB subsystem has changed a lot over time, and it has been
    possible to create userspace USB drivers using usbfs/libusb/gadgetfs
    that operate as fast as the USB bus allows.  Because of this, the USB
    subsystem will not be allowing closed source kernel drivers to
    register with it, after this grace period is over.  If anyone needs
    any help in converting their closed source drivers over to use the
    userspace filesystems, please contact the
    linux-usb-devel@lists.sourceforge.net mailing list, and the developers
    there will be glad to help you out.
Who:    Greg Kroah-Hartman <gregkh@suse.de>

[Shawn B.]

Actually, NI-DAQmx 8.0 does not provide USB support so it won't break in 2008.  NI-DAQmx Base 2.1 currently provides support for USB DAQ devices, and it does it entirely in userspace, so it will continue to work after these changes.

Currently the only NI drivers that use the USB API in the kernel is our NI-488.2 driver for our USB-GPIB devices (The messages you see in the kernel logs come from NI-KAL which is a shared component).  We are of course aware of the changes that will go into the kernel in 2008 and will use this "grace period" to evaluate our alternatives in future USB drivers for Linux.

Shawn B
National Instruments

[ninevoltz]

Just updated to Fedora Core 6 today. NIDAQmx still works ok with kernel 2.6.18-1.2798.fc6.

Just out of curiosity, when can we expect the next update of NIDAQmx for Linux?

Thanks,

John

[Neil_S.]

John,

Thanks for posting to the NI forums.  We are always evaluating the possibility of releasing newer versions of our drivers on various platforms.  However, no definite timetable is available.  This timetable is directly affected by both the technical effort that is required for the upgrade as well as the demand for the driver.  Let us know if you have any additional questions.

Regards,

Neil S.
Applications Engineer
National Instruments

[jbailey]

I am working on a real-time motor control project and am using a PCIe-6259 card for DAQ.  The current setup is a Linux PC running FC5 with a 2.6.15 kernel modified per the instructions found in this thread.

We are trying to use the NI-DAQmx version 8 driver to read encoder data, however, we seem to be unable to get the example code provided with the driver to work.  Has anyone gotten the encoder data example code to work?

The encoder signals have been connected directly to the card and we have also tried using a LS7183 interface chip between the encoder and the DAQ card.  Either way we seem to be having trouble reading in the signals and decoding them with the Linux Driver.  Using the example CntDigEvents program we have been able to accurately read pulses coming through the ctr1_src line (PFI 3).  When using the example  angular encoder program (see attached) and a square wave input to the motor, when the motor moves in one direction we get a random, constant large number and when we move in the other direction we get values that change but do not make sense.

We have also installed the card on a Windows PC and used the same setup with Measurement & Automation Explorer and have been able to correctly read in the data both with and without the LS7183 chip.

It does seem that the card is functioning correctly as verified using Windows, but it appears that the Linux drivers are not working correctly.  Can anyone help?

[ninevoltz]

Does the same (unmodified) source code compile and run properly in Windows?

If it does, I won't be able to help you, but if it doesn't, look carefully at your data types and the return codes from the DAQ routines.

Try directly connecting a low frequency square wave generator to the counter and see if it counts properly. For all I know there really could be a bug in the GNU/Linux drivers, NI will have to help you if that's the case. I haven't used the counter function on our boards.

John 

[jbailey]

I have not tried compiling that same C program and running under Windows, but I did use MAX and set the parameters of my task exactly the same as they were in that file.  That setup in MAX worked.  I sent the code that I've been using to a support person at NI and he says what I have should be correct for my application, but I may try running that program under Windows if we can't do anything else.

I did connect a function generator to the counter and just ran a simple program (CntDigEvents) that counts pulses on the SRC line, and it worked fine.  The only problem is I do not think I can edit it so that I can count on other inputs such as GATE or AUX.  After using the LS7183 chip and more thoroughly testing the angular encoder script, it seems that the problem is reading in counts on the AUX line.  I have not been able to find a simple diagnostic script that just counts pulses on the AUX input.  Does anyone know of a way to test that?

Are there any known problems with accessing the AUX input under Linux?

[Brian F.]

Hello jbailey.  The AUX input on your 6259 card for counter 0 is PIN 45 or PFI 10.  You should be able to communicate with this AUX input in Linux.  There are no known issues with this reported.  However, Fedora is not a supported version of Linux so there may be undocumented issues that I am not familiar with directly.  I would recommend trying to compile the same C code in Windows and see if you have any success in this OS.  This will allow us to see if the problem exists with Fedora or something else.  Good luck with your application!

Brian F

Applications Engineer

National Instruments