`Sequencing Acqusition, Save data and Trigger

[ramrajh]

The hardware I am using is a NI-USB 6343 multi function DAQ

I am attempting to automate the process consisting of the following steps:

1) Read voltage data (DAQmx Read)

2) Save the data in a file (write to text file)

3) Send a trigger (Generating a pulse output using Counter output). 

The trigger moves the probe to the next location for measurement. Then I want to rinse and repeat the process. 

I am currently doing this manually, as shown in the VI titled "2019-12-27_Acquire data after calibration_manual trigger". The process is set for continuous acquisition. "Save the data" is triggered using a boolean button. Following this, I use the "move traverse" boolean button to move the probe to the next measurement location. I then wait for the traverse to stop moving, before I "save the data" at the next measurement location.

I am trying to automate this process, by putting it in a flat sequence, in the same sequence of events that I have given above, shown in the attached VI titled "2019-12-27_Acquire data after calibration_trigger trials". I have added a "Wait (ms)" in the sequence between Save and Trigger. The "wait (ms)" gives the VI required time to save the data, before moving the traverse to the next measurement location. I do not want an overlap of the data nor do I want it to actively save data when the traverse (measurement probe) is moving.

I have tried multiple sequences, changing the order of events and also tried different constant for "Wait (ms). However, I keep getting the error -200279 (attached screenshot), randomly. Sometimes the VI work seamlessly for 5 mins, then its crashes. Other times, it crashes immediately with the error -200279.

Any suggestions on how to modify the VI titled "2019-12-27_Acquire data after calibration_trigger trials", allowing it to work seamlessly.

NOTE: There is no feedback mechanism available from the traverse, using which I know whether it has moved to the next measurement location or not.

EDIT: I added the property node for DAQmx read, allowing data to be overwritten, based on suggestions given in other topics for this error. Didnt seem to help either.

[Bob_Schor · Accepted solution]

You (almost always) never need, and should never use, a Frame Sequence.  In your posted code, you should use a single Error Line to sequence everything.  The only exception used to be the "Wait" function, but the introduction of .VIMs (in LabVIEW 2017) introduced the "Stall" VIM that "stalls" Data Flow.  Here's the central loop of your VI, simplified and with no Frames (note that the DAQ Assistants should probably be replaced with DAQmx routines, possibly "hidden" inside small sub-VIs that "do one thing").

Bob Schor

[Kevin_Price]

Your most immediate problem for that buffer overflow error is that you start the task before the loop, but don't start reading data until / unless the big boolean GUI "Start Acquisition" button is set True.  

Based on your 10000 Hz specified sample rate, you can expect a 10000 sample buffer size, or 1 second worth before overflow.  I'd venture that many of your errors occur when you don't have a fast enough reaction time to hit the GUI button soon enough after running the vi. 

There's another significant problem though.  You're attempting to read the entire buffer contents all at once (10000 samples).  Meanwhile, in the background, the DAQmx driver is trying to keep putting data *into* the buffer at a rate of 10000 samples/sec.   That doesn't leave much time for you to get the whole buffer contents copied over into your application memory.

And then there's *also* the possibility that your sequence of events may sometimes require more time to execute, such that you can't reliably keep up with the 1-per-second loop rate you need.

I think you may need to rethink your general approach.   If you really want continuous acquisition and logging, I think you'll need to start using multiple loops and some kind of "signalling" mechanism to fire off events or messages that help you coordinate your timing needs.  

   I picture 3 loops.  1st one is dedicated to controlling and reading data from the DAQ task, and deciding when to signal for other things to occur.  The 2nd one is dedicated to logging.  The 1st loop sends all the DAQ data to the 2nd loop via queue or channel wire.  This is a very common structure known as the "producer - consumer pattern."

   The 1st loop would also know when to signal to the 3rd loop that it's time to generate a trigger pulse or time to set a motor voltage.   This signalling should also happen via events, a queue, or a channel wire so that the 3rd loop can spend most of its time idling and waiting to be signalled.

-Kevin P

[ramrajh]

Thanks for that tip Bob. I tried that out almost immediately, incorporating it into a few other VI's that I made earlier. Wonderful tip.

Still working on using the tips given by you and Kevin, to fix my original VI. Like Kevin pointed out, I am still getting a data overflow because of the wait time's that are involved.

[ramrajh]

I tried out a few different combinations and got it right. It works with error sequencing and time delays, in finite acquisition mode. Now I have to convert all the DAQ assistant blocks into sub vi's and get things going.

@ Bob and Kevin

Thanks again.

[Bob_Schor]

Yes, do incorporate Kevin's solution (which involves rethinking the design of your loop and adding parallel loops to decouple the time-locked "Data Acquisition", a.k.a. "Producer", process from the follow-on "Data Processing", or "Consumer", process.

Bob Schor