Reference a array of clusters from another VI

[jboden]

An example of what I am trying to do is have 10 vis all read/write the same DAQmx analog IO.  One VI creates the task then stays open in a loop always watching the channels then when the program shuts down it closes the task.

Now the 9 other vis need to also get the read/write  the analog io.  They can not use the same task so I need to pass the data between the vis somehow.  Things such as global variables and such will not work because the channels and such are dynamic based on configuration files.

This is a simple example of what I am trying to do.  The main concern is a Modbus/tcp device I have where I can only open the tcp link once and need to share the data amongst many vis.

[Mark_Yedinak]

---

@jboden wrote:

An example of what I am trying to do is have 10 vis all read/write the same DAQmx analog IO.  One VI creates the task then stays open in a loop always watching the channels then when the program shuts down it closes the task.

Now the 9 other vis need to also get the read/write  the analog io.  They can not use the same task so I need to pass the data between the vis somehow.  Things such as global variables and such will not work because the channels and such are dynamic based on configuration files.

This is a simple example of what I am trying to do.  The main concern is a Modbus/tcp device I have where I can only open the tcp link once and need to share the data amongst many vis.

---

Bad, very bad! Create one task that communicates with your device and using messaging as suggested to instruct this task what to write to your device. What you are proposing is almost certainly destined to fail due to race conditions.

[nathand]

There are multiple ways to handle this situation, almost all of which will probably be better than trying to update front panel values.  Here's what I did in one similar situation, and I'm providing this as an example with no intent to suggest that it's the best way, but it was convenient for me.

I had a single VI, containing two loops that ran constantly and handled IO to several devices.  One loop for outputs through a .NET component, the other for inputs.  The devices were all configured to send UDP packets at regular intervals with the latest readings, and the input loop waited for those packets to arrive. 

Any time some part of the code needed to set an output, it put a request in a queue.  The request included the new value and the module, slot, and channel number of the output.  The output loop just waited for requests and processed them as they arrived.  For further ease of use, I wrapped the enqueue in a VI that took in an enumeration describing which output to change and formatted the request, so that if I moved an output to a different module or channel there was only one place to update it.

When a UDP packet arrived with new inputs, it updated values stored in an action engine that could be read from any other part of the code.  Internally the action engine formatted the raw inputs into a large cluster so that it was possible to unbundle a logically-named input.  Again, if an input moved to a different channel, I needed update it in only one location.

[jboden]

Thanks all.  That is pretty much my intent.

One VI that starts the output tasks and waits for notifications from other VIs to set outputs.  That way I can notifiy that central vi from anywhere without knowing anything about it.

Would it work then to also toss my inputs into the que from another loop in the same main vi then I can always veiw them from anywhere by looking over the que?

[nathand]

No. A queue is good for many-to-one communication. For the inputs you have a one-to-many situation: one source, many recipients. A notifier can work here, or a functional global as I described. A queue does not because only one receiver can dequeue an element.

[jboden]

Perfect! Again thanks all for your help.