LabVIEW
Event Driven State Machine Infinite Run Error
Hi chuck,
@User002 wrote:
Local variables are restricted.
Then why do you use all those "value" property nodes? These are basically the same as local variables!
Why are there controls/indicators missing their labels?
Why are there so many unused terminals in your block diagram???
@User002 wrote:
In my program, I cannot stop the program when sample mode is continuous. I had thought the stop control would work to end the loop since it is inside it, but that is not the case. Any suggestions?
Which loop does not stop?
What's the sense in using the "visible" property of your stop button to stop a loop???
Other questions:
- Why don't you handle one or two channels using the same code? You can use DAQmxRead in "N channels" mode for both options!
- Why do you use an ExpressVI to index the waveforms from an array? Why not use IndexArray to index array elements?
- Why do you use DDT wires? (Related to previous question…)
- Why don't you use DAQmx scales when you need your DAQ readings in mV instead of V (according to the name of that missing subVI)?
If local variables are a misdemeanor, value property nodes are a felony! 😮 Who made these rules and what's the logic behind them.
In a properly designed program, you don't need any locals or value properties, there are plenty of ways to do this better. LabVIEW is a graphical programming language and "the wire is the variable". You seem to have all these disconnected controls as fake variables, then use value property nodes to access them (exactly the same as using local variables!!!). I am sure your teacher was trying to wean you off these really bad habits, but you are just substituting meth for crack.
So you are hiding labels to temporarily mess things up just to have to clean it all up later? Why this detour? Then you are even deleting labels of your value properties with the confusing effect that all look the same, but in fact pointing to different front panel objects. Why would you do all that in the first place, making later cleanup full of landmines.
Your state enum needs to be a typedef! You have all these diagram constant and if you ever need to e.g. add a new state, you currently would need to replace all enums with the new version. Plan ahead!
Your use of an event structure is completely misguided here. All you need is repeat the idle case if no button has been pressed. The terminals of latch action booleans never belong outside the toplevel loop. Do you know why? Any operation of the the start or end buttons while the code is not in the idle state will permanently lock up the VI forever. Again, do you know why?
In a better design, you would keep a cluster of all settings in a shift register, bundle the new value by name when a settings change and read the current setting using unbundle my name wherever needed. Now you have full control over where the settings are modified.
You don't need any inner loops. Done right, the outermost loop is sufficient to loop anything you possibly ever need to loop. All terminals can be right there!
Your shift registers are not initialized and e.g. the error wire is not cleared in the init state, meaning that of the previous run ended in error, you'll start with a permanent error on the next run and nothing will work.
Value properties share all the same potential race conditions as local variables. (because they have an error wire, sometimes execution order can be made slightly more deterministic, but you don't even use that!). Property nodes execute synchronously and require a thread switch and are thus require orders of magnitude more time and resources to do exactly the same thing as a local variable.
To change properties (blinking, color, disabled, etc.), you use property nodes.
To change values of indicators, you would use the wire!
The value of controls are supposed to be changed by the user, not by the code. (in the very rare case where a control value needs to be changed via code, use a local variable) .
Excessive use of local variables or value properties blurs the important distinction between controls and indicators and makes understanding the code at least twice more difficult and offer multiple more places for bugs to hide..
Latch action booleans (your start and stop) reset back to false once they are read by the code. If they are outside, they only get read once at the start of the program and never again, so they never reset. You are also never notified that the code has actually read them. Flying blind!
You events still lock the front panel. Get rid of the event structure!
You still have plenty of blank and missing labels on diagram objects!
You still have all these completely unneeded value properties!
You have an outer loop that you can use to spin any of the inner code according to the current state. Just remain in that same state until you want to go to a different state. No inner loops needed. For example if you are in continuous mode (after deleting the inner while loop), you would just go back to continuous mode, but go to "end: state once the stop button has been pressed. Same difference!
A case structure does not display anything, so I am not sure what you are talking about.
(Also note that if you use a typedef, you need to attach that too.)
Here's a quick rewrite that demonstrates some of the ideas to eliminate ALL value property nodes. I took out the event structure and you are free to put it back in, but you need to very careful how you configure it (e.g. don't lock the panel! Set the even queue to 1, etc.)
I don't have any of your hardware or drivers, so all code is broken for me and I cannot test. I cannot do certain wires, so they are missing Most likely there are bugs but you should be able to glean some ideas how to do things better.
Please don't post examples that you did not write. Just provide a link!
Is this an official example by a reputable programmer or just some random hack found elsewhere. Seems pretty questionable with the latch action terminals outside the loop, no icon, no documentation and not even any diagram comments. A silly state filled with five different "init to default" nodes. Way too clumsy! OTOH, you seem to have copied all these glaring mistakes verbatim.
Why don't you open the example finder and start with "state machine fundamentals", for example? Then graduate to more complex examples.
