Queued message handler, default case/message?

[joptimus]

Hi,

I've started to implement the QMH design pattern for my application:

• Producer
  A state machine that implements my algorithm:
  Move actuators, send commands to a camera, adjust parameters etc.
• Consumer
  A state machine that sends low level commands to the devices depending on the task at hand

But now I have a problem:

I would like to continously check and display the positions of the actuators, like a default case/message. Depending on the positions, different actions should be taken. If I were using an event structure in the producer loop, I could use its timeout function, but in my state machine I cannot do that.

Example in the producer loop:

1. State "actuator move to position" -> actuator moving
2. Check position every 100 ms until target reached <---- this would be my default case
3. After position is reached, take a picture
4. Exit

I admit, I still have a little trouble differentiation between states and transitions. Currently, my state in the producer loop state machine where I send the "move" command and the target positions, is named "move to xy". It executes just once. Maybe it would be better to have a state "moving now" that reads the position and transitions to the next state (for example "stopped") once the target is reached?

Any thoughts on this please?

Thanks!

[Bob_Schor]

If you have a Queued Message Handler running your State Machine, there is nothing preventing you from creating a "Check Position" State.  One way to deal with this is to create a separate (parallel) "Timer" loop that does nothing but fire a "Check Position" message every 100 msec (you'd have to branch the QMH's Queue to this loop so it could send the message).  In your QMH State Machine, you might not want to always Check Position every 100 msec -- to deal with that, you could have a Boolean "Check Position" on a Shift Register that you set True when you do want to Check Position and false when you do not.  Now when the Check Position Message is received, it checks the Check Position Boolean on the QMH's set of Shift Register and does nothing if this is False, and whatever you need it to do if it is true.  Very time-efficient.

Note that if you want to use an Event structure for your QMH, there's no reason you can't create a User Event whose element is your Message Cluster and use what you might call a User Event State Machine as the basis for your "Event QMH".  With this change, you could use the Event Timeout to schedule Check Position (I would still say "Put Check Position on the Event Queue, let the State Machine handle it" rather than doing the Check directly in the Timeout case, but that's just my gut feeling ...).

Bob Schor

[crossrulz]

I would have your consumer loop just constantly reading the position.  Assuming you are using a queue, just use its timeout and store the positions in a global variable.

[Sam_Sharp · Accepted solution]

---

But now I have a problem:

I would like to continously check and display the positions of the actuators, like a default case/message. Depending on the positions, different actions should be taken. If I were using an event structure in the producer loop, I could use its timeout function, but in my state machine I cannot do that.

---

Why not? You can set the dequeue timeout so that if no message is received, it goes to a 'timeout' case of your QMH which is where you can check the positions etc.

[joptimus]

Didn't know I could to that! That is exactly what I need, thanks!

[JÞB]

And, I'll chime in.

Sometimes two loops is not enough.  

Your application sounds like a SCADA system.  To implement this one would normally create a process (read that as action engine or Class) for each resource that can serve data to whatever process controls the overall operation.  

User Interface would be one of those processes.  Usually this loop is Event Driven.  Hey, Users do things, based upon judgment about feedback from the system, that involve more intellegence than a computer has!  Interaction with the user almost needs to be event driven!  BUT, the UI Event Loop should not be taking direct actions-  It should send commands to the various resource loops to modify their states.

Or to put it simply, the producer produces commands to the consumers abstracting the implementation details.  The consumers should be handleing the details of HOW.

[Gregory]

---

@Sam_Sharp wrote:

---

But now I have a problem:

I would like to continously check and display the positions of the actuators, like a default case/message. Depending on the positions, different actions should be taken. If I were using an event structure in the producer loop, I could use its timeout function, but in my state machine I cannot do that.

---

Why not? You can set the dequeue timeout so that if no message is received, it goes to a 'timeout' case of your QMH which is where you can check the positions etc.

---

To build on Sam's suggestions, the default string when a timeout occurs is going to be "" (two pairs of quotes for an emptry string), and the default enum will be the first item in your enum list. When I am using strings I often make the "" empty quotes do a repetitive action, and always - always - use the default case (type in Default and it should not have quotes around it) to catch typos. It will save you a lot of time, just a one button dialog inside the Default case that tells you that you made a typo. Also add a couple seconds wait if you want so you don't get caught in a loop 🙂