We are going to change the Channel wire appearance

[AbandoningCausality]

If you want them always showing then just leave your channel layer visible. Personally, I like functional globals and I'd appreciate the enhancement of defining them anonymously and optionally seeing where they go.

[Dragis]

Allowing various layers of information to be shown and hidden, including channel or standard wires, is something we've been toying with for a long time. Personally, I'd love to be able to hide all code at run-time that is not part of the "steady-state" flow of my application. It's good to hear others would like to see these features!

[TimVargo]

I rather like the idea of using the bezier curves that by default have transparency of 80%, but show up better (like 20%) upon mouse-over; but this is evidentially not possible until we get a new BD editor.  This way they would never be TOTALLY hidden, but not distracting either, while still offering full readability.  Perhaps shift-mouse-over could even render ALL channel wires on the current BD at 20%.

[TimVargo]

On the topic of terminology, if we REALLY want these to be conceptually different from normal wires, then why is the word "wire" in their name (channel wire)?  Over on the Pop Quiz thread, both Mads and kegghead explained, and I agree: 

... the connection between channel nodes should never be called wires. There is no flow. They're channels, not wires.

... drop the idea of a channel "wire".

Wouldn't channel conduit, or something similar, be less mentally disorienting?  With a physical, traditional "conduit" there are wires running inside of an armored jacket; but these inner wires are protected and inaccessible until you reach a node (think junction-box).  This analogy should be well understood by those who already understand the concept of a wire.

[AristosQueue (NI)]

This got a lot of discussion, both inside and outside NI.

A few things keep driving us back to wires:

a) you draw them with the wiring tool.

b) they are affected by ctrl+b

c) they connect nodes together, which is what wires do

At the end of the day, we found we needed three terms:

1. The lines of pixels on diagrams that show synchronous dataflow

2. The lines of pixels on diagrams that show asynchronous dataflow

3. Both of the above inclusively

We could either invent a new term #3 or use "wire" as the term #3. Inventing a new term #3 would require realigning the vocabulary of all users ("What does ctrl+b do? It removes all thingybusses." or "You can probe the thingybusses on the diagram.") Changing the scripting APIs would be a particular pain. Or we could use "wire" as that inclusive term and make these a branch of the wire family (pun intended). We went with the latter. It is both acurate and easier than recoding the minds of our uses.

The reason that we emphasize "channel wires" instead of just "channels" is because of DAQ channels. Eventually, we intend to tightly align the hardware channels with these graphical channels -- you would have a DAQ device on the diagram that has N channel wire terminals coming out of it, each representing one of the DAQ channels. You would connect these to Read or Write endpoints in your application as desired. This would not remove the lower level refnum API, but it will provide a significantly simpler [we believe] system for following where your hardware is accessed in a program for those who choose to use that paradigm. But in the short term, we don't have that, and we aren't going to be discussing those future plans with users generally at this juncture. So we are taking care to make sure people are aware this is not some DAQ-specific feature.

Regarding "conduit" specifically, eventually we want a single line of pixels that represents multiple channels all together. When we ask people what to call that future thing, "conduit" comes up as a grouping term and seems to imply a bunch of wires together to a notable number users. Personally, I prefer "bundle" for that future concept, but even if we go with "megathingybus", we wouldn't want to use "conduit" today specifically because of its association with a set of wires together.

[Bob_Schor]

