USB-6210 DAQ delay issue

[Moseq]

Hello All,

I have an Issue with data delay during program running.

I have VI find_device_names_DAQ.vi for opening comunication with USB-6210 and physical channels in it. DAQmx Start Task.VI is the output of this find_device_names_DAQ.vi, the DAQmx Read Data.Vi is placed inside of producer loop. 

My question is, why during running the data gets "delayed", I mean, I have a time set in producer loop at 100ms, and I am gathering 10 samples per sec in contiunous mode, after 500 cycles signal from analog pressure sensor and results put into program starts to mismatch in time. This time mismatch is increasing during running, so when analog signal from sensor is in 0 second, data is placed in waveform in 3s, then maybe 5s and so on. 

What is more, should I put USB Switch management in another consumer loop, or should I keep it in producer loop?

Thank you for help,

Mateusz

[Kevin_Price]

There are problems both in how you try to control timing in your loop and in how you keep track of it.

The "Time Frequency VI.vi" forces a delay based on (alleged) frequency and then outputs an elapsed time value when it returns.  Here are 3 main problems with it:

- the frequency value is a user input that isn't related to the AI task sample rate.  You should have a single data source that feeds both to make sure they agree

- the frequency value is used wrongly to set a delay time.  "1000Hz" waits for 1000 msec, "500Hz" waits for 500 msec, etc. 

- the elapsed time output is a calculation based on assumptions.  Namely, the assumption is that total elapsed time is exactly equal to the iteration # times the requested wait time.  You're not considering the time needed to execute other code in the loop.

Further, the forced wait is probably causing your iteration time to be slower than the sample rate.  This causes data to build up in the task buffer because DAQmx Read will only read the single oldest sample available.  Over time, your GUI displays will be lagging farther and farther behind the real-time sensor signals.

-Kevin P

[Moseq]

Thank you Kevin for fast reply. According to 1st issue, a single data feeding both you mean I should connect sample rate in DAQmx Clock Vi and the wait in producer loop (for ex. I will put wait for 100ms , so I must set sample rate at 10 samples per sec etc)?

Can you provide me some example or advice how should I handle with time then ? Create another loop where I will use get queue status function and there put wait just to not force to wait producer loop ? 

Thanks in advance! 

Mateusz

[Kevin_Price · Accepted solution]

The best way to handle time will depend a bit on the bigger context of your app.

In a reading loop, you can use DAQmx Read alone to control loop timing.  A typical rule of thumb is to request about 0.1 sec worth of samples per iteration, which will cause the loop to run at 10 Hz.

You can read the data as a waveform instead of an array.  Each waveform you read will provide timing information that's as precise as your sample rate.

There are other schemes that time the loop with only the Wait (msec) primitive, and then request the potentially variable number of "all available" samples using the special value -1 to indicate "all available."

You should end up with exactly 1 thing that controls your loop timing, no more no less.  The other things that execute within the loop need to not interfere with that timing.  So, you can also get in trouble if you rely on timing via DAQmx Read, but read only 1 sample at a time from a high sample rate task *and* have time-consuming processing in your loop that prevents you from iterating as fast as you sample.  Execution time of the code in the loop is a 3rd possible thing trying to control loop timing.

As a rule, my DAQ producer loops do little or no processing of the data they read from DAQmx.  I let other consumer loops do the processing to minimize interference with the timing of my DAQ loop.

-Kevin P

[Moseq]

Sorry for quite delay in discussion.

I did as you suggested and now data acquisition is doing properly, Thank you !

I have also a question, I have not tried it yet, but is it possible to synchronize 2x NI USB-6210 on one PC in one software to work in paralell?

I am also not sure if I use queue propelly, I mean I am putting data twice in producer loop to gather informations in consumer loops, should I add "Input in Queue VI" in producer loop as many times as many consumer loops I have in software? Or is it made differently?

Many Thanks,

Moseq

[Kevin_Price]

It should be straightforward to use 2 USB-6210's in parallel.  It may be a good idea to use independent parallel loops in software to service them.

To sync the 2 devices takes a little more work (but not too much).  You'll need to physically wire some kind of shared timing signal(s) between the devices, configure the tasks properly to generate or use that signal, and then be careful of your sequencing.  I like to designate a master task that exports its sample clock and 1 or more slave tasks that receive it.  Then I make sure all slave tasks are started *before* the master task.

Basic queue info (I can't look at code now): each time your producer loop code calls Enqueue to add data to the queue, the data goes to the back of the line where it accumulates with other data that was added previously.   Each time a consumer loop calls Dequeue to remove data from the same queue, it removes data that's at the *front* of the line, i.e., the data that's been waiting there the longest.

If you have multiple consumer loops, it's generally advised to have a separate queue for each consumer.  Then a single producer loop might call Enqueue multiple times, but each instance would have a distinct queue refnum wired into the top left terminal.

If you often find yourself distributing the same data to multiple consumers, there are other approaches (such as DQMH) based around custom user events that may be preferable.

-Kevin P