Flat sequence to State machine Conversion

[zahidkjatoi]

Dear LV seniors/Experts,

I have created a program which has a lot of flat sequences (As shown in below image).

But the problem is that i could not stop these sequences whenever i wanted. Because, when I am in the middle of sequence, even I press stop button, it does not work. I searched on this forum about solutions, everyone is suggesting to use state machine. My question to you is that, how can i transform this flate sequence to a state machine which is not controlled by any events. These flat sequences contains a set of tasks which should be performed one after another, without any external command. I have created a sample program, just to show the flat sequence which I have to use (Or alternatively state machine) to ensure running of tasks in sequence. Kindly guide accordingly...

Thanks

[Norbert_B]

I recommend to move to a Producer/Consumer instead of a state machine.

From the screenshot (not reviewing the VI you attached) it seems less effort to do so.

[crossrulz]

It looks like you already have a state machine.  Just make each frame in your sequence its own state in your main state machine.  So when you press "Standard Test", you then transition to the first state of your test, which transitions to the next step, etc.  You can add checking for the abort button in each of those states.

[zahidkjatoi]

Dear Crossrulz,

Thank you so much for your reply. Yes, i do have a state machine implemented here. But i could not get your point. Should i make another state machine for every test (for example 'Standard test') ? Actually the main state machine has 4 types of different tests which run on user input alongwith an error shutdown and stop button event. Do I need to add more events into main state machine?

Kindly elaborate,

Khan.

[Norbert_B]

From the screenshot, you have a state machine with at least one state containing an event structure (i hope no states more have an event structure!). This event structure has at least one event case containing a sequence structure.

That means: If the event occurs, you want to execute a sequence of actions.

You can add those actions as cases to the state machine you already have, but you will not detect button hits (or to be more precise: execute events to button hits) until returning to the case containing the event structure. So a simple "moving up the actions as states" does not provide what you are looking for.

Because of that, i recommended the Producer/Consumer as the consumer can represent the sequence of actions ("self-feeding") while the producer still can react on button hits inbetween and e.g. modify following states for the consumer.

[daveTW]

As a start, I made a little example of a conversion from a flat sequence to a state machine.

[zahidkjatoi]

Dear devTW, 

Thank you for your kind reply and example. The problem in my case is that, i don't have any values which is passed from one frame to another. All frames are independent and do separate tasks (The example attached is just for having idea of flat sequence). When one frame (or case/state) is completed, the other frame (or case/state) should start automatically- which is the requirement. But case or state usually needs to be triggered or executed on some conditions, here i don't have any conditions which could trigger it. Hope you'll understand my point.

Waiting for your kind reply

Khan.

[zahidkjatoi]

Dear Nobert_B, 

Thank you for your kind reply.  I understand your point of using producer/Consumer loop. But i am little bit confused that how are the elements in producer loop will be created and how the different cases inside consumer loop will be executed. Hope you'll understand my point. Kindly guide me accordingly.

Waiting for your kind reply

Khan.

[cbutcher · Accepted solution]

Using the example already posted as an idea - there is no reason the states have to be linked. Attached is a VI with 3 steps all just performing addition with no communication between states, using a 0ms timeout event structure.

With regards to producer/consumer, the idea often involves a Queue sending the states all to the consumer to carry out when you press "start", or similar. If you need to stop after a state that is in progress, you can enqueue from the opposite end. This becomes more complicated when you want to for example save and stop - then you have to reverse the order of the states that are enqueued, but that brings its own problems. 

[Norbert_B]

---

@cbutcher wrote:
[...] This becomes more complicated when you want to for example save and stop - then you have to reverse the order of the states that are enqueued, but that brings its own problems. 

---

Well, that really depends on the design.

When stating "self-feeding consumer" i refer to a queue driven state machine inside the consumer. That means that the producer only enqueues "start sequence" and each 'step' of the sequence (aka case in the consumer) enqueues the next following 'step'. Please note that in such use-case, i prefer the term "action" rather than "step" as it a) better suits the terminology of state machines and b) it does not conflict with TestStand terminology.

That means that the queue should only have one element (or none) in the first place.

You are correct that feeding the queue from the producer in parallel (e.g. save and quit) has to make sure that nothing goes wrong, even if in such situations the queue might have more than one element.

Enqueue in opposite end is one tool to address priority handling. Flush queue is the other tool to prevent incorrect usage.

That requires that no one is enqueuing things except the loop ('process') you are now looking for.

Example:

The producer starts a sequence by sending "start sequence". The consumer starts its self-feeding sequence execution. The producer is idle and can react on user interaction on the GUI.

If the user presses "Save and Quit", the producer enqueues in opposite end "Save & Quit".

Now, the consumer (who enqueues 'normally' at the backend of the queue) has to go to "Save & Quit" action as next step, regardless of what the consumer enqueued to feed itself. Inside this action, flush the queue. If you have to different cases for "Save" and "Quit" already designed, enqueue these states after the flush.

To ensure correct functionality, when "Quit" is involved, the producer has to stop or, at least, to NOT enqueue anything more to the queue! Disabling controls might be a suitable approach to prevent users from incorrect interaction in case the producer is not stopped right away.

Remember to enable them in the init of the application to have a clean GUI.