LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

QSM, queue based on current state

Solved!
Go to solution

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, 

0 Kudos
Message 1 of 14
(3,104 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 14
(3,094 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 14
(3,088 Views)

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. 

0 Kudos
Message 4 of 14
(3,083 Views)

@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


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 14
(3,074 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 14
(3,058 Views)

@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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 14
(3,051 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 14
(3,047 Views)

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'.

0 Kudos
Message 9 of 14
(3,045 Views)

@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

 

 

Message 10 of 14
(3,022 Views)