QSM, queue based on current state

[Patrem1]

Hi,

I'm trying to change the architecture of my Vi to Queued State Machine. Never used that before. 

At first I just put the loop with the States themself and controls being read in the same loop. 

I thought might as well use it as supposed and add the Event loop on top. 

But now I'm puzzled with how to handle this situation. 

The Vi change parameters and preview a camera. You cannot change parameters with the preview running. But I did it so the user can change settings without stopping the preview manually. 

When a parameter change button is pressed, let's say 'write FPS' the next states depends on the current state. 

If just in 'Idle', go to 'Change FPS' then back to 'Idle'. 

If in 'Idle preview' (Idle with preview On), go to 'Stop preview', 'Change FPS', 'Start Preview', back to 'Idle Preview'. 

When I had just one loop, I knew in which which state I was so I knew which states to queue. 

But with the event stuture, I'm not sure how to handle that.

I feel like my 'Idle' and 'Idle preview' thing' might be part of the problem. 

How could I queue the next states based on if the preview is On or not?

Thank you, 

[Ben]

About half of the projects I work on are ones where I am asked to get rid of the QSM and make the application more readable.

In short let me suggest using a Queued Message Handler.

When you are developing your code think about making what you are visualizing as "States" as sub-VIs that can be called in the proper sequence. This often will eliminate the need to stack-up State calls and any difference in how the sub-VIs are called can be handled in the state itself.

Ben

[crossrulz]

---

@Patrem1 wrote:

How could I queue the next states based on if the preview is On or not?

---

Just store the "preview" status in a shift register.

[Patrem1]

The thing is that this shift register with the 'preview' status would be in the bottom loop, so not accessible to the Event Structure when the next states are queued on a button press. 

I guess I could use a local variable or channel wire or something like that to share this info. 

[JÞB]

---

@crossrulz wrote:

---

@Patrem1 wrote:

How could I queue the next states based on if the preview is On or not?

---

Just store the "preview" status in a shift register.

---

Tim that exposes data to states that may not need it and someone might mess with the data in a state it should not be messed with- Use a Global<Ducks>

After reading the OP's response, use a FGV with error in and error out

[crossrulz]

---

@JÞB wrote:

---

@crossrulz wrote:

---

@Patrem1 wrote:

How could I queue the next states based on if the preview is On or not?

---

Just store the "preview" status in a shift register.

---

Tim that exposes data to states that may not need it and someone might mess with the data in a state it should not be messed with- Use a Global<Ducks>

After reading the OP's response, use a FGV with error in and error out

---

Actually, it sounds more like I did not properly understand the setup the OP has.  QSM is a single loop, which means it should be fine storing it in that loop.  But the OP's last post points to them actually using a QMH.

Patrem1, Please post your VI so we can understand what your current situation is.

[Ben]

---

@crossrulz wrote:

---

...

After reading the OP's response, use a FGV with error in and error out

---

Actually, it sounds more like I did not properly understand the setup the OP has.  QSM is a single loop, which means it should be fine storing it in that loop.  But the OP's last post points to them actually using a QMH.

Patrem1, Please post your VI so we can understand what your current situation is.

---

IN the deepest darkest corners of the LabVIEW wild there exist an abominable beast that is part QSM part QMH.

Spoiler

That critter get feed from an event handling loop or will on occasion eat its own tail. It actions are chaotic and there is no way to predict it next move or tell where is or has come from.

Beware the Beast!

Ben

[crossrulz]

---

@Ben wrote:

IN the deepest darkest corners of the LabVIEW wild there exist an abominable beast that is part QSM part QMH.

---

Abominable is correct.  I know the beat you are referring to.  And it is sounding a lot like the OP has one.  Unfortunately, the only real way to deal with it is to completely destroy it and use one of its parents, which one depends on the application.

[Patrem1]

I would need to do some formating before posting my Vi and I'm using fonctions from the 'Vision and motion'. 

But my current situation is like this example :

https://forums.ni.com/t5/Example-Program-Drafts/Queued-State-Machine-with-User-Input/ta-p/3497450 

My error I assumed this was named a queued state machine, it is a queued state machine with user input. 

So you're saying this is a abomination or it's okay?

EDIT : So to be clear at first I had only a 'Queue state machine' that I'm trying to change to a 'Queued state machine with user input'.

[deceased]

---

@Patrem1 wrote:

I would need to do some formating before posting my Vi and I'm using fonctions from the 'Vision and motion'. 

But my current situation is like this example :

https://forums.ni.com/t5/Example-Program-Drafts/Queued-State-Machine-with-User-Input/ta-p/3497450 

My error I assumed this was named a queued state machine, it is a queued state machine with user input. 

So you're saying this is a abomination or it's okay?

EDIT : So to be clear at first I had only a 'Queue state machine' that I'm trying to change to a 'Queued state machine with user input'.

---

This depends on what the interactions are from the event loop as well as how your states are set up in the state machine.

If you think about it, you are creating a race condition between your normal state to state activity and the events.

If you have a STATE B which transitions from STATE A you have to account for the fact that you might interrupt with an EVENT state between them. This event state best not try to send you on another code path, or alter any of the STATE info associated with STATE A, because next iteration of your STATE MACHINE is going to dequeue and send you to STATE B anyway (since it was enqueued in STATE A but the EVENT was enqueued before it).

In short it can work, but only in very well managed/configured scenarios.

0xDEAD