Queued State Machine for Starting and Stopping a Continuous DAQmx Task

[jcannon]

Hi all, I have been away from using LabVIEW for a few years and now getting my head back into it... I am a little stuck on this problem and could use some help...

Currently, I am updating the design of some old vis of mine that perform continuous AI measurements using the DAQ Assistant and an "enable" front panel button to start/stop data acquisition as needed ... I would like to change these to a state machine using DAQmx controls and an event structure to monitor for changes in the "Start/Stop Acquisition" front panel button...

Essentially, I just want to be able to manually start and stop DAQ task as needed with a front panel button without stopping the entire vi...

I have examined all the NI examples, Google, and YouTube tutorials without success... I have attached what I have done so far (LV 2014SP1)...

Any help would be greatly appreciated...

Thanks,

Jack

[GerdW]

Hi Jack,

you need to fiddle with the conditions of your statemachine to make it work!

Right now there is a problem when you switch from "Acquiring" to "System Idle": you basically DON'T stop the DAQmx task! You try to go to "Stop DAQmx" state, but due to the outer case structure you go to "System Idle" state instead…

Recommendation: use only one case structure and implement a "DAQmx idle" state!

(Another recommendation: draw your statemachine states on a sheet of paper and sketch the conditions. This helped me a lot…)

[Quiztus2]

I don't have DAQ mx, so you have to connect the Daq mx blocks yourself.
The main idea behind this is to use a event structure for collecting your stop, exit and start clicks and additionaly to
set the timeout of the event structure to 0 in case you want to do consecutive daq reads until you click stop or exit.

[jcannon · Accepted solution]

Thank you, GerdW and Quiztus2!

I have used your feedback to create a queued state machine... This vi will be further developed into a larger, more complex application and this QSM skeleton will work great...

Thanks again...

[Quiztus2]

it appears strange to me that you start everytime before you read. I don't expect that to be necessary.

I would tidy your program before going bigger.

What is the purpose of the 2 parallel error wires?

Do you really want to polute your queue with start commands?

[jcannon]

Hi Quiztus2,

If you start the DAQmx task but don't read, the samples are still acquired by the DAQ device, which holds them in the device buffer until they are read... This leads to a buffer error once the buffer is maxed out, causing an error, and the application stops running... So the DAQmx task must "start, read, stop" on each operation to run correcting... Only the initialised DAQmx task can remain in memory via the shifter register and not be performed on each operation...

What do you mean by parallel wires? Do you mean parallel while loops? By using two loops, the event structure with the front panel controls can always be accessed and send commands to change the DAQmx state... I think with your example images, when the DAQmx "read data" state is running, there is no way for a change in the "record data" button to be actioned as the event structure is located in the "system idle" state...  Please correct me if I have missed something... 

Thanks.

[Quiztus2]

regarding error wires: I mean this error wire spaghetti here:

regarding start,read,stop: Sure, Init, Start, Read,Stop is perfect, but did you consider also: Init, Start, Read, Read, Read,Read, Stop?

In the code I created for you the following should happen ( I didn't test it) : Click Start -> Start Case (Start) -> Read Case (Read) -> Idle State (React to clicks, otherwise timeout) -> Timeout -> Read Case (Read) and so on.

Regarding parallel loops:

I didn't test your QMH, but it looks like your event loop polutes the queue with start commands when timeout is set to 0.

[Yamaeda]

---

@jcannon wrote:

If you start the DAQmx task but don't read, the samples are still acquired by the DAQ device, which holds them in the device buffer until they are read... This leads to a buffer error once the buffer is maxed out, causing an error, and the application stops running... So the DAQmx task must "start, read, stop" on each operation to run correcting... Only the initialised DAQmx task can remain in memory via the shifter register and not be performed on each operation...

---

 If you want to 'back sample' i'd put the sampling in a separate loop that keeps a record (array) of fixed/limited length and pull from that when needed. It can e.g. keep the last 10 seconds worth of data and and rotate/overwrite as needed. 

This can be implemented in several ways, an array which you prune is the 1st thought, but it could also be a lossy queue.