queued state machine architecture question

[tiho]

Hi

I would like to understand the Labview queued state machine architecture in details. I use in my application this structure with event structure in the producer loop.

I took the theory from this link:  https://decibel.ni.com/content/docs/DOC-32964

On the fig 1 there is an example of this architecture. I have the producer and consumer loops but I haven't the subVI Processes marked with point 4.

On the fig. 3 it is the same. I have the event structure in the while loop, state machine loop but I haven't the processes marked with point 4.

Could you please explain what does it mean exactly Process 1, Process 2, Process 3 from fig. 3.

Regards

[mikeporter]

Those are just dummy VIs that are operating as placeholders showing where you would insert the code that implements the bits of code for your application.

Mike...

[RavensFan]

Those subVI's or processes are whatever you want them to be.  You don't have to have them if you don't need them.  They could be some other process such as continually monitoring a DAQ card.  Maybe something like a TCP/IP communication process that can monitor and take commands from external programs.

[Ray.R]

Try to think of this architecture as a means to implement a dynamic state machine which allows the software to change the execution of the states based on decisions or events that occur while the code is running.  For instance, if event "A" occurs, then add a bunch of "steps" or "states" to the existing list.  The way you use the Queued State Machine can allow you to place the new states immediately after hading the event, or somewhere within the states, or appends them (states) at the end. 

Let's say you have event or a decision "B" that removes the rest of the states (ie: stop a test), but you want a graceful shutdown, you can clear the queue and add the appropriate states.

The processes in the example are just to show that the code can be flexible, but you have to code the behaviour for your software.  The beauty, depending on how you implement your code, is that you can almost "script" how the code should run.  You can even be a little clever and add predefined "scripts" to provide added flexibility.

Once you go through your first code with a Queued State Machine, you will unlikely go back to past architectures..  Well... maybe except when you write your CLD exam... 

[mikeporter]

The point that Ray makes about scripting is a good one. If you decide to.move in that direction give some thought to what you name things so the resulting script steps read naturally.

Mike...

[tiho]

Hi

Thank you for your answer. In my case I have one producer loop with an event structure inside. For each of my 5 devices I have 5 different while consumer loops. The connection between the producer loop and each consumer loop is made using queues.

On this way I have all components shown on fig. 1 from the link mentioned above without using the additional processes marked as number 4.

Regards 

[Ray.R]

I try to avoid having more than one consumer loop.  Otherwise, it can get a little crazy..

I do not know why you need a separate loop for each of the devices.  If (for some strange reason that escapes me) you do need to implement that, why not consider dynamic VI's (ie: daemon)? Do not confuse the sub-processes (or sub-VI's) as being additional loops.  There is only one consumer loop in that example and should only be one producer loop, which may have one or more processes.  Think of it as a group of people in one room as having a common objective.  They may have individual or common tasks, but they are within the same room and work together.  They are not involved with another objective that is taking place in the room next door.  Think of the room as the loop.  Imagine that in the other room, the people are producing the tasks for the people in the first room.  You may have a circumstance where the people producing the tasks are producing someting which is outside the objective of the first room, thereby requiring a second room.  In that case, you may need a scheduler and a means to inform the producer group of the progress or state of progress from each of the groups.  However, that is now becoming complicated and a proper architecture is imperative for success.  In that situation, the software implementation may be a producer loop with a queueed state machine that runs based on events generated from multiple sources (operaor, producer loop, consumer loops).  I would keep the implementation to a single producer even if it has multiple triggers or sources. 

Try to keep the code as simple and as basic as possible.  Multiple loops in parallel is a sign of something "about to go wrong", especially if there is timing related to each process (in this case device).

I hope the above did not produce confusion instead of clarity..