Problem with USB 6008 - not constant sampling rate

[George Milias]

Hi all,

  For a long time, I am trying to overcome a problem with my project which needs constant data acquisition.  The purpose of my project is to build a motorised muscle dynamometer which will have the ability from the one hand to measure continuously the position and torque of the muscle - joint and from the other hand to control the motion of an actuator (via a motor)  . The software has been developed in VB6. I use an USB 6008 unit and a PC with windows XP

Inside the main do - loop, I use a multichannel daqmxreadanalogf64 with the following parameters:

onboardclock

rate=500 samples per sec,

numberofchannels=4 

samples per read = 10

At the same loop I use DAQmxWriteAnalogScalarF64 in order to send the appropriate voltage to the motor drive.

(StartTask and Stop&ClearTask are outside the loop for gaining velocity)

For security reasons, I use a timer that measures every sec the number of loops completed (samples per sec received). If calculated samples per sec are higher or lower than 1,3 or 0,7 * selected samples per sec respectively (+/-30%), I show an informative message and quit the application.

Although the system in general is working well, sometimes the system freezes a little, and so the error message is showed. I have tried a lot of ways (i.e. faster loop, better do events, setpriority API to Real Time, genuine NI USB cable, fast and reliable PC, latest version of Nidaq drivers and many others...) to improve the performance and avoid these freezes but with no result!

The biggest problem is that this phenomenon is incidental. Sometimes, it takes place after the first minutes of working and sometimes after 1 or 2 hours, with no previous signs of showing me that the communication starts being slower.

Please help me!

I have no other ideas...

George Milias

[Kyle_A.]

Hello George,

What error message do you see after the freeze?  This will help give some insight to what could be causing this issue.  What version of DAQmx are you using?  It's hard to say right now what could be specifically causing this.

[George Milias]

Hello Kyle,

Thanks for your immediate reply. I do not see any error message immediatey after the freeze from the DAQmx error handler. Actually, it is my code that stops the loop and show a msgbox. Let me give you some more details. Inside the main loop there is a counter that its value is increased for every loop completed. In each loop I read 10 samples per channel. So with the help of a timer (with an interval of 1000ms) I can calculate the total samples per sec that have been read (counter value * 10) and check if this number is inside an acceptable range (+/- 30%). If the timer is not enabled no msg will be seen, since the freeze is not permanent but lasts only some ms and after that the acquisition continues. I can see that kind of freeze also in the real time graph where the line stops for a while and after some ms continues with faster velocity for the first secs and after continues with the preset velocity. I also used the DAQmxGetReadAvailSampPerChan with a timer in order to measure periodically how many are the unread samples (and check if I am not fast enough to measure all available data in the buffer), but I noticed that when the line stops this number is 0.

 After my msgbox, the code of the error that I get is 200279, but this is probably, due the fact that I stopped the loop. The version of DAQmx that I am using is 8.9.0f4

Any ideas?

Thanks in advance,

George

[Kyle_A.]

Hey George,

The first thing that sticks out to me is the 200279 error that you are receiving.  Whether your start and stop tasks are configured inside or outside of the loop, when you stop the loop you shouldn't see this error if they are configured correctly.  Given this fact, one thing you can try is to read more samples since you are sampling at 500 Hz.  I would sample atleast 50 samples per read.  You can ignore or filter the data if need be in your loop processing.  

If you run an example that just takes an acquisition at a specified rate, do you see the same results?  Are you able to isolate parts of your code and reproduce/eliminate the issue?  It might also be worth finding out if you are actually acquiring data during your freezes or if the chart is slow to refresh.

Hopefully, this will help pinpoint the issue.   Let me know what you find out, thank you.