LabVIEW
improve my design pattern.
First, this is about your design, not your design pattern. A design pattern is a design that's reused by the masses.
Producer\Consumer is a design pattern.
The way you use the Producer\Consumer, it leans more towards a Master\Slave design pattern. PC is usually: P producing data, C consuming it. MS is: M producing commands, S executing them. Of course if commands are data, this is more or less the same thing, but the philosophy is different...
@labmaster wrote:
In this case, I have to use the copied local variable or functional variable.
Do I need to use a user or dynamic event function to communication with UI loop instead of only one local variable?
In summary, I am trying not to use local variable in flowing of logic.
A third option is value signaling properties. Those will set the value, and signal the producer's event structure.
I'd start the DAQ loop in parallel (but not dynamically), and communicate with it with user events. Maybe the slave (or actor) will write stuff in a data bus (FGV), or send it's data with user events as well (or just a signal that data was updated.
If it will work well or not depends on the details. Implementation details and requirement details.
Search LabVIEW like a graph! 
@labmaster wrote:
For example, when I sent the signal for re-initialize hardware and transfered the obtained data to loop3 from loop2,
two or three copied 'local' variables are enough for loop-loop communication.[...]
Do I need to use a user or dynamic event function to communication with UI loop instead of only one local variable?
[...]
But, is it acceptable to you that many loop-communication functions can be used in my rough design?
In general, the data should be queued together with command. That's why one of the most common designs is to use a Cluster with a String or Enum and a Variant as queue data with some variations. (Some prefer to flatten the data and use 2 strings, e.g. I prefer the Enum as Command as case structures becomes more 'automatic' and spelling isn't an issue).
That way it's easy to send both command and data in a generalized form to any consumer.
To return data you can use User events or a "Recieve-queue" with the same cluster idea.
/Y
Of course channel wires could make things easier, although they're 'just' layers around queues and other build-in functionality.
@labmaster wrote:
I use the enum as the command, too.
I would like to see the detail or example of "a Recieve-queue with the same cluster idea" you mentioned as the way of transfering data to the event structure.
That's going to sound very complicated, but it's not that hard. There are multiple ways to do it. Here's my take on it.
When sending the command enum (in a cluster) over a queue, also send a newly create queue reference. The receiver can get the command, and use the queue reference to send it's answer. The Sender can wait for the answer (with or without a time out).
The above situation is a bit funny in this context. If you make two loops, so the first loop doesn't stall execution, waiting for the second loop defeats that purpose. If this is acceptable, why use two loops in the first place?
The 'send' and 'wait for answer' actions can be separated, but in an event structure that is tricky, as it waits for events, not queue elements. The receiver can send it's results in a user event, but that is another pattern (not a send and wait for result).
In general it is a useful pattern for decoupling the code of the processes. This leans towards actor framework...
@Bob_Schor wrote:
- The LabVIEW Tools Network (pointed to by VIPM). There are several "systems" that have been widely adopted and praised, including the JKI State Machine and the Delacor Queued Message Handler (DQMH).
On this topic in particular, it might be helpful to know that currently (this month? so not much longer, but still) there is a free JKI online course about the JKI-SM. Usually this is fairly expensive...
Re the DQMH, Delacor have lots of online training materials that can be freely accessed (videos and blog posts etc) and there are quite a few NI Week presentation videos around covering the DQMH. I don't know if there's a freely available (now, or ever) course covering it, but I know several people (including Delacor) offer paid training.
