Channel Wires (Asynchronous Wires) Discussion

[AutoMeasure]

...And the super secret feature, the Asynchronous Wire...

 

What is this secret feature?  Sounds good just from the name.  Thanks.

[hooovahh]

Check out the last 10 minutes or so of the augmenting the right click presentation named:

 

2015 NIWeek_08_Augmenting Right-Click Menus in LabVIEW 2015_Stephen Loftus Mercer-Darren Nattinger.mp4

 

It can be found on the FTP site of NI Week videos:

 

https://lavag.org/topic/19154-ni-week-2015-videos/

 

It has lots of features, but the most accessible is the ability to write data in one place, and read it in another place, and have those two places linked by a wire that doesn't force data flow.  

 

Edit: Oh here's more.

https://decibel.ni.com/content/docs/DOC-41918

[ShaunR]

 

It has lots of features, but the most accessible is the ability to write data in one place, and read it in another place, and have those two places linked by a wire that doesn't force data flow.  

Woah, there pardner.

 

Apart from giving you many ways to confuse and shoot yourself and others in the foot. What problem do these "asynchronous wires" solve, exactly?

 

At first glance, it looks to me like a solution looking for a problem.

[hooovahh]

Apart from giving you many ways to confuse and shoot yourself and others in the foot. What problem do these "asynchronous wires" solve, exactly?

It's feedback like that, that I'm guessing NI is looking for.  

 

But if you were to ask R&D I think their answer would be something along the lines of how LabVIEW has some weaknesses when data flow isn't followed.  If I have queues being opened by name, it can be difficult to know where messages are being enqueued and dequeued.  With a Channel Wire you have the ability to trace back where the data came from.  Visually debugging can be easier.

 

It can probably confuse the hell out of new developers but honestly NI had catered to new developers in other ways, and I'd rather not hold back a language in favor simply because it is a concept that beginners struggle with.  It is a balance for sure.

 

While this technology fascinates me, the implementation is also interesting.  All done in G code, creating the VIs as they are needed, and keeping a cache of the ones already made.  Sure XNodes would have done this for you too, but if XNodes can be avoided, and still get the same (or similar) functionality I understand the design choice.  It opens the way for other developers to make other cool right click scripting tools.

[ShaunR]

It's feedback like that, that I'm guessing NI is looking for.  

 

But if you were to ask R&D I think their answer would be something along the lines of how LabVIEW has some weaknesses when data flow isn't followed.  If I have queues being opened by name, it can be difficult to know where messages are being enqueued and dequeued.  With a Channel Wire you have the ability to trace back where the data came from.  Visually debugging can be easier.

 

It can probably confuse the hell out of new developers but honestly NI had catered to new developers in other ways, and I'd rather not hold back a language in favor simply because it is a concept that beginners struggle with.  It is a balance for sure.

 

While this technology fascinates me, the implementation is also interesting.  All done in G code, creating the VIs as they are needed, and keeping a cache of the ones already made.  Sure XNodes would have done this for you too, but if XNodes can be avoided, and still get the same (or similar) functionality I understand the design choice.  It opens the way for other developers to make other cool right click scripting tools.

 

Leaving aside "what a wire means" in LabVIEW for now. There are two points I would raise here.

 

If data flow isn't followed. That's not a weakness. That is a consequence of breaking dataflow in a dataflow language.LabVIEW is inherently concurrent and has implicit sequencing but go ahead and use your GO4 templated framework - just don;t come crying to me about needing extra language semantics to get synchronization back again for an architecture where you've specifically chosen to remove what the language gave you.  

 

I spend a lot of my time writing little bits of code to remove wires. I remove them for three reasons.

1) Modularity-I can just plonk the VI on any number of diagrams and it will just work (get rid of init, do something, deinit).

2) Break dataflow - Encapsulate events, for example, into an API where each call is atomic and refnum free.

3) Diagram readability-More of a side effect.

 

I feel the example they show is rather contrived. Most of the time I would use such a system in different VIs because of 1&2 Generally I want to share data between processes, not individual while loops. Then the whole idea showing where the data comes from with a wire becomes moot and it is no different to what I usually use.....except more complex to create,, it seems.

 

That said. I haven't played fully yet. So I am open to being convinced with a killer application of them.

[d_laub]

My pet theory about the asynchronous wires is that they're a necessary feature for something big that hasn't been released yet.

 

The Channel webpage mentions they'll expand them to "cross-target" communication in the future.  I think that's the "killer app".  If you combine cross-target async wires with the Java-based runtime engine they alluded to at Wednesday's keynote, that might point to a big change in the portability of LV code.

 

My wild speculation is they might be working on the ability to transparently virtualize VIs across multiple targets.  Like, you make a simple producer-consumer VI using a channel, and the VI Server can split the producer and consumer and run them on separate targets (or even spawn thousands in the cloud for massively parallel computing) just as easily as running the VI locally.  It could run your data acquisition code on multiple PXIs, PCs, cRIOs, and cDAQs sprinkled all over as if they were all in the same chassis, and could dynamically shift the processing load around as needed.

 

