DAQ Assistant data lag when acquiring force data from NI USB-6002

[kellanrams30]

Hello,

I am attempting to collect force data from 2 loadcells that input analog data to our NI USB-6002 DAQ. The timing of our data collection is very important. When collecting data I sometimes will see a delay or lag in the force waveform plots that I have, and the force data that I write to file does not keep up with the the forces that I am inducing on the system. The data itself is very noisy as well. 

In DAQ assistant, I am collecting the data at 2000Hz and set the number of samples to 50, which I have found to be the most effective for continuous acquisition. The DAQ we are using has a USB connection (no ethernet). I collect the data in a while loop that also collects timestamp data from a different component of our system. Does anyone have advice for what may be causing the delay that I am experiencing?

An image of my DAQ assistant code is attached. 

Many thanks,

Kellan 

[santo_13]

First and foremost advise - please DO NOT use DAQ assistant.

Since you mention the timing of your data collection is very important, you would have to learn and use DAQmx functions instead.

A simple analogy for DAQ Assistant is the training wheels on a bicycle, since your objective is to do stunts on a bicycle you have to let go of the training wheels and learn to ride on your own. The same applies here, DAQ assistant is only for newbies, it can't get you much when you start increasing the requirements

This would be a good starting point,

https://www.ni.com/en-us/support/documentation/supplemental/06/learn-10-functions-in-ni-daqmx-and-ha...

[Tom_Powers]

I kind of take exception to the remark that daq assistant is only for newbies.  I use it all of the time.  BUT whenever I use it I right click on it  and convert it to DAQmx code.  Then I start modifying that code.  Thus I use it as a quick start aid for writing real code. 

To OP's point.  Each time you do a DAQ assistant it creats a task, creates each channel, sets up the clocks, starts the acquisition, gets the data then closes the task which is a moderate amount of overhead.

It is probably more time efficient to do a state machine

Init make sure all of your stuff is correct.

Set up the file and write the header,

set up acq state

    create the task then do a for next loop to create all of the channels then set up the clocks then go to the

Get data state where you

   -start the acq, check to see if you are done, get the data, then go to

Process data or file data or plot the chunk of data or what ever then go to wait

   here you process the data or file the data or what ever.

Wait

  Check and make sure that the controls did not change

  if so go to set up acq

  if not go to get data.

  On exit go to exit.

Exit

   To be clean close the DAQ task 

Also if you have a big data graph with more than a few thousand points it your program could delayed.

[Bob_Schor]

---

@Tom_Powers wrote:

I kind of take exception to the remark that daq assistant is only for newbies.  I use it all of the time.  BUT whenever I use it I right click on it  and convert it to DAQmx code.  Then I start modifying that code.  Thus I use it as a quick start aid for writing real code. 

---

And if you read the reference cited by the "first responder", you would also abandon the Dreaded DAQ Assistant and immediately (a) create a Task (in MAX or in the LabVIEW Project), (b) drop a "DAQmx Start Task", "DAQmx Read" (or "DAQmx Write", as appropriate), and "DAQmx Stop Task", (c) connect them with Task/Channel wires on top, Error Line on the bottom, (d) wire a blank Constant to the DAQmx Start Task, click the down-triangle and choose the already-created Task from Step (a), and draw the While Loop around the Read or Write of Step (b) "to Handle 80% of your Data Acquisition Applications".

Bob Schor

[kellanrams30]

Thanks Tom, 

I will give this a shot and see how it goes. 

Best,

Kellan

[johntrich1971]

You are additionally opening and closing the file each time by using the Write to Measurement File express vi. You should instead open a file prior to starting the acquisition, write to the file, and then close the file upon completion. 

I also like to use a Producer/Consumer architecture when I'm streaming data to a file. This keeps the data acquisition separate from all other activity. Another option is to set the DAQmx driver up to stream to a TDMS file.

[Kevin_Price]

---

@johntrich1971 wrote:

... I also like to use a Producer/Consumer architecture when I'm streaming data to a file. This keeps the data acquisition separate from all other activity.

---

👍👍👍

Yeah, that's right, 3 thumbs up!  The *reason* to keep a streaming DAQ loop lean & mean is that you don't want to risk a fatal-to-the-task buffer overflow error.  If your logging loop lags behind, you just build a backlog in the queue.  If your DAQ loop lags behind too much, it produces no more data ever (until you stop and restart the task).  The point is, the DAQ loop tends to be the most critical point of failure, so it deserves special attention and diva treatment.

-Kevin P