DAQ NI6009 Timing & PC transfer rate

[Federico B]

We are trying to develop a robotic arm control system. The devices group involved in this project include a NI USB-6009 DAQ. We know that this device can sample at 42 KSamples/second, but we assume it is not the frequency at which samples arrive to the PC. We are working with NI DAQmx Base, on a Linux platform. The samples arrive to the PC (by calling the DAQmxBaseReadAnalogF64 C function - see attached code). Then are processed, and the resultant signals are send back to the motors to move the joints. 

The fact is that the samples arrive to the PC at about 100 S/Sec... It's not enough for our requirements. We need at least 1 KS/S (for each channel, and about 8 channels). 

What device do you recommend us? Is it possible to reach those requirements with the NI 6009 DAQ?

Regards

Federico

[Dennis_Knutson]

The code is now more readable than in your other post but why are you still using single point read? And if you want 1kSample/sec, why is your sample rate set to 20?

Have you looked at any of the example programs?

[Federico B]

I'm using single point read because I'm not interested in getting old value samples, just the last one that was sampled by the DAQ.

If I set the sample rate to 1000 Hz, I start having old samples (buffered samples). 20 Hz is a value that the are using now because the things go right, we get correct samples, which represent the current voltage in the inputs.

The file attached was made based on 2 examples: acquireNScans.c and genVoltage.c (NI DAQ mx Base 3.2.0).

We want to have the last (current) value with the lowest delay, not a block of values taken at some exactly frequency with old samples.
Is this DAQ the correct device? Should I use another code?

Regards,

 
Federico

[Dennis_Knutson]

Using your software timed approach, I don't think it much matters which device you use. I could be wrong though, whenever I've wanted 1000 samples per second, that's the clock rate I used.

[Federico B]

Do you understand my problem? I think you didn't read the previous messages I've sent.

I want 1000 samples per second, but not blocks of 1000 samples per second. That doesn't help me. 

I want a sample, 1 ms later other sample, 1 ms later other sample... 

Regards

Federico

[Dennis_Knutson]

I understand your question perfectly well. What I'm saying and you don't seem to understand is that I don't think you can come close to the sample rate in software timed acquisition, which is what I believe you are in when you select a single sample. All of the specs for acquisition rates that you see are for hardware timed acquisition - where the internal clock controls the sample rate.

[Shawn B.]

Hey Federico,

As Dennis pointed out if you use software timed acquisition you are limited by your OS, computer, and hardware.  I feel I should also point out that since you mentioned you are building a robotic arm control system, that you may have some other problems with your approach.  I'm assuming that the reason you are performing single point software timed acquisitions is because you trying to monitor in "Real Time" and adjust your control system.  What you care about in this case is latency (the time between when you ask the computer to do something and when it actually happens).  Unfortunately your choice of OS, and hardware may not meet your latency requirements.  PCI has a much lower latency than USB and is more deterministic.  Additionally Linux is not Real Time OS and may not provide deterministic software timed loop rates.

Of course using a PCI data acquisition card with a Real Time OS like LabVIEW RT still may not solve your problem.  Real Time does not mean "fast" only deterministic so your acquisition rate may still be limited by how fast your software can process the data.  You are obviously wanting to process every single data point as it arrives or you wouldn't be doing what you are doing.  I think you should spend some time thinking about your latency requirements.  What is the maximum time you can have between data points?  What happens if you exceed that maximum time?  Will your robotic arm move further than it should and break?

Shawn Bohrer

National Instruments

[Federico B]

> All of the specs for acquisition rates that you see are for hardware timed acquisition - where the internal clock controls the sample rate.

That's why I'm asking, about the limits of the 'one sample delay from NI6009 to PC'. I want a software controlled acquisition. 

Is there a way to improve this 'software controlled acquisition'? The accuracy of the timing (i.e. 1000 Hz) is not important for us, just the maximun rate at which I can request 'one sample value' to the NI6009. We are working with a query-request software architecture, which uses the DAQ as 'current situation device'.

I think there are specific devices for doing that. What kind of DAQ devices do you think could help us?

Regards

Federico

[Federico B]

Yes Shawn, we are trying to use JAUS, on a Linux platform, for controlling a robotic arm. You're right, latency is what worries us. By the moment we are working with RTAI, we need a soft real time OS since the arm is an therapeutic project, nothing catastrophic will happen if some event is lost.

The latency should be less than 2 ms...

What DAQ device do you suggest to work with Linux and those requirements?

Thanks a lot!!!

Federico

[Shawn B.]

Hey Federico,

DAQ is not my area of expertise I am more of a Linux guy, so I don't feel comfortable recommending a specific piece of hardware.  I would recommend talking to your local NI sales representative, or simply calling/emailing the sales team.  I will tell you that something that supports hardware timed single point sampling mode would be best.  Additionally I'll mention again that since you need to process every data point as they are acquired, your computer and software will influence if you can achieve your required latencies.

Since I am a Linux guy, I am interested in the fact that you are using RTAI.  I should warn that we do not test any of our Linux drivers on any of the RT Linux variants so it is possible you could encounter issues using our drivers with RTAI.  I'm guessing you haven't had any problems using NI-DAQmx Base with your USB-6008 on RTAI so far?

Shawn Bohrer

National Instruments