Ubuntu 10.04, ni-usb-6210, nidaqmxbase-3.3.0
getting it to work on Ubuntu is a pain, but feasible. Why is the installation routine not general like other installers but so RedHat specific? Anyway ...
The simple examples in ANSI-C do work ("acquire1Scan", "acquireNScans") and wrapping it with ctypes into python is no problem at all.
But "acquireNScans-ExtClk" is unreliable!!! Sometimes it works sometimes its not! (the same in python, trigger is OK and observed with a scope).
The only workaround here is to read the first three channels instead of one ... at least i have not seen any error yet.
A crosscheck with windooze shows the same!!!
Actually i am trying to get the linear encoder to work (DAQmxBaseCreateCILinEncoderChan) to trigger on specific periodic positions. I tried a lot and according to the specs it should work, but i got countless error messages.
So i do not think that it is the Linux lib which is crap, but is seems to be an inherent bug whether in the lib in general or its my hardware.
Any help appreciated!
First of all thanks for posting your question to the NI Multifunction DAQ forum. I guess you already know this, but I just want to point it out, one more time. DAQmx Base 3.3 does not support any version of Unbuntu, only SUSE, RedHat as you can see from the download page ni.com/updates. The DAQmx Base 3.1 supports Mandriva, SUSE, RedHat. So you're a lucky guy if you got the driver up and running, but it's NOT officially supported.
Let me tell you how to get your USB-DAQ application working in general. To use an external clock you have to connect this clock to any PFI on your device. See for further details the NI USB-621x User Manual (371931f) on page 4-14. You can find any manual at ni.com/manuals, searching for the number or the device name. For the pinout have a look at the NI USB-621x Specifications (371932f) page 12. In general I would recommend to read the NI USB-621x User Manual (371931f) and the M Series User Manual (371022K).
One main problem you will be faced with, is the problem that the USB devices have a FIFO buffer and they will not send any data until this buffer is half full. That is the default setting. You can change this by modifying the "data transfer request condition", which is a property of a DAQmx channel. Please look this up in the NI-DAQmx help. These property settings are only available in the NI-DAQmx driver and not in the DAQmx Base. So if you have a Windows computer you can install the latest NI-DAQmx (9.1.1 current version). On a Linux system you will never be able to set this property for a USB-DAQ device, because of DAQmx Base or the missing USB device support in the DAQmx 8.0.1, which is also available as a Linux version.
I hope this information helps you to get your work done.
thanks for the info 🙂
i knew before that Ubuntu is not supported, but hey ... its Linux ... everything is possible ... 😉
The only annoyance is the highly distribution specific installation routine ... this is really not necessary ... i had to do a lot by hand.
I know about the connections/pinout etc. and with some modifications i can use the provided ansi-c examples and consequently python for programming.
The puzzling thing is that the externally triggered acquisition sometimes works and sometimes not ("DAQmx_Val_ContSamps" and multiple "DAQmxBaseReadAnalogF64").
Sampling with the internal clock never showed any problem ...
What i have observed so far is that a higher number of read channels or a larger set of samples increases the probability of successful reads.
So my ugly workaround is the sample more channels than required and drop them in software.
Your explanation about the USB buffer only being sent if half full makes sense. Although i do not understand why even a reset of the DAQ does not lead to repeatable conditions.
And my wish is still to use the linear position encoder "DAQmxBaseCreateCILinEncoderChan" with "DAQmx_Val_X4" for triggering analog signals at specific path periods ... but i could not realize it even with windooze and "full" NI-DAQmx ...
Try to set the timeout parameter for the DAQmxBaseReadAnalogF64 to a higher value or "-1". This means that your acquisition will have more time or wait infinite time until enough values are acquired to reach the filled FIFO criteria.
Hm ... does not work for me ...
When consecutive acquisitions run then at some point the measurement does not return. A longer timeout does not help.
Once its dead it stays dead.
If this does not work try to set the "data transfer request condition" as mentioned above, this is the only thing to work with the USB device.
does "data transfer request condition" mean
#define DAQmx_AI_DataXferReqCond 0x188B
I can only find .vi examples which are not much help for ansi-c or python ...
Its not documented in the daqmxbasecfuncindex ...
How can i change it?
I mean in the NI-DAQ™mx C Reference Help the topic Analog Input >> General Properties >> Advanced >> Data Transfer and Memory >> Data Transfer Request Condition.You have to set DAQmx_Val_OnBrdMemNotEmpty (10241) or DAQmx_Val_OnbrdMemCustomThreshold (12577).
This is not selectable in DAQmx Base.
If this not help you, please provide your code here, because it's hard to see what you are exactly doing without any code.
Ah ... i see ... but my NI USB 6210 is supported only by NI-DAQmx Base ... so i do not have that option ...
There is not this option in DAQmx Base, this is correct for Linux, as I mentioned in one of my post before. Then you have to try the timeout thing. But as you said, you also have a Windows testsystem, there you can install DAQmx 9.1.1, which is the latest one and then you can set the property. In that driver your device is supported on Windows only. See http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmx/9.1.1/readme.html