I have a couple of question I would like to present. I need a sort of hint on how to best perform a contiuous acquisition cycle using timed FSM.
I am going to upload my VI (it's conceptual, not a currently working one) and ask for explainations.
I need to acquire the voltage of a battery. The load power comsuption is driven by a couple of transistor. I drive the transistors trough two digital IO lines of the USB daq.
Since I need to have some power cycle for a given time, I need to have a sort of time control on the output.
So I wrote a simple state machine whose states are updated when a timer reaches zero. Each state has its own time to wait.
Furthermore, I differentiate the acquisiton and control operations using two while cycles.
First question: is this a correct way of building a timed fsm?
I need to log and correlate the input line to the internal states of the fsm. So i madesome numerical indicator on the front panel of the VI and created a local variable (I know that local variables are BAD but I had no other idea about) to pass values from a while to the other.
I aslo want to select the sequent state of the FMS based on the input value I get from a channel. Can I stil use a local variable?
Will the two tasks be related?
Second question: are local variables something that I can use for this task?
Last but not least: I need to perform some filtering on the acquired values.
In this vi i perform a filtering operation and then i get the local variables I use for the control.
will this filtering desync the two while cycles?shall I perform any control BEFORE perform the filtering?
The same question is valid for the logging purpose: logging unfiltered data I suppose is unuseful. But based on this "architecture" I know fsm states and the signals logged are out of sync (since it happens in a lot of dataset acquired with this vi).
Is it a problem of the logging (maybe given by different buffers for the daq and internal state or something similar) or the whole fsm is going to be out of sync, so the dataset acquired is no longer useful since it's out of sync?
Any hint would be very appreciated.
Solved! Go to Solution.
Question 1: It is a reasonable start but lacks some things to make it a good FSM. There is no Wait or delay in the loop so it will run as fast as possible. The US-6008 has software timed digital outputs so the DAQ Assistant may take some time but the amount of time is unknown and not necessarily consistent from iteration to iteration. Since the Analog Input DAQ Assistant in the other loop runs at <= 10 iterations per second, a Wait of 100 ms in the FSM loop seems like a good starting point. Waiting 3000 ms is not a good idea because the loop becomes unresponsive to the stop button for long periods.
Do you need to write to the DO lines on every iterations, even when the data has not changed? Add a DO Write state which is called only when the data changes.
The DAQ Assistant has a Stop input and a Stopped output. When you are ready to stop the loop, the stop signal should be wired to those inputs so the DAQ Assistant can clear the tasks. The Stopped output can be wired to the Stop terminal of the loop.
It seems that you want to link the two loops. Local variables are generally a poor way to do this. The better way is to use queues. One queue can send the current state to the file loop. (More comments later on whether that is really what you need). A different queue can send the data or, better, commands, from the file loop to the DO loop.
I think that you want the values of the digital outputs rather than the state. Particularly if you add a DO Write state as I suggested above, the current state will not always represent the power condition of your test equipment. To make this work with the additional state the boolean array should be passed from one iteration to the next via a shift register.
It appears that you have at least two commands to be sent from the file loop to the DO loop. One is the Stop command. The other is a Go to Next Power Level command. You should probably have a command to Set the Power Level to Off which can be used if the battery voltage gets too low and before stopping. The way your program is currently configured, the last power level will continue as long as the computer power is on and the USB-6008 is still plugged in. Stopping the program does NOT reset the DO lines.
When using anti-parallel queues, you need to be careful about setting the timeouts and about handling the timed out case.
The advantages of queues are that it is easy to assure synchronization at the levels you need, that data can be buffered as needed, and there are good examples. It also avoids the possibilites of race conditions often introduced by local variables. This program could be based on a variation of the Producer/Consumer Design Pattern.
Filtering questions: Any filter introduces a time delay. In your case where you are filtering 100 samples 10 times per second it is likely that the filter will be done long before the next data set arrives. So the delay of the filter is not what affects your synchronization. The queues described above will resolve the issues. Since you are looking at cycle times of seconds and minimum intervals on the order of 100 ms, the exact timing (at the tens of milliseconds level) is probably not too important.
The real question about the filtering comes down to this: Does the control work better if the signal is filtered?
- - - - -
I would probably do the whole thing somewhat differently. Given the slow speeds and the small amount of data, a single loop with an enhanced state machine is all that is needed. Get rid of the DAQ Assistants and learn to use the DAQmx VIs. States might include: Init DO, Init AI, Init File, Idle, Read AI, Write DO, Analyze, Filter, Set Power, Wait, Save, Close File, Shutdown DO, Shutdown AI, Error, and Exit. No local variables. No dummy indicators just to allow the creation of local variables. Very little code outside the state case structure. No queues.
First of all, thank you very much for your reply.
I think that I'll switch to a single while cycle as you suggested.
Anyway, for me is not so clear why I should switch from 3000ms to 300ms for the timer.
I thoutght that the while cycle would not stall but run continuously until the time counter reaches zero - and then update the state of the state machine and retriggers the timer.
That's why I didnt'use the "wait" function.
"The real question about the filtering comes down to this: Does the control work better if the signal is filtered?"
Since the line is a little bit noisy BUT I didn't perform any kind of hw lowpass I wanted to have a smooth signal in oreder to get rid of fast spikes or similars.
But I was thinking that IF the two while loops were sync, a filter on the AI lines would have shifted the states-data.
I'll edit the vi and then come back with more questions.