07-10-2014 02:12 PM
Hi all,
The picture illustrates my problem. Could someone help create the state machine for this?
The part that I can't really figure out is how to create the state machine without having to create an exact copy of my VI in state A
and put it in a different case. How could I tell the machine (via the shift register, for example) to go back to the code in State A
and perform the same analysis on dataset B if the user chooses to open up another data file.
The reason I don't want to copy my code into a different state is because it has dozens of plots, tables, etc, and I don't want to creat copies
of those controls and indicators on my front panel. Afterall, I shouldn't have to if I am running the same analysis, but just on a different dataset.
By the way, I attempted to write a simple example where the input is two integers and state A would add them, and if the user selected two
other integers, the code would add the additional integers. But in this example, it is easy to copy the addition operation and place it in a different
case. But still I wasn't able to get it fully working. So I am posting here to get help. Thanks in advance.
Questions:
1. Are opening file dialogue box and deciding to select data B considered "states" as well?
2. Do I need to make an entire copy of all my code in state A if the code is called again to perform on a different dataset?
3. What should the states be in my enum?
4. What needs to be connected to the Stop input of the while loop?
07-10-2014 02:25 PM
I would recommend going with a Queued State Machine. In this setup, you keep what states you want to go through in a queue and dequeue the state when you choose the state.
The benefit of going this route is that your State A doesn't need to know which state it needs to go to next. You can enqueue multiple states from your dialog states.
07-10-2014 02:25 PM
How about having a "state" where the user selects the file, then have a different state where the analysis is made? The things that are common can be in their own states, i.e. file path selection (state "A"), opening and analysis of data in selected file, if the action is truely common (state B), output to file, etc. (State"C"), return to State A?
07-10-2014 02:37 PM
In my world, there are three criteria of state machines:
See here for an article about them.
There are no established rules about it, so feel free to ignore those, but I've been doing it that way for 20+ years.
That means that the DIALOG would not be a state. The reason (for me) is most often, I might have the need for multiple copies of the same state machine to run simultaneously. Having a dialog within the machine would prevent one instance from running while the other waited on the user.
So, I keep the state machine itself separate from such dialogs, wait timers, etc.
Do I need to make an entire copy of all my code in state A if the code is called again to perform on a different dataset?
No - that's what SubVIs are for.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
07-10-2014 04:51 PM
Thanks all for the discussion. However, I am not getting a clear answer. I have read some material on state machines, have watched
some tutorials on Youtube and have clicked on some links that people post here. But most of what I have found is abstract. I'll work
on my simple example (adding two numbers, see my first post above) and maybe by trial and error I can figure it out.
BTW, yes my code does have subVIs (> 2 dozen) and there are a lot of controls (giving the user the choice to format the plots, tables, etc.),
and the code is not simple to just have a few inputs, a few outputs, and a couple of subVIs in the middle.
If someone can write a simple state machine VI that can help with my problem (even the simple one with adding two numbers), it would be great and instructive.
07-10-2014 05:08 PM
Looking more closely at your flowchart, I'm not sure a state machine is needed, or even helpful.
Consider what I call a "Manager", with three functions:
create an ENUM with those three items.
Use it as a COMMAND input to a VI, running in a WHILE loop, that uses shift registers to hold temporary results.
In the INIT case, you clear out the temp storage.
In the PROCESS case, you process some new data into the mix.
In the OUTPUT case, you deliver the results.
See attached VI.
Call INIT once, call PROCESS for each new data, call OUTPUT once.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
07-10-2014 05:12 PM
Thanks CoastalMaine.
Could you kindly convert your VI to 2011 version? I am eager to open it and study it.
07-10-2014 05:18 PM
Let's try 2010.
See attached VI
Blog for (mostly LabVIEW) programmers: Tips And Tricks
07-12-2018 06:38 AM
You can use Creately UML tool to create state machine charts. First get your flow diagram right and separate processes/decisions. Then convert them to individual states and draw them as below.
07-12-2018 07:08 AM - edited 07-12-2018 07:10 AM
Hi murchak,
1. Are opening file dialogue box and deciding to select data B considered "states" as well?
You can make this a state as well…
2. Do I need to make an entire copy of all my code in state A if the code is called again to perform on a different dataset?
No, you only need to supply different data/parameters for that state…
3. What should the states be in my enum?
I would NOT use "State A", "State B", but something more descriptive like "User Dialog" and "Data Processing"…
4. What needs to be connected to the Stop input of the while loop?
There should be a boolean FALSE/TRUE value connected to!
When the current state requires more states to be executed it should output FALSE, otherwise it should output TRUE to quit the statemachine…
Edit: Oh, I'm really late - one should wait too long before posting an answer…