Channel wires and aggregate controls

[sth]

This may have been obvious to most of you, but it stopped me in my tracks.

I was trying to setup a system where I had 16 asynchronous VIs communicating with some combination of 4 other synchronous VIs and decided I could just pass an array of channel wires to each of those asynchronous VIs and at run time change the configuration of which channels they would actually use out of the array.

However, it seems that you can have a FP channel wire and pass it but can not put that channel wire in an aggregate control such as a cluster or an array.  I can generate channel wires in a FOR loop and send one to each asynchronous array but I would need 20 inputs on some of these VIs to handle my issues.

I think I will use something like a shared memory (DVR) mechanism for my needs.  It more closely emulates a C program that used to do this in ancient times.

[DerrickB]

Channel Wires have some special treatment in LabVIEW and the compiler to get them to work the way they do, which is completely incompatible with normal dataflow paradigms and they aren't to be thought of as data that can be aggregated and passed around like other values in LabVIEW.

Every terminal and tunnel for a Channel Wire gets treated as a control/input by the compiler. Channel Wire indicators that may seem like something flowing out of a SubVI instead become inputs to the SubVI during compilation. A little thinking about this makes it clear why there's another forbidden behavior for Channel Wires: being passed through structures; both tunnels would become inputs into the structure's diagram(s) so now there are 2 inputs to the same wire segment.

Somewhere there are some great discussions from AristosQueue on these forums and lavag that go into some better analogies that my quick googling was unable to find but I'll add them here if I come across them later today.

[jfalesi]

So the solution is to pretend you're writing C code? I learned LabVIEW so I wouldn't have to learn to write C code...

[Ludwig72]

You have learned LabVIEW, so there is no need to ever learn anything else in your life. 😄

[IlluminatedG]

I'm not following the writing C analogy.

They're a feature that have rules about their usage resulting from how they're implemented.

[sth]

---

@jfalesi wrote:

So the solution is to pretend you're writing C code? I learned LabVIEW so I wouldn't have to learn to write C code...

---

????, this was just using a basic architecture from an ancient C code program.  The architecture was just to communicate with a bunch (20) parallel processes.  There is no pretending here, I can write C-code and LV code, and about 20 other languages (most of them dead! Algol anyone?)  Program architecting needs to be done in whatever language you chose.  If you write LV with out an architecture there will be issues.

[sth]

Derick, Your description was very helpful as usual, but since I can put a bunch of controls in a cluster and pass that to a subVI.  I should be able to put a bunch of channel wires in a cluster and do the same.

When I unbundle the channel wire terminals they are date inputs (controls) and do not pass through structures.  But I can see that this is messy and the implementation might cause more headaches than it solves.

(I don't follow the C-writing analogy either)

[jfalesi]

Agreed, but the context switching (from LabVIEW to text based languages) hurts my brain.

[jfalesi]

---

@sth wrote:

This may have been obvious to most of you, but it stopped me in my tracks.

I was trying to setup a system where I had 16 asynchronous VIs communicating with some combination of 4 other synchronous VIs and decided I could just pass an array of channel wires to each of those asynchronous VIs and at run time change the configuration of which channels they would actually use out of the array.

However, it seems that you can have a FP channel wire and pass it but can not put that channel wire in an aggregate control such as a cluster or an array.  I can generate channel wires in a FOR loop and send one to each asynchronous array but I would need 20 inputs on some of these VIs to handle my issues.

I think I will use something like a shared memory (DVR) mechanism for my needs.  It more closely emulates a C program that used to do this in ancient times.

---

Would this be a use case for the AF, i.e. dynamic multithreading?

[IlluminatedG]

This just sounds like a case of not using channel wires and implementing the underlying notifier or queue (or anything else) behavior directly. Frameworks like DQMH and AF certainly provide a model of performing scalable async processing along with the messaging APIs but they can also bring a lot of design baggage with them to refactor into existing applications. If you can start with one of those frameworks and develop following their intended designs and usage then they're certainly a great fit for this.

I get you wouldn't expect the limitation of how channel wires can be passed around ahead of time, but that's the rule due to how they work under the hood and if that limitation means they don't work for you... then they don't work for you. It is possible to pass channel wires into start async calls but you wouldn't be able to handle an arbitrary number of channels.