Channel Wires (Asynchronous Wires) Discussion

[ShaunR]

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

It's not my definition. You tell me.

 

I'm pulling you up on

 

"The undecorated word "dataflow" just means that data moves, either temporally or spatially.".

It doesn't!  (just mean)

Edited August 16, 2015 by ShaunR

[GregSands]

IMHO, Channel Wires are definitely not Dataflow.  But that's not necessarily a bad thing - LabVIEW has not been a pure dataflow language for decades (when did queues/notifiers/... first appear?  Anyone still alive from back then?)  And I can even see the point of having them - they provide a visual representation of that non-dataflow, and the various types of Channels just describe the transport mechanism.

 

The issue for me is in calling them "Wires" at all - that's where the confusion arises.  They seem more like "Portals" - something that connects two locations without traversing the space in between.  In that sense, I don't like that the Channels are sitting on the block diagram, and perhaps that's where a 3D view could be more useful - I can more easily see them existing in a hyperspace that sits outside of the block diagrams.

 

One more thing - the existing Queue wires could be thought of as Channels/Portals, right?  The data doesn't flow along the wire, it teleports to other locations, and you can even do away with the wire altogether with named queues.  So the Real Problem is that LabVIEW has been calling things wires that are not wires, and now perhaps there's a chance of changing that, and giving a robust framework for understanding non-dataflow.

 

One last thing (I promise!) - I would think Global Variables (and Shared Variables?) are essentially part of this too, but they're more like a Quantum Portal, where each end is "entangled" - i.e. there is no underlying transport mechanism in between.

[Neil Pate]

I agree the problem stems from calling them "wires". In LabVIEW all wires obey data-flow, period.

 

Queues and other reference type constructs are not wires, they have a wire to represent the their reference, and that wire does obey dataflow, but the actual implementation of the queue does not live on the wire.

 

So, I do am not really that keen on the name "Channel Wires". I would have been totally fine with just "Channels". However, I am pretty sure I will just get used to them.

Edited August 18, 2015 by Neil Pate

[eberaud]

Well it's not only the name. It does look like a wire, and like you said even reference wires obey data flow...

[hooovahh]

Well it's not only the name. It does look like a wire, and like you said even reference wires obey data flow...

But in NI's defense they did use visual queues to help show that it isn't just a normal wire, going into and out of structures don't use tunnels.  This for me was enough to know they were special, but probably not enough for new developers.

[ShaunR]

But in NI's defense they did use visual queues to help show that it isn't just a normal wire, going into and out of structures don't use tunnels.  This for me was enough to know they were special, but probably not enough for new developers.

 

I understand their enthusiasm. I just think its the wrong aspect view. Wires have a definite meaning in the diagram., but what would they mean in the VI hierarchy?

 

If I could look at the VI heirarchy and see where a particular VI contained a create node and which VI that create node was sending data to. That would be like a network map. If I could select a VI in the hierarchy window that has a create event (queue,or notifier) and see all the VIs that had its event registration. I would have a map of my messaging system If I could probe the wires between VIs; I would be frothing at the mouth.

Edited August 18, 2015 by ShaunR

[Jordan Kuehn]

I understand their enthusiasm. I just think its the wrong aspect view. Wires have a definite meaning in the diagram., but what would they mean in the VI hierarchy?

 

To summarize, all the complaints I'm seeing are related to the representation on the BD.  Is that accurate?  

 

To me this seems like an incredible concept if done correctly.  Essentially a loss-less local variable that can communicate cross-platform from what I've gathered.  

 

As a final note, I think this subject deserves its own thread and this one can return back to highlighting the new features in 2015.  Though it might be a pretty short thread then... 

[ShaunR]

Essentially a loss-less local variable that can communicate cross-platform from what I've gathered.  

 

Don't we already have that with shared variables?

[Jordan Kuehn]

Don't we already have that with shared variables?

 

Shared variables aren't loss-less unless you have some magic I don't know about.  This seems to be a combination of NSVs and Network Streams without the additional configuration.

[hooovahh]

As a final note, I think this subject deserves its own thread and this one can return back to highlighting the new features in 2015. 

Great suggestion, topic split.  Next time suggest that sooner, 2 1/2 pages of that 3 page discussion was on this one feature.

[GregSands]

To summarize, all the complaints I'm seeing are related to the representation on the BD.  Is that accurate?  

 

No, I think there's a semantic issue as well with calling them "wires".  The BD representation is ok given that there's no other place for them to currently be represented, but I think my (and possibly Shaun's) argument is that they shouldn't really exist on the BD at all.  They're in another dimension.  And even more so if you want to show the links between VIs, or across platforms.

 

Even more so with statements like this:

 

Channels Can Create Cycles

Channels do allow for bidirectional communication as well as any more complex cyclic graph that you would like to construct.

 

 

That diagram is impossible to interpret with the Channels drawn like other wires on the BD.  

 

 

 

To me this seems like an incredible concept if done correctly.  Essentially a loss-less local variable that can communicate cross-platform from what I've gathered.  

 

I might be wrong, but as far as I can tell, Channels don't (yet) enable anything different to what can already be achieved, but provide a new visual representation.  AQs post (read the whole message again) sums it up really well: "The goal with channels is to provide a visualization of the asynch communication code paths".  So they're a way of seeing/probing links between different sections of code that are connected by a queue/notifier/event/global/...  Channels are just a higher-level box that encompasses all async communication.  And by "just", I don't mean "merely" - like you, I think these could be incredibly powerful and useful.

 

It's already possible to implement a loss-less cross-platform communication using Network Streams, but I think Channels might eventually give the ability not only to do that more easily, but to be able to directly see/follow that link.  

Edited August 18, 2015 by GregSands

[smithd]

disclaimer for anyone who doesn't know me: despite the giant bright blue "NI" next to my name I am not in any way affiliated with R&D so don't take anything I say as a fact about the product.

 

 

IMHO, Channel Wires are definitely not Dataflow.  But that's not necessarily a bad thing - LabVIEW has not been a pure dataflow language for decades (when did queues/notifiers/... first appear?  Anyone still alive from back then?)  And I can even see the point of having them - they provide a visual representation of that non-dataflow, and the various types of Channels just describe the transport mechanism.

The story I've heard is that they're asynchronous dataflow, similar as I understand it to http://noflojs.org/

 

This makes sense to me, based on the wiki:

 

Traditionally, a program is modeled as a series of operations happening in a specific order; this may be referred to as sequential,^[1].3procedural,^[2] Control flow^[2] (indicating that the program chooses a specific path), or imperative programming. The program focuses on commands, in line with the von Neumann^[1].3 vision of sequential programming, where data is normally "at rest"^[2].7

In contrast, dataflow programming emphasizes the movement of data and models programs as a series of connections. Explicitly defined inputs and outputs connect operations, which function like black boxes.^[2].2 An operation runs as soon as all of its inputs become valid.^[3] Thus, dataflow languages are inherently parallel and can work well in large, decentralized systems.^{[1].3[4] [5]}

So to me it sounds like the big thing that makes something dataflow is that you can explicitly visualize the routing and movement of data which is exactly the intent of these wires (as I understand it)

 

Something else I agree with, but isn't so far as I can tell in the explicit definition, is that an important part of dataflow's simplicity advantage is that data isn't shared. You see how it flows between items but you don't usually share it. When you do (as with DVRs or FGVs), you 'break' dataflow or at least break a key value it provides. Note that this is different from a queue, user event, or the new wires. In all these cases a given section of code explicitly sends information to another section of code without retaining access to that data. The data is sent but not shared.

 

But in NI's defense they did use visual queues to help show that it isn't just a normal wire, going into and out of structures don't use tunnels.  This for me was enough to know they were special, but probably not enough for new developers.

But what if we had started 15 years ago (or whenever) with just these channel wires and queues had never been implemented as a separate concept? What if core 1 taught these wires? I don't really think it would be a problem for anyone experienced and it would reduce confusion for new developers (whats a sv? notifier? occurence? user event? queue? single element queue? rt fifo? who cares?). 

 

I personally have zero plans to use these wires in anything I work on, but I do think that if we had created them first there would probably be no need to have added many of the others.

 

 

 

If I could look at the VI heirarchy and see where a particular VI contained a create node and which VI that create node was sending data to. That would be like a network map. If I could select a VI in the hierarchy window that has a create event (queue,or notifier) and see all the VIs that had its event registration. I would have a map of my messaging system   If I could probe the wires between VIs; I would be frothing at the mouth. 

I'm curious what this looks like in your mind. Is it a more granular version of this (https://decibel.ni.com/content/docs/DOC-23262) or something else entirely?

 

Something that I'm not a big fan of is the giant fanout of queue wires that occur in many applications. It seems like the async wires would help with this as you can draw the wires between the subVIs which are actually communicating (A->B) rather than the current situation (init->A; init->B).

 

Also, I noticed your comment about shoving queues inside of subVIs and getting rid of the wires entirely. I've seen this many times before and never really understood it, but it seems related to how you want to visualize this stuff, so I'm curious how that concept ("vanishing wires") fits into your communication map concept.

[JackDunaway]

Great suggestion, topic split.

 

Thank you; I was reserving continued replies without polish in the spirit of not muddying the water of the original topic, so this helps a more organic and focused conversation.

 

 

 

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

 

 

It's not my definition. You tell me.

 

Unequivocally, and with a detailed response whose draft seems to have been lost in the thread fork. Stay tuned...

[ScottJordan]

Manudelavega notes, "...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."  

 

Others have expressed similar concerns in different ways.

 

But: ​That ship sailed circa 1987 when global variables first became a thing.  (A few of us were using uninitialized shift registers even before that.)  Dataflow is central to the LabVIEW way of doing things, but purity was sacrificed on the altar of power and functionality at that time.  

 

The real question is whether there's a use case for this particular innovation, and whether this provides a more sensible and LabVIEW-ish way of representing what's going on.

 

I suspect that if you've done much with queues and suchlike to take advantage of LabVIEW's awesome parallelism capabilities, you'd probably feel it does.  I have, and do.  

[JackDunaway]

A few of us were using uninitialized shift registers even before that.

 

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.

[Sparkette]

I'm curious how the wires are able to ignore structure boundaries and loop around without feedback nodes. What confuses me is that the channel readers/writers are plain old subVI's, and the channel terminals appear to just be strictly-typed VI refnums.

[GregSands]

They don't ignore structure boundaries - click on them, and there is a transparent terminal.  Not sure how they loop without feedback nodes though, I guess the wires have some special flags set?

 

What's also interesting is that the wires are colored from both directions (this one shows a mis-match in types):

 

[CraigC]

I understand their enthusiasm. I just think its the wrong aspect view. Wires have a definite meaning in the diagram., but what would they mean in the VI hierarchy?

 

If I could look at the VI heirarchy and see where a particular VI contained a create node and which VI that create node was sending data to. That would be like a network map. If I could select a VI in the hierarchy window that has a create event (queue,or notifier) and see all the VIs that had its event registration. I would have a map of my messaging system If I could probe the wires between VIs; I would be frothing at the mouth.

 

Something Like This....  Auto generated then output to GraphML  

Although it is fairly specific to application it might be able to be applied as a general tool.  Some fairly rough code just to see if it was feasible.

 

 

Craig

 

Edited post to make the map file colour coded with the BD VIs.

Queue Map.zip

Edited August 19, 2015 by CraigC

[smithd]

They don't ignore structure boundaries - click on them, and there is a transparent terminal.  Not sure how they loop without feedback nodes though, I guess the wires have some special flags set?

I don't think there are any special flags. If you think about it, in any other queue situation you have to create the queue outside of the loop and pass it into the loop. The same thing happens here, but the terminal is colored weird to make it seem more like what you intend than what is really happening. I'm actually not sure where the create happens though.

Something Like This....  Auto generated then output to GraphML  

Although it is fairly specific to application it might be able to be applied as a general tool.  Some fairly rough code just to see if it was feasible.

 

 

Craig

 

Edited post to make the map file colour coded with the BD VIs.

And heres where I really just don't get the removal of wires. Why are we hardcoding the queues for A, B, and C? None of that code cares what queue it reads from. Just using the wires means that your (well written) top level VI documents the communication path:

[hooovahh]

I don't think there are any special flags. If you think about it, in any other queue situation you have to create the queue outside of the loop and pass it into the loop. 

Yes but in this case the queue reference can be accessed without needing the value on the wire.  A LabVIEW paradigm is a function doesn't execute until all of its inputs are available, and once it is done executing all of the outputs are generated.  In this case a while loop can execute with a Channel Wire connected to it, that doesn't come from a data flow from a source.  Most of how a Channel Wire works is normal G, but the wire behavior not enforcing data flow is something NI had to do for this one wire type (or types).

 

I think it's been mentioned before but all this is, is syntactical sugar.  Anything a Channel Wire can do, I can do without Channel Wires.  But if I can make my code faster, cleaner, and be better documented, then I can see the value in this feature.

[CraigC]

 Why are we hardcoding the queues for A, B, and C? None of that code cares what queue it reads from. Just using the wires means that your (well written) top level VI documents the communication path:

All of that code was just to dump out some sort of Queue Structure into a VI so we could see where the Queues are sending Information to / from in a Map Diagram.  The Top level structure of test, test_A, test_B is just randomness (except I ensured there was only one De-Q per Queue).  I am just trying to illustrate that part of what a "Channel Wire" is trying to accomplish is indicate to the developer where asynchronous data is accessed / flowing (I am not good with terminologies).  A different way of relaying this information is in a hierarchy / map file / class hierarchy diagram, which in my opinion is easier to read.

 

Here is the same rough VI I posted but run on an actual project which includes VIs which are dynamically called (and therefore may not be represented by a "Channel Wire" ??).

 

I have anonymised the vi Names hence the blank boxes.

Edited August 19, 2015 by CraigC

[ShaunR]

Something that I'm not a big fan of is the giant fanout of queue wires that occur in many applications. It seems like the async wires would help with this as you can draw the wires between the subVIs which are actually communicating (A->B) rather than the current situation (init->A; init->B).

I don't see how it helps. It's just another wire to trail around except it won't sequence execution like all the others do. If my subVI is truly asynchronous I can take that sub VI and put it anywhere. I can dynamically launch it. I can run it on a another computer. I just don't wire between loops - it's clutter that requires decoding.

 

Also, I noticed your comment about shoving queues inside of subVIs and getting rid of the wires entirely. I've seen this many times before and never really understood it, but it seems related to how you want to visualize this stuff, so I'm curious how that concept ("vanishing wires") fits into your communication map concept.

 

Its not to do with visualisation. It is encapsulation and breaking dependencies. I create self contained autonomous "nodes" that can be tested in isolation. Can be transplanted from project to project, Can be distributed as a single entity and can be worked on without the rest  of the application. It just has the side effect that it really cleans up the diagram and makes it look much simpler than it really is.

 

I'm curious what this looks like in your mind. Is it a more granular version of this (https://decibel.ni.com/content/docs/DOC-23262) or something else entirely?

 

My mind is a dark and foreboding place

I will describe how I see software and it may cast light on why I like LabVIEW over the others and how I currently use the VI hierarchy window and design software. Probably more than your asking for but it may help

In a nutshell, I see dead people 3D systems.

I don't see these systems as lines of code or flow diagrams or other abstract sensations at that level. I see them like in the hierarchy window but in 3D. More like Firefox 3D view but infinitely big. Where there are icons, I see real devices that I've used or know about. Where there are lines, I see TCPIP, Serial, broadband and satellite comms. I see mains cables, probes and sensors. I can also see the layers of that system like the layers in the Firefox 3D view, I can see cabinets full of devices and devices full of boards and boards full of software and a sometimes a  rough BOM. You know when the girl in Jurassic Park turns security back on and locks the doors with the computer? That's a poor mans version of how I see systems in my head and I can envision them from scratch, from specs or discussions with a customer. At least one of those devices is usually a programmable device and that's where LabVIEW comes in.

I can zoom around and in and out of that 3D hierarchy too. I can go to a particular device and inspect it. I can also switch views of that device. I can see it's UI menus and DIP switch settings. I can flip a brain-bit and view it as the wiring diagrams or as a high level schematic of subystems. I can see the exploded view of the accessories and attach them to the fascia to figure out wire routing. My thoughts are very visual and I can view it in many ways. This is also how I view the software. I see VI icons that represent the devices and the databases and all the things in the real world. I can move them around, change their menus and their dip switches-except they aren't menus or dip switches. They are configuration files and VI front panels. I flip my brain-bit to view the software wiring [vi diagram]  and click on "Create SubVI" as I transition the subVI to a subsytem and the current VI to a high level schematic. Moving from the real world to LabVIEW is seamless to me. With other Languages I have to build those sub VIs and diagrams in my head and keep them there or reload them from a document/source file. LabVIEW lets me put them directly into code and leaves me free to think about the system not the memory location/pointers or other mechanics of the programming language. It gets the job done rather than being the job.

 

So those new wires don't have a use for me. They are in the wrong "view". I always try to simplify, encapsulate and decouple the wiring diagrams in my code and part of that is reducing wire counts and breaking flow where appropriate.

 

[ShaunR]

All of that code was just to dump out some sort of Queue Structure into a VI so we could see where the Queues are sending Information to / from in a Map Diagram.  The Top level structure of test, test_A, test_B is just randomness (except I ensured there was only one De-Q per Queue).  I am just trying to illustrate that part of what a "Channel Wire" is trying to accomplish is indicate to the developer where asynchronous data is accessed / flowing (I am not good with terminologies).  A different way of relaying this information is in a hierarchy / map file / class hierarchy diagram, which in my opinion is easier to read.

 

Here is the same rough VI I posted but run on an actual project which includes VIs which are dynamically called (and therefore may not be represented by a "Channel Wire" ??).

 

I have anonymised the vi Names hence the blank boxes.

 

Yup. Now that's useful. If you can make it an isometric 3D view of all the VI icons that have queues, events, notifiers etc with switches to turn paths on and off. I'll be in Nirvana

[chris754]

I like this. I don't really see it breaking data flow. It's sort of like like "worm hole" data flow. Data is still moving from one point to another, just not encumbered by normal physical bounds of the 2d world.

[hooovahh]

I like this. I don't really see it breaking data flow. It's sort of like like "worm hole" data flow. Data is still moving from one point to another, just not encumbered by normal physical bounds of the 2d world.

Such a great analogy.  This is less breaking LabVIEW's programming concepts, and more like adding another dimension to them.  Is LabVIEW the first 3D programming language?  Not quite I guess.

 

Isn't there a principal that a observer in one dimension can observe the next dimension higher, but only at a single frame of reference?  Maybe not the right wording but you know.  We in 3D space can observe 4D space time.  So our 2D monitors can observe a 3D space that is static.  Maybe this is LabVIEW's way of representing the 3D space.