LabVIEW Channel Wires
Pop quiz! Test your understanding of channels!
This is a screenshot of an interesting VI to contemplate. Test your knowledge of channels by answering the questions below.
1. Which loop begins first?
a) the left most
b) the second from left
c) the third from left
d) the right most
e) all of them try to run simultaneously
f) one of them begins first but exactly which one is a compiler decision
2. What are the values of "element" each time the third loop executes?
a) It displays increments of four, but it may display the same value several iterations in a row.
b) It displays increments of one, a different one each iteration.
c) It never displays anything because this VI hangs when you run it with all the loops waiting on each other.
d) It displays increments of four, a different one each iteration.
e) It displays increments of one most times but every once in a while the value increments by four in one iteration.
f) It displays the number 0 every iteration.
3. If you deleted the Wait Ms function from the third loop, what are the values of "element" each time the third loop executes?
a) It displays increments of four, but it may display the same value several iterations in a row.
b) It displays increments of one, a different one each iteration.
c) It never displays anything because this VI hangs when you run it with all the loops waiting on each other.
d) It displays increments of four, a different one each iteration.
e) It displays increments of one most times but every once in a while the value increments by four in one iteration.
f) It displays the number 0 every iteration.
4. What happens when the Stop button is pressed?
a) Nothing because the VI is hung with all loops waiting on each other.
b) The third loop from the left stops and the others keep running.
c) The third loop from the left stops and then the others stop in sequence so the VI halts.
d) The right most loop stops and then the others stop in sequence so that the VI halts.
e) The loops stop iterating but the VI doesn't halt because the loops are waiting on each other to complete.
f) The VI restarts as if the user had hit Abort and then hit the Run button again.
5. Suppose you did the following edits...
-- Replace (using the menu item) each of the current queue-based channel endpoints with the matching Tag channel endpoint that ships with LV 2015.
-- Remove all the broken wires on the diagram.
-- Wire the Stop button to the Stop terminal of the third loop.
-- Create a constant FALSE on the stop terminals of the other three loops.
(If you don't want to try to visualize this, check out the attached "EditToUseTags.png".)
When you run the VI, what are the values of "element" each time the third loop executes?
a) It displays increments of four, but it may display the same value several iterations in a row.
b) It displays increments of one, a different one each iteration.
c) It never displays anything because this VI hangs when you run it with all the loops waiting on each other.
d) It displays increments of four, a different one each iteration.
e) It displays increments of one most times but every once in a while the value increments by four in one iteration.
f) It displays the number 0 every iteration.
Answers are here, written in white text on a white background. Select the text to be able to see it.
Comments are moderated so no one just posts the answers!
Answer 1: E. All try to begin at the same time. Channel wires do not create a dataflow dependency between the loops, so this is no different than four parallel while loops on a diagram.
Answer 2: D. First value is zero. The zero is passed through the queues around the circle, getting incremented each time. When it comes back around, it is now 4. Repeat.
Answer 3: D. No change in behavior. The same thing happens but faster.
Answer 4: C. The stop signal is propagated through this particular channel wire.
Answer 5: C. This VI hangs because the Tag's Read endpoint blocks until the tag has been written to at least once and it does not have a timeout.
Really helpful Aristos, thanks for taking the time to put this together. I managed to get these right, but I think there was an element of expectation towards your example purpose rather than definitely knowing the correct answers 
I'm interested in seeing examples that use these constructs across independent components/actors, to pass messages etc., something more than simple VIs. Without access to 2015 I'm unable to experiment with these, are there any on-line white-papers that cover larger use cases yet?
JackDunaway wrote:
Thoric wrote:
I'm interested in seeing examples that use these constructs across independent components/actors, to pass messages etc., something more than simple VIs. Without access to 2015 I'm unable to experiment with these, are there any on-line white-papers that cover larger use cases yet?
Having thought about this a lot since first seeing Async Wires...
I think that the value proposition of Async Wires is changing how we write procedural code at the functional level, not necessarily to replace all the endpoint configuration semantics needed at the systems/application-layer.
It could be argued a few ways... but I think the way to draw the line is this -- keep Async wires as deterministic as lossless as a CPU clock will allow, while having one other very similar type that's more tuned for messaging at a different layer.
Async wires are an unwelcome feature to my head. I'm very excited about their introduction, but they contradict years of brain training adapting to interpreting dataflow imagery. Suddenly cycles are permitted! The conflict is difficult to accede.
My mind is expanding to understand the full impact of Channels. In the short term my myopic vision sees them replacing existing functions to duplicate existing functionality more elegantly (messages across components), but their impact procedurally re-writes the rulebook somewhat, introducing theoretical chapters I've not yet discovered. Dang I wish I had LV2015 to actually play with these!
AristosQueue wrote:
The current draw style came about after multiple people said, "you know, that channel doesn't really look like a regular wire; I think I could learn to 'see' it differently." But we may need to go further.
They still look like wires to me, and that's my biggest aversion to them. Maybe it's because I do so much object oriented work such that I don't really have an expectation of what a wire looks like.
I really don't like seeing those loops graphically connected. Having to explain data flow to a new user while hand-waving any time these constructs are used would be pretty awkward I imagine.
For starters I think the lack of a tunnel when crossing a loop boundary is way too subtle. Something obvious has to be there saying "hey this isn't data flow and I'm not a wire tunneling, indexing, or feeding back through this boundary". Something that doesn't exist anywhere else in LabVIEW.
For the record I *love* feedback nodes. Don't be messin' with them!
