Decoupling two nested state machines?

[joptimus]

Hi guys!

Is it possible to decouple two state machines that are nested within each other? Meaning there is an outer state machine (do measurement 1..n, exit application etc.) and inner ones (program control of how to perform said measurements).The outer state machine accepts commands from the UI loop, the inner state machine passes commands to instruments.
 

I would like to make my code more modular, hence the question.

I have attached a screenshot of an example. The middle structure is what is bothering me.

Edited August 8, 2016 by joptimus

[austinman]

Have you considered simply moving the Producer Loop for Measurements into it's own loop? You could have 6 separate While Loop, or possibly combine the Instrument Loops into one loop (need to think that over). If you haven't done so already take a look at the Queued Message Handler template that ships with LabVIEW and the Continues Measurement and Logging sample project. Based on what you have posted I think you will find the template educational, as you are pretty close to what it does. The loops have different names, but the concepts are the same.Hope this helps.

[joptimus]

No I haven't actually. It is an interesting concept, but wouldn't there be performance considerations if I ran so many loops at once?

I would have:

1. Event handling loop
2. UI message loop
3. 5 loops, one for each measurement (like the acquisition and logging loop)
4. 4 loops for my instruments

That gives a total of 11 loops that would all be running in parallel, some idle, some doing something.

[Tim_S]

5 hours ago, joptimus said:

That gives a total of 11 loops that would all be running in parallel, some idle, some doing something.

Only 11 loops?

Your computer is doing a lot of things at once with just the operating system. The question is really 11 loops that need how many resources. If each loop takes a couple percent CPU usage every 100 msec, then you can have a lot of loops running in parallel. If you have two loops that needs 100% CPU usage for 30 seconds and they have to run at the same time, then you'd have a problem. Loops running in parallel have to "play nice with each other".

[ensegre]

Thread starving might become an issue eventually, but only if there are some thread-locking calls, e.g. orange CLFN. But anyway, I would give some thought about whether the proposed architecture is really sound and couldn't be factored out differently. For example, would it scale gracefully if a fourth, a fifth instrument and so on will need to be added later on? In the middle level, why a cluster of queue references needs to live on the shift register? How does the producer loop address the right queue, and how easy would it be to add more commands/instruments? What would be the stop conditions of the inner and outer while? Is it ok that the each "measurement" command produced by the top level translates to independently executed instrument commands, or is there some sequentiality and interdependence to be accounted for?