State Machine with Multiloop Communication

[AYanez]

Good day , after much thought and not find a solution for myself that satisfies my judgment , I come to the forum for help.

I am designing a system, but between my requirements is the suspend the data acquisition based on external digital signals.

The states would be:

Init
Start
Acquire
Stop
Exit

The idea has come to me is to do the following :

Using a loop containing a Queue with Shift Register Timeout connected to the shift register and having an Enum : My idea is to make transitions based on shift register having the Enum as a simple state machine and when the state is enabled Acquire Timeout for acquiring data temporize while the Dequeue Element hope for some appropriate message to stop the test, something like this with the difference that instead of string would be an Enum:

However I have come to the forum to see the opinion of more experienced users because I want to find the most optimal solution , hope someone can help me to get the best solution,  if you require additional information gladly I will provide. Thanks in advance.

[Norbert_B]

You should take a look into the Queued Message Handler which is accessible in the "Create Project" assistant in LV 2013. I think this template was already added in LV 2012, i doubt the presence in previous versions.

Norbert

[AYanez]

Hi Norbert, I have used this architecture for example to handle the UI events, but in my case I need that the Acquire case stay working until I send a message to stop, my doubt is if is correct enqueue elements inside a consumer case, my main issue is that the acquisition time must be variable with a constant or control so for that I thought in a shift register.

Perhaps I have misunderstood the operation of the template for such cases, if you could give me a small example I would greatly appreciate it, thanks for the help, I really want to learn the best way to resolve such cases.

[Bob_Schor]

One (good, in my opinion) way to do this is to have three loops running in parallel.  The middle loop is your Queued State Machine, which basically handles "commands" such as Initialize, Configure, Acquire, and Stop.  The top loop is an Event loop driven by Front Panel controls -- I'm thinking of a big button that says "Acquire", and a bigger Red button that says "Stop".  All the Event loop does is to put the appropriate Command on the Queue for the State Machine.

The third loop is your Acquire loop.  I'm assuming that data acquisition is timed, "more important" (higher priority) than commands.  Configure it to take a point every N ticks, and do whatever it needs to with the data.  Have some form of "write-once" structure, such as a Stop Global Variable, a Stop Single Process Shared Variable, a VIG (or Functional Global Variable) wired to the Stop button of the Acquire loop.  [You could also use a Local Variable, but they tend to be harder to find when you need to debug your code].  When the State Machine decides it is time to stop acquisition, it "sets" the appropriate Stop condition for the Acquisition loop (e.g. it wires a True into the Global or Shared Variable, or sets the VIG to True).

One nice thing about this design is that it separates Front Panel processing, Command Processing, and Data Acquisition into their own parallel loops.  This can lead to code that is (a) easier to understand, (b) easier to debug, (c) easier to write, and (d) more likely to work the first time.