Interrupt a an unfinished state in a QSM

[t.mcgregor]

Hi All,

I am starting a new application using the QSM code as per example

https://decibel.ni.com/content/docs/DOC-14169

The general question is I have a state which is waiting for data from a device (lets call the state wait for device data). Once in such a state as the dataflow does not continue until data is recieved from the device by design the state will wait indefinitely for data.

What is the best way to exit the state to allow new states which are generated via the HALT, OR STOP stop buttons in the UI loop to immediatly interrupt (or reasonably quickly interrupt) the wait for device data State

Is the best wayto create a timeout on the wait for device data State? The timeout would exit the current loop iteration and porbably queue the wait for device data State, (but this of course would be overwritten by HALT or STOP commands from the UI loop)

Im sure there must be a better way? My brains frozen on this....

Thanks

[crossrulz]

---

t.mcgregor wrote:

Is the best wayto create a timeout on the wait for device data State? The timeout would exit the current loop iteration and porbably queue the wait for device data State, (but this of course would be overwritten by HALT or STOP commands from the UI loop)

---

That is the best way.  Otherwise you have no way to checking for the HALT or STOP.

[AKA_TG]

.. and by the way using the timeout in an event structure has advantages over simple loop polling (although it esssntially is doing the equivalent of polling.)

The advantage is that when the user presses the stop button it is seen buy the UI loop immediately.

In traditional loop polling this is usually not the case, unless one knows to use using the primitive event "wait for front panel activity."

[t.mcgregor]

Hi,

Thanks.

So a good option would be to use a EVENT structure within the wait for device data State. Make the timeout event enqueue the wait for device data State again but allow this to be prioritised by State enqueed by the HALT or STOP button press in the UI loop.

It works and looks like a great idea.

If I have many "wait" states is it ok to use event structures for each wait state?. I mean is there anything fundamentally wrong with using many event structures in a state machine loop.?

Thanks

[crossrulz]

I would recommend against using multiple event structures.  There are a lot of caveats with using multiple event structures.  The most common issue is if you have the "Lock front panel until event case is complete" option turned on.  You cause an event, but have no way to get to the event structure that is looking for the event because it is buried inside of a QSM case that can't be reached.

[MarcDub]

There is another way If you "wait for data" state usesa notifier or a queue, You can interrup the wait by releasing the notifier or the queue reference. It would then generate a corresponding error that you can handle accordingly.

[AKA_TG]

The best way to program states is to have only one wait state.

This defines the concept of what the state machine is doing. Its usually waiting for something to happen right?

It also allows you to handle waiting in just one place.

Having more than one wait state can be disastrous down the road, although it may work in the short term it is not recommended. If designed properly only one event handler should be needed.

Use a while loop with a case structure and and shift registers to allow all kinds of complex operations to be easily handled in one place.

[JÞB]

Lets bring this back to the design table.  Your proposed QHM has a state definition problem.  I'll use an analogy to make my point easy to understand.

in the analogy the QMH is a state machine to visit grandma.  

First we make sure we are presentable, Grandma hates it if we don't shave right? (init process)-

Then we drive to grandmas house (Long uniteruptable process)

Have cookies (Its why we visit grandma right?)

Go home

Write a thank you card  

You get the idea right?.  There is a problem with the state "drive to grandmas house"  It might be fine if Grandma lives a few blocks away but if she lives a long way off we need to do something a little different.  We need to bring a small child along in the back seat.  Every so often he will pipe up and say "Are we there yet? are we there yet?.. and we redefine the state "Drive to grandmas house" into a succession of "Start Drive" and "Wait for drive to be over" States that queue to self untill either the goal is met (We get to grandmas house) or something else interupts us (I need to Pee!)  If "I need to pee", gets raised along the drive we can service that request and resume.  The Bridge is out! could cause you to abort the trip and send an appology instead of the thank you.

Does that help clarify things?

[johnsold]

Now Jeff's Grandma understands what he does!

Lynn

[JÞB]

---

@johnsold wrote:

Now Jeff's Grandma understands what he does!

Lynn

---

She's known for quite some time.  Who do you think taught me?  My G-Daddy!- he gave me good advice about shaving too.

Spoiler

Don't take the analogy too far though.  you might notice that the simplest implementation is that I don't Flush after peeing  My grandmothers would not have been fond of that bu,t the queue is happy.