Test bench loop time increased 6 folds.

[Spongetowel]

Hi,

          I have a test bench that was in use for 2 years now that uses a USB-6001 to read 5 analog input. The read input cycle time is set to 50ms and was stable until recently. Now the loop time increased to 300ms, same build, same equipment. I tried it on a different PC and the build worked again at 50ms, but the next day it jumped to 300ms again. I suspect windows update, and that the second PC was turned off and updated overnight. But going through the update (KB5017308) I cannot find anything to substantiate my claim.  

Anyone else had similar issue ? 

[santo_13]

It is possible that it may be unrelated to the Windows update and it was present all along waiting to show itself due to the way the "data acquisition" application was implemented.

Just to rule out the possibility of a design bug, please share the source code of your "data acquisition" application.

[GerdW]

Hi towel,

---

@Spongetowel wrote:

I have a test bench that was in use for 2 years now that uses a USB-6001 to read 5 analog input. The read input cycle time is set to 50ms and was stable until recently. Now the loop time increased to 300ms, same build, same equipment. I tried it on a different PC and the build worked again at 50ms, but the next day it jumped to 300ms again.

---

How do you enforce that sample rate?

Do you set the samplerate using DAQmxTiming function within the DAQmx task - or do you just throw some wait functions into your loop and read single samples?

When you need reliable timing (aka fixed samplerate) you shoudl use the DAQmxTiming function!

[cstorey]

You might be running into USB selective suspend issues.  Google how to turn it off so the computer keeps the USB connection between your USB-6001 and the program alive.  

Any errors during execution?  Big files being written?  Network storage that can't be accessed?  Other than that, if you want good help, you should post the code to see if there are race conditions or errors that need fixing.

Cheers,

Craig

[Spongetowel]

Thank you for the replies. 

It was an existing software that I updated 2 years ago to satisfy new requirement. So I'm not comfortable posting. 

The acquisition is in a while loop, the loop stops when the readings are stable ( 3 readings are the same).  With DAQ Assistant there is 4 analog voltage input, 25 sample at 2khz. 2 channels use custom scaling. each channel pass through ((add array element / array size) + offset) into a build array. there is a wait 50ms and a tick count to show current loop time.  The front panel has 2 item, a wave graph of one of the channel and an indicator of loop time

During acquisition there are no other task performed, all report generation is done afterward. 

When it was in development, I tried working on my laptop but I stopped because the loop time was also higher so I always work on my desktop. I figure it was just poor performance

There are no error, warning or anything. The issue was discovered when the speed reading was all wrong and I observed my loop time indicator was not at 50ms anymore. 

I am not currently on site, so there are test that I will only be able to perform later. 

[santo_13 · Accepted solution]

So, it is almost clear, the root cause based on your description is "by design and implementation".

Few red flags,

1. DAQ Assistant
2. Using software wait (tick or any sort of timing node) to enforce sampling rate than use hardware-timed sampling
3. Measuring loop time

[Spongetowel]

I reluctantly followed your advice and ditched DAQ assistant, timing the loop only with the sample N on readings. It solved the issue. I kept the loop time reading because I need to keep an eye on it to validate the loop time. I lost a bit of stability, oscillating between 49-50ms, which is an error of about 1-0.5% on timed readings. 

Funny thing is that the old version using DAQ assistant and 'waited' loop still worked. The only distinction in my  update was that I used DAQ assistant scaling tool and added 4 more analog inputs. 

Meanwhile, my local National instrument support did not reply in three weeks. 

Thank you for the support.