Java runs on tons of platforms, which could allow them to run LabVIEW in even more places, and there are lots of great tools already for virtualizing Java applications, so they wouldn't even need to do the most difficult parts.

[infinitenothing]

Let me poke a hole in that theory. Async wires aren't necessary for anything. The functionality already exists as shown in the Getting Started guide.

[d_laub]

Well it's my pet and I'm keeping it :-P

[bbean]

Asynchronous wires seem to be an extension of the wireless wires I was working on with the Wormhole xnode.   The wormhole xnode would have had the wireless cleanliness of a local variable with the speed of direct wire.  Oh well.

 

 

 

 

Disclaimer: do not use this anywhere in your code...its just for fun

WormHole.zip

[hooovahh]

Disclaimer: do not use this anywhere in your code...its just for fun

This is kinda fun, it does a few things you don't see in XNodes very often.  That being said not being able to pass wireless data into our out of subVIs, or even structures is pretty limiting.  Thanks for sharing.

[eberaud]

Sorry but I just can't figure out what the picture represents on the 'receiver' side 

[bbean]

 That being said not being able to pass wireless data into our out of subVIs, or even structures is pretty limiting.  Thanks for sharing.

 

Still waiting on this front.  LabVIEW needs to move to 3d diagrams like CAD programs.

 

 

Sorry but I just can't figure out what the picture represents on the 'receiver' side 

 

https://en.wikipedia.org/wiki/Dalek

http://www.thedoctorwhosite.co.uk/dalek/

[hooovahh]

Still waiting on this front.  LabVIEW needs to move to 3d diagrams like CAD programs.

I was referring to the fact that Channel Wires can be pass into subVIs, and diagrams where your XNode implementation cannot.  The idea is you can then follow the data of the Channel Wire and find all those involved in generating or consuming the data.

 

Would a 3D environment help?  I'm not sure, what benefit does that give me?  It certainly adds another layer of complications, but organizational-wise I think it would be too much to work with.  Processors naturally have parallel operations with multi core work, FPGA even more so.  So having a 2D environment with parallel operations seems like a good design.  I guess if processors had another layer, maybe if each core of a processor was made up of N cores, then a 3D environment could be used and development might help write code for processors of processors.  But since the coupling between cores is not that big of a deal, and the compiler takes care of the FPGA side, even here I don't think it would be very useful.  Besides we only have 2D screens, lets wait to make LabVIEW 3D until we have holographic monitors.

[ShaunR]

Still waiting on this front.  LabVIEW needs to move to 3d diagrams like CAD programs.

 

This is something the hierarchy diagram (HD) has needed for a while. The HD could be so much more useful for navigating the architecture - an interface like the Firefox 3D view. It would mean I wouldn't have to visualise the bipyramidal architectures in my head (the flat diamond is all you can see) and give real insight into multi-level state machines. Double click and open a VI diagram.....it'd be great.

[Aristos Queue]

TL;DR: There are further developments that will layer on top of channel wires, but the hypothesis we are testing is that channel wires are valuable to write code faster (fewer mouse clicks than setting up other mechanisms mentioned above) that is more comprehensible to future readers of the code and more verifiable for tools like VI Analyzer or code review buddies. Feedback on the hypothesis is welcome. 

 

The goal with channels is to provide a visualization of the asynch communication code paths. Shaun may not see evaporating wires as a weakness, but most users do. Users generally, in our observation, do better learning code bases where the code on screen shows what's going on instead of implying what's going on. When data disappears into a queue/event/global/shared-variable/etc., we observe developers unable to keep in their heads where that connection goes. It also means it is impossible for developer to assert all of the points in the code that have their fingers on a comm channel. 

 