After a long silence (too busy with other things, but I was "silently reading"), I decided to add my $0.02 and ask a question.  Then, of course, I blew up my Channel Wires (but I'll post that separately) ...

First, the idea of Channel Wires is very intriguing, and there is clearly additional functionality that can be had by using them.  However, "With Great Power Comes Great Responsibility".

One of the key concepts of LabVIEW, one that takes students a while to learn, is the concept of Data Flow, that Wires mean something, that Inputs and Outputs govern order of execution (not "placement on the page").  When we introduce Queues, there's a bit of a mental "jar" because it seems like data flows "backwards" in the Queue, but if you get the user to understand that the Queue is a conduit (or "channel"), it's not so bad.  And these are sufficiently "advanced" topics that users catch on pretty quick.

Now come Channels, which "float above" the boundaries of structures, able to "reach inside" a running loop and transmit "over the edge".  Because there are both input and output (unlike, say, an Enqueue which has a "vestigial" output, with the data going out through the input connector), if we obey the "left-to-right" wiring sequence, and also want to obey the "vertical stacking" of functions running in parallel (a very nice visual reminder that they have no data dependency on each other), we've got a bit of a mess -- maybe an S-shaped channel from Output of Loop 1 backwards to the Input of Loop 2 ...

Channels are clearly an "advanced" topic, partly because of the non-data-flow paradigm.  As such, visual appearance really is important.  I'm not too unhappy with the "flange" and "channel appearance" flowing over the edge of structures.  I see both sides of "are they Wires or Channels or Both", and think I can live with Channel Wires as a reasonable compromise.

So here's a question -- are some of these "enhanced features" making their way into LabVIEW 2015 SP1?  How about into LabVIEW 2016 Beta?  Or should we do both (and really go nuts)?

Bob Schor

[AristosQueue (NI)]

> How about into LabVIEW 2016 Beta?

The fully productized version of channels will be in 2016 Beta. Whether or not they are in the final 2016 product is, of course, something I won't promise ever since I got burned by LVOOP being in a beta and then slipping the release.  😉

We won't be putting any of it into 2015 SP1 -- I am of the firm opinion that service packs are for stabilization, not for feature expansion, and I don't like it when NI fuzzes that line.

> Channels are clearly an "advanced" topic

Clearly. Very advanced. So advanced that I've asked about possibly teaching them in the LV Core 2 customer education course. 🙂

Joking aside -- I don't think they're an advanced topic. I referred to them as advanced back in August when we first started sharing them with customers. The more we've put them in people's hands, the less I've held that position. Some of us have been pouring development effort into polishing them precisely because we're recognizing more and more uses for them where they pull previously complex topics down substantially. A basic producer/consumer loop. Pipelining. UI modeling. We've got working examples that will be shipping with LabVIEW 2016 that have been created inspired by various uses we've seen channels used for. Those examples are very diverse. Moreover, they're surprisingly *simple*. There's a Sound & Vibration example in particular that eliminated a huge swath of existing nodes.

I hope when 2016 beta is available that you'll all be able to look through the examples and see. If you're going to be at the CLA Summits (Americas or Europe), come find me in a spare moment I can let you see 2016 channels on my laptop.

[Bob_Schor]

Vincent wrote "... They are more easily identified at first glance as "non regular, non-data-flow wire" than the new design, to my opinion. And identifying what is data-flow and what is channel looks much more important to me than knowing the underlying data type to me, at least at first glance when debugging a VI."

I agree, and I just realized what has been bugging me all this time about Channel Wires.  I'm going to vastly-oversimplify things here by discussing Queues and their Channel equivalent.  The "problem" with Queues is that when you enqueue something, it acts as though it instantaneously "flows backwards" through the incoming Queue wire outside Loop edges, somehow violating Data Flow (I know it doesn't, really, but that's the visual appearance that's presented).  Channel Wires explicitly ignore Loop edges, so the "solution" was to have "input" and "output" Channels that act as "instantaneous conduits" leaping over structure edges.

But now, if we have, say, 5 VIs running in parallel and sharing a Queue (say 4 enqueuer and one dequeuer), and we maintain the extremely-useful visual convention of left-to-right information flow, we'll have to get all those Channel Out wires from the right-side of our sub-VIs to the left (input) side of the "Channel-consumer" VI.

But why not have a visually-distinct two-way channel (such as the current Queue)?  I won't try to draw such a thing, but one visually-appealing (in my Mind's Eye) idea would be to take two "one-way" Channels and "fuse" them together into something that is a little wider, perhaps, but looks like it could have "flow in both directions" inside it.

Returning to the Queue example, if I have a sub-VI that is going to be enqueuing things, I obviously need to bring the Queue into the sub-VI, but unless I'm going to have multiple Queue operations inside this sub-VI, I don't need to use the output tunnel on the Enqueue function, and, indeed, don't need the Queue wire at all once I've hooked it into the Enqueue function.  Many shipping LabVIEW examples that use Queues do not bring the Queue wire all the way across a sub-VI -- if it is needed when the sub-VI exits (for example, to do a Release Queue), it is often branched before entering the sub-VI and brought "over the top".  Similarly, sub-VIs that Dequeue also have "short" Queue wires that don't make it past the Dequeue function.  Indeed, for some of my routines where I have several Queued State Machines (and QMHs), my Block Diagrams got so messy with Queue Wires running all over the place (mostly on the left side of my Main VI, but also through the While loops of my QSM and QMH VIs so I could "enqueue at the end of a loop" and "Release when exiting") that I created some Action Engines to implement what I called my "Wireless Queue", with Actions taking the place of all of the Queue functions except  Dequeue, with the Queue wire living on a Shift Register within the Engine.  When I realized I was envisioning "Wireless Channels", I sensed something was not quite right ...

So I'm offering the idea of a Two-Way Channel, something that would always connect "on the left", though it would exist in Reader and Writer configurations.  Smarter Minds than mine have obviously been thinking about Channels way longer -- I'd be very interested in feedback.

From my perspective of trying to teach LabVIEW to students who don't understand Data Flow (just look at the LabVIEW forums!), I'm nervous about introducing something that appears to violate this principle.  I'm trying to "have my (dataflow) cake and eat (channel) it, too" ...

Bob Schor

[AristosQueue (NI)]

Bob_Schor wrote:

But now, if we have, say, 5 VIs running in parallel and sharing a Queue (say 4 enqueuer and one dequeuer), and we maintain the extremely-useful visual convention of left-to-right information flow, we'll have to get all those Channel Out wires from the right-side of our sub-VIs to the left (input) side of the "Channel-consumer" VI.

Really? Why? Here's four enqueuers talking to 1 dequeuer.

And here are the two block diagrams:

[Bob_Schor]

Sigh -- good point, I really need to play with these things more (I managed to "break" LV2015 playing with Channels, so I'm now waiting on the Beta ...).

BS