LabVIEW
State machine architecture
wiebe@CARYA wrote:
An event structure in a while loop is of course still some sort of SM, as it is a 'machine', and has 'state' (classes or clusters in shift registers). But traditionally, a LabVIEW state machine is a case in a loop, and an type def enum to switch state.
I think 'traditionally' is the keyword here. If you replace the case with an event structure and the enum to events, you have very much the same basic architecture, but an "Event machine", there's ofc the hybrid that's very common with different states and an UI/idle state with an event structure, is that by this traditional/strict definition a state machine?
It's interesting to note how close to the producer/consumer it actually is, just pull out the Event structure case and you're basically there. š
/Y
wiebe@CARYA wrote:
'Need' is a bit strong. I do well without SMs. But if that is the situation, a SM would be a good fit.
You are correct, I oversimplified.
For me, "state machine" refers more to the concept of being able to execute parts of code in an arbitrary order using a simple implementation rather than to the exact way of implementation using a while loop, a case structure, and enums.
About the traditional SM in LabVIEW, both you and Yamaeda are right. It's introduced in LabVIEW Core 1, which explains a Sequential Process State Machine (case in while loop) and a UI-driven Process State Machine (case with event structure in while loop). The shipped LabVIEW template "Simple State Machine " contains the the event-structure one. Which makes sense, as removing the event structure results in the other SM.
And yes, a main difference between the simple state machine and the producer/consumer concept is that in the former a case will normally be followed by one next case, whereas in the latter a case can be followed by several cases. One can implement this using a single while loop with a case structure as well, when passing e.g. an array of enums instead of a single enum. (Eliminating the advantage of having different priorities in the producer and consumer loop, of course).
@paul_cardinale wrote:
@newman3108 wrote:
Hi, im still pretty new to labview, I have built a program that is functional just wondering how to make it better and more efficient. Someone told me to use a state machine architecture with my program but not too sure how to implement it/ if it would be beneficial.
Thanks
I don't understand why people do this. You're asking for help, yet you present a block diagram that's a big mess. Apparently you've made no effort to clean it up. You'll get more people offering to help if put forth something presentable. When I see a mess like that, I don't even try to analyze it.
Haven't looked at the code, as it's still only available in LV19...
But now I don't mind anymore.
Search LabVIEW like a graph!
@paul_cardinale wrote:
I don't understand why people do this. You're asking for help, yet you present a block diagram that's a big mess. Apparently you've made no effort to clean it up. You'll get more people offering to help if put forth something presentable. When I see a mess like that, I don't even try to analyze it.
Personally, I'd not call this a big mess. I have seen much MUCH worse^^
Error handling is there, dataflow is left-to right, I see comments, correct use of the flat sequence structure. The Block Diagram is just a bit spacious, and there is no modularity.
But in general you are right, there is still place for improvement. Put some sub-VIs and the code is much easier to understand. In this case I would accept this, as this is what the OP was asking about... Constants and algorithms could still be explained.
