State machine with different acquisition modes/loops

[Gregory]

---

@irPaul wrote:

To find the problem I have constructed a minimal working example (see attached) of two parallel while loops; one with Vision Acquisition and the second displays an incrementing number. If I highlight the execution, it is clear that the first loop is only repeated and the second one is never executed!

I haven't found a solution for this yet, so any input on it is appreciated.

---

Hi Paul,

You have actually constructed two serial while loops. The one to the right depends on 3 values, the final value of the stopped boolean, the error cluster, and the iteration count. None of these values are passed on until the first while loop stops execution. This might seem annoying, but think how silly it would be if the second loop didn't wait, and just started guessing at what the values could be! 

This is why we have a couple different ways to communicate data between loops. You have noted the queue, which does not get wired through one loop and into the other, but gets branched off into both loops. That is why both loops can run at the same time. Some other options are notifiers, local variables, global variables, and data value references.

[Gregory]

---

@irPaul wrote:

Schematically depicted, it would look like below. Is this way of thinking correct? (Before I redesign everything again)

---

I'm not sure I've ever seen a LabVIEW diagram represented with text before! I think you have the right idea using the queue, but I'm not sure what you mean by "action" and I'm not sure how you plan to use an event structure in there.

[irPaul]

---

@Gregory wrote:

I'm not sure I've ever seen a LabVIEW diagram represented with text before! I think you have the right idea using the queue, but I'm not sure what you mean by "action" and I'm not sure how you plan to use an event structure in there.

---

With "action" I mean the data process that should be performed. As you might have seen in my first VI, the data process, or "action" as I called it here, is selected by the user using the buttons on the front pannel (Calibrate, measure, pause and stop - default state is Idle). I have named them "action" rather than "state" according to Bob's initial reaction about it being an "action engine" instead of a state machine.

Essentially I have a producer/consumer architecture now. My thought process was that the consumer loop should apply the appropriate data processing, in accordance to the user input. To make a sort of switchcase scenario that responds on user input (user clicking the button), I wanted to nest the event-case structure as is used in the state machine to do so.

(In other words, "action" is the enumerate of states that the system can be in).

I hope that clarifies it!

[Gregory]

I see now. Yes, the event loop should be able to catch any time you change the data processing action. And I assume your data processing will go in the timeout case of your event structure?

[irPaul]

Indeed, that was the idea.

I have implemented it and it works fine. In the end the architecture to handle the different states is not different but the producer/consumer loop is definitely a lot neater and more organised. Thanks for the input! 🙂