state machine and queue integration

[yenknip]

I have a sub VI that will use a state machine loop to control a furnace, and use a de-queue loop which can receive commands for the furnace, but otherwise the furnace looks after itself in its state machine.

I have been trying to think of the best way to implement this but can't come up with anything, or even if a re-structuring of my sub vi needs to be done

Things I need to take into account are that the next queue item won't dequeue until the state machine is ready to take it, unless the quit command is queued - in which case I need to keep polling the queue to see if the command has been sent

I have thought of 2 possibilities:

- I could put the dequeue element block inside the state machine and having a 'get next item' case, but then each iteration would need to check for the quit command in the queue somewhere

- the dequeue loop could place each item it receives in an array so as soon as quit is received, it can act accordingly, but the array would need to be referenced by a variable in the state loop, additionally the quit would need to be passed to the state machine, creating the same problem I already have

If anybody has any thoughts, I would be glad to hear them

[RavensFan]

It's a little unclear from your picture and description as to exactly what you are trying to do.  I don't see where you are doing the enqueueing.

But despite that, maybe this can help.  For something like a quit command where you need it to act immediately, remember that you can enqueue items to the front of the queue so that it is the next to be acted on no matter how many items are in the queue.

Other possibilites would be to use a notifier or even a carefully used local variable to allow one loop to signal the other about a quit command that is separate from the queue.

[Ray.R]

Have you looked at some examples of Queued Event structures or Producer / Consumer loops?

Can you show where you create your queue(s) and Enqueue your values?

RayR

[yenknip]

Items are enqueued in other VIs and the queue reference is passed around. Multiple commands can be sent at a time so a queue structure is most sensible.

Additionally, the furnace is on a moveable carriage so it can move between the process chambers to keep downtime to a minimum. The furnace can be in various states such as 'go to position', 'move up', 'move down' and so on. The up/down command cannot be processed until the furnace is under the process chamber, so a state machine is most sensibly used.

Commands should not be processed by the state machine until they are ready. Unless a Stop condition was sent. My problem was how to share commands between the queue loop and the state machine loop and jumping important instructions to the top of the queue without having to poll the queue to see if stop had been sent.

I have solved this myself after sleeping on it 🙂 I shall post it on the off-chance anybody else finds it useful.

The overall structure is a state machine, with a bit of preprocessing on the queue. The queue is emptied and appended to an array at the beginning of the state loop, each new element is checked to see if it is a stop command, in which case the 'current state' shift register is overwritten to stop. If not, the command is queued up in the the array, If nothing has been added to the loop, then it continues to process the current state

[Jarrod_S.]

Glad you found a solution! Another common way to shut down a loop that depends on a queue to receive commands rather than sending a Quit message is to simply close the queue reference. The next time you try to dequeue a command, you'll get an error. So your Quit case of the state machine would actually be an error case around the inner case structure.

This also alerts all other processes enqueing commands that the state machine is no longer active, because they'll fail to enqueue. The advantage of your solution is that it's a little easier to restart the state machine after it's processed a Quit command, because you don't need to recreate a queue ref and pass it out to the whole system.

I would also recommend for your wiring convenience and code clarity to keep the States Array local to the Check Furnace Queue VI, rather than pass it out to the state machine. It doesn't seem from your pics or description that the state machine needs to know how the states are cached or dequeued, just that there's a next state coming. You can use a While Loop set to run once with an uninitialized shift register in the Check Furnace Queue VI to store the states, or if you have LV85 you can just use a Feedback Node without any while loop.


Message Edited by Jarrod S. on 05-13-2008 08:27 AM

[yenknip]

---

@jarrod S. wrote:

I would also recommend for your wiring convenience and code clarity to keep the States Array local to the Check Furnace Queue VI, rather than pass it out to the state machine.
Message Edited by Jarrod S. on 05-13-2008 08:27 AM

---

It's funny you say that because I came to the same conclusion 5 minutes ago 😄

I've just browsed the forums, and found what you said about the feedback node instead of a non-init SR, I haven't even seen them before let alone used them! Still, I'm happier using SRs. Thanks for the info though 🙂