So channel wires depict the communication. They can run into subVIs. Most of them can be probed (probing is not something we added to all the channel types... we're still playing with how that debugging experience should work). 

 

The channel wires also give the compiler a chance to substitute the underlying communications mechanism on different targets. Queues are desktop specific; resource refs are FPGA specific. A channel that just expresses the protocol desired might be compiled one way on one target and another way on a different target with no need to re-code the subVIs.

 

We're also playing with wires that express connections across targets. No idea how that will turn out. 

[ShaunR]

Shaun may not see evaporating wires as a weakness, but most users do.

What I actually said was breaking dataflow is a consequence, not a weakness.

 

The issue I have with this is that wires have always been the method to be able to sequence execution. Its how data flows in LabVIEW and is very intuitive as an analogy! We have always been taught that we should use them instead of sequence structures and wire error clusters to make execution order unambiguous and repeatable. Well. This type of wire doesn't do any of that and if you think it does you are in a whole world of hurt. I can guarantee that people will expect it to though, especially when single stepping or highlight execution debugging etc.

 

I also said. I'm willing to be convinced. When we do break dataflow it would be helpful to know where data pops out but why not do something with existing asynchronous methods like events?

 

So. Show me the killer app. Lets see how easy it makes understanding the Actor Framework. Lets upgrade some existing software to use this technology so we can compare the benefits directly. Is it just a fancy global variable with a confusing wire type or is it like buffered TCPIP endpoints?

Edited August 14, 2015 by ShaunR

[eberaud]

I'm on the same page as Shaun. Maybe it's a matter of habit, but for those of us who have been developing in LabVIEW for years, a wire always controls data flow and execution. This is a golden rule that suddenly doesn't apply anymore, and that's quite disturbing I find.

[Aristos Queue]

So. Show me the killer app.

Nope.  That's what we want to see from you. This was released as an exploration of what's possible. We have some things that we think would be improved by channels, but we're still exploring the design space. Our goal at this point is NOT to convince you to use them. Our goal now is to see if given them if you find interesting and powerful things to do with them. That may both surprise us with new uses and let's us see what areas are worth more detailed expansion.

 

Had this been an actual release, this feature would have been accompanied by useful example programs and more detailed instructions for use.

[ShaunR]

Nope.  That's what we want to see from you. This was released as an exploration of what's possible. We have some things that we think would be improved by channels, but we're still exploring the design space. Our goal at this point is NOT to convince you to use them. Our goal now is to see if given them if you find interesting and powerful things to do with them. That may both surprise us with new uses and let's us see what areas are worth more detailed expansion.

 

Had this been an actual release, this feature would have been accompanied by useful example programs and more detailed instructions for use.

Lol. That's hoping a bit (from me ;P ) , If you'd put the wire in the hierarchy window, I'd be all over it

 

So that's an admission that its a solution looking for a problem as I surmised?

Edited August 14, 2015 by ShaunR

[Aristos Queue]

So that's an admission that its a solution looking for a problem as I surmised?

No.

[JackDunaway]

Now with async wires, it's important we more clearly define our historical usage of the word "dataflow" to mean "synchronous dataflow", also acknowledging "asynchronous dataflow" is a better way to describe we've historically called "breaking dataflow".

 

The undecorated word "dataflow" just means that data moves, either temporally or spatially. Synchronous and asynchronous dataflow are desirable for different reasons at different layers.

 

Async wires are a huge opportunity to explore innovation on procedural logic at the functional/diagram level (this syntax at systems/application layer right now is less interesting). I would recommend checking out an awesome example AQ posted on: https://decibel.ni.com/content/docs/DOC-42942 

[ShaunR]

Now with async wires, it's important we more clearly define our historical usage of the word "dataflow" to mean "synchronous dataflow", also acknowledging "asynchronous dataflow" is a better way to describe we've historically called "breaking dataflow".

 

The undecorated word "dataflow" just means that data moves, either temporally or spatially. Synchronous and asynchronous dataflow are desirable for different reasons at different layers.

 

 

Sorry. I'm not going to let you get away with that conflation.

 

Dataflow has a specific architectural meaning from an operational stand-point. I won't let you conflate an abstract, analogous idea of data moving with an operational paradigm through tortured wording. It's like saying by-value is the same as by-reference because they both enable passing data by-something, right?

Edited August 15, 2015 by ShaunR

[JackDunaway]

Sorry. I'm not going to let you get away with that conflation. Dataflow has a specific architectural meaning

 

For clarity: are you saying that Channel Wires (this is the official name and a much better name; my usage of `async wire` is I believe what it used to be called until being replaced by the better name Channel Wire) are not `dataflow`, and considering them as such conflates concepts to a point of confusion?

[ShaunR]

For clarity: are you saying that Channel Wires (this is the official name and a much better name; my usage of `async wire` is I believe what it used to be called until being replaced by the better name Channel Wire) are not `dataflow`, and considering them as such conflates concepts to a point of confusion?

 

I'm saying that dataflow, in a dataflow paradigm, has a specific operational meaning and is a defined concept. It is not is just an analogy to a river flowing to aid comprehension for data being produced and consumed. I'm just picking you up on watering down (no pun intended ) the definition by conveniently ignoring state.

 

Do "Channel Wires", "Asynchronous Wires", "Pipes", "Conduits", "Meanders", "Dunaway Dynamic Data Doorways" or whatever you want to call them   implicitly impart execution state? The answer is the answer to whether they are part of a dataflow paradigm or not.

Edited August 16, 2015 by ShaunR

[JackDunaway]

I'm saying that dataflow, in a dataflow paradigm, has a specific operational meaning and is a defined concept. It is not is just an analogy to a river flowing to aid comprehension for data being produced and consumed. I'm just picking you up on watering down (no pun intended ) the definition by conveniently ignoring state.

 

Do "Channel Wires", "Asynchronous Wires", "Pipes", "Conduits", "Meanders", "Dunaway Dynamic Data Doorways" or whatever you want to call them   implicitly impart execution state? The answer is the answer to whether they are part of a dataflow paradigm or not.

 

Does a Channel Wire fall within your definition of "dataflow"?