Jump to content

Channel Wires (Asynchronous Wires) Discussion


Recommended Posts

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.

Link to comment

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 by Neil Pate
Link to comment

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.

Link to comment

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. :D

Edited by ShaunR
Link to comment

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...  :oops:

Link to comment

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.

Link to comment

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.

 

Untitled.png

 

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 by GregSands
Link to comment

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]:P.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]:P.3 vision of sequential programming, where data is normally "at rest"[2]:P.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]:P.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]:P.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.  :D

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.

  • Like 1
Link to comment

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...

Link to comment

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.  

  • Like 1
Link to comment

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.

Link to comment

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):

 

post-3889-0-43066300-1439961574.png

Link to comment

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. :D

 

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.

post-15311-0-81538000-1439993841.png

Queue Map.zip

post-15311-0-24495100-1439996253.png

Edited by CraigC
Link to comment

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:

post-52313-0-63663500-1439996832.png

Link to comment

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.

Link to comment

 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.

post-15311-0-01455000-1439999129.png

Edited by CraigC
  • Like 2
Link to comment

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 :wub:

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.