Channel Wires (Asynchronous Wires) Discussion

[OlivierL]

I was very skeptical when I first heard about those channel wires for the first time last March. After checking it out and reading this thread, I am still of the opinion that those wires would not help me or my team program better applications nor to program faster. As others pointed out, these do not offer any benefit in applications where VIs are dynamically launched which is the main reason I need to acquire the same reference multiple time in the first place (or use FGV, DVR, ...). Otherwise, I can acquire the Queue Ref or the User Event outside of parallel loops and respect the dataflow paradigm by passing the reference.  Anyhow, I am very curious to see what others might do with them.

 

This being said about development, I could see a benefit to this tool for debugging, like CraigC suggested. If I could, at run time, select a Queue or User Event on a wire and then visually see who is enqueuing/generating event, I think that this could save me time.  Imagine a "Highlight execution" that is only activated when data is produced/consumed to/from the selected Queue/Event, lasts for a few seconds until the data gets onto this "Channel Wire" that appears on the BD and then continues the highlight execution for a few seconds on the consumer side, again with the "Channel Wire" appearing momentarily to visually show the "real" dataflow.  Alternatively, if those wires could be displayed automatically, during debugging when the execution is paused, to see at run time every VI that currently holds a given Queue reference or Event reference and real-time consuming/producing, that could be a good ally to troubleshoot communication problems.

[Jordan Kuehn]

I was very skeptical when I first heard about those channel wires for the first time last March. After checking it out and reading this thread, I am still of the opinion that those wires would not help me or my team program better applications nor to program faster. As others pointed out, these do not offer any benefit in applications where VIs are dynamically launched which is the main reason I need to acquire the same reference multiple time in the first place (or use FGV, DVR, ...). Otherwise, I can acquire the Queue Ref or the User Event outside of parallel loops and respect the dataflow paradigm by passing the reference.  Anyhow, I am very curious to see what others might do with them.

 

While perhaps not relevant for your applications, I am still quite intrigued by the loosely alluded to cross-platform nature of these "wires".  If communication across platforms was as easy (and much safer than) using local variables I see a great benefit.  One big hurdle with cRIO programming comes about when a host computer is needed.  Some of the new platforms mitigate this need, but don't eliminate it.  If I can run a (LV) wire from a cRIO to a host machine without doing any configuration and have a loss-less transfer mechanism implemented I would be quite happy. Sure I can do the same thing with streams (or any of the raw TCP communication methods), but they can be clumsy and need to be wrapped with auto-connect logic to handle real world situations.  We use a high level language for many reasons, but abstraction is near the top of the list.

Edited August 21, 2015 by Jordan Kuehn

[OlivierL]

If I can run a (LV) wire from a cRIO to a host machine without doing any configuration and have a loss-less transfer mechanism implemented I would be quite happy. Sure I can do the same thing with streams (or any of the raw TCP communication methods), but they can be clumsy and need to be wrapped with auto-connect logic to handle real world situations.

So I assume that this would be similar to a (buffered) network shared variable that automatically adapts to type (vs having to configure it in a separate window) and possibly buffered depth.  From a representation on the BD, however, how would that translate to any gains? 

 

I think your point is valid if we take it to a system level design, where relationships can be drawn at a higher level and where the Host and cRIO are both "sub VIs" at the system level representation.  But then again, the caveats I see is that I will likely have multiple such communication methods (so many wires between the two targets representation) and again, why can I not acquire the queue/stream/event on the system level diagram and pass a reference using dataflow to both top level VI (Host and cRIO).  I think that this could help the design process, if the same Queue reference could simply be passed to both targets and to let LabVIEW handle all the complex TCP/connection/encryption/authentication for me.  That is awesome.  However, does it really need to be "asynchronous" wire that does not follow the data flow paradigm on the block diagram and crosses structures boundaries differently from any other wire content?

 

Maybe hovering over a Queue or a right click menu option could allow you to see what other VI have access to the Queue including every target and quickly identify any Enqueue/Dequeue operation done on the given reference. This could be offered at design time as well since the code is already compiled.

[ShaunR]

I think your point is valid if we take it to a system level design, where relationships can be drawn at a higher level and where the Host and cRIO are both "sub VIs" at the system level representation. 

 

That's what I mean by the Channel Wires are in the wrong "View".

 

It think also there is also a bit of imagineering going on too. Usually when we talk about cross platform we simply mean that code can run on another platform. LabVIEW is a cross platform programming language in that it runs on Windows, Linux and a whole host of other platforms. ,Cross platform compilers etc I wouldn't be surprised if cross platform just means it will be supported in the others in the same way that some property nodes are applicable in one platform but not another. I'd like to think that it is the start of a new technology that means we can control other machines just by looking at them and thinking really hard, though

[sth]

On August 18, 2015 at 10:35 PM, JackDunaway said:

I have heard anecdotally Tony Vento "invented" the "LV2 Global". Can you tell a story about what you remember from this time? I was thinking about Ninja Turtles and Ghostbusters this decade in the 1900's, but just like then, ears still perk for a good story.

Came across this comment looking for something else and a little late, but....  I know that Greg McKaskle was discussing this as a standard technique in late 1994.

http://info-labview.org/ILVMessages/1994/12/02/Info-LabVIEW_Digest_1994-12-02_005.html