Channel wiring VS Queuing - Which one to choose?

[VinnyAstro]

Hi.

I think the subject is clear enough: I was wondering what ponders your choice between queuing and using channel wires when creating a prod/consumer architecture?

I've actually only recently learned about channel wires (always used queuing before that - or local/global variables 🙄) and I don't really get the purpose of it. 

If I understood well, compared to queuing, Tag channels is unbuffered (allowing a lot of different stuff with it) but if data acquisition is actually important, what should I use and why? Queuing or channel wire?

Thanks in advance.

Best,

Vincent

[billko]

I use queues because that's what I'm used to.  Other people - Bob Schor is a prime example - have moved on to channel wires and never looked back.

I think queues and notifiers are functional analogs of channel wires, but channel wires visually keep to the idea of dataflow.

[VinnyAstro]

Hmm I see.

So Channel wires would be an aesthetic choice?

I've seen in the labview help somwhere that Channel wires uses broadcast comms while queues don't, but I'm really not sure to understand what that means. Is it a question of loops synchronizing?

[crossrulz]

---

@VinnyAstro wrote:

So Channel wires would be an aesthetic choice?

I've seen in the labview help somwhere that Channel wires uses broadcast comms while queues don't, but I'm really not sure to understand what that means. Is it a question of loops synchronizing?

---

Depends on the type of channel you are using.  I know the streaming and messaging channels actually use queues behind the scenes.

So, in general, yes Channels are mostly an aesthetic choice.

[Kevin_Price · Accepted solution]

I too use Queues because I'm used to them and because we've developed a number of internal tools and utilties around a QMH (a queue-based message handling architecture).   I guess I kinda like the finer granularity of manipulations available too -- status queries, preview, flush -- but again, probably mainly because I'm used to them.

Rumor time: I was at NI Week 2018 and thought I detected some subtle hints from a deep NI insider that "Channels" might in the future evolve to include network-level messaging or data delivery.  Nothing at all definitive, but it's part of the reason I think Channels are very much worth keeping an eye on, even as I keep sticking with Queues for the time being.

-Kevin P

[Bob_Schor · Accepted solution]

As has been noted, I am a Channel Wire "Aficionado" (or "Nut").  Most of the Projects I've worked on since Channel Wires were introduced use between 8-20 Channel Wires, predominently Messenger Channels (replacing Queues in the Queued Message Handler, creating the Channel Message Handler), Streams (for Producer/Consumer connectors), Tags (replacing Notifiers), and Event Messengers (simplifying User Events).  I consider them to be an Abstraction for Asynchronous Communication between/among LabVIEW structures, primarily Loops and sub-VIs, and find them a better "metaphor" to convey this than (for example) trying to describe to a LabVIEW Novice how an Enqueue gets the data to "flow backwards down the wire and over to the Dequeue function in another loop") (I know, I could bring up By Reference ...).

It would not surprise me if Queues were faster and hidden (somehow) inside some of the Channel Wires, but I'm willing to pay the 70 nanosecond time penalty (I made that number up) for clarity in being able to glance at a Block Diagram and "see" the Asynchronous Data Flow -- the Human (Design and Debug) element is so much slower, time (and clarity) saved (and gained) seem more than worth it to me.

Bob "Channel Wire" Schor

[Frozen]

There are some notable concerns with channel wires. #1 being that they are not very portable between developers. Channel wires are self-creating code located out-side of your source control. See this link

[VinnyAstro]

---

@Bob_Schor wrote:

As has been noted, I am a Channel Wire "Aficionado" (or "Nut").  Most of the Projects I've worked on since Channel Wires were introduced use between 8-20 Channel Wires, predominently Messenger Channels (replacing Queues in the Queued Message Handler, creating the Channel Message Handler), Streams (for Producer/Consumer connectors), Tags (replacing Notifiers), and Event Messengers (simplifying User Events).  I consider them to be an Abstraction for Asynchronous Communication between/among LabVIEW structures, primarily Loops and sub-VIs, and find them a better "metaphor" to convey this than (for example) trying to describe to a LabVIEW Novice how an Enqueue gets the data to "flow backwards down the wire and over to the Dequeue function in another loop") (I know, I could bring up By Reference ...).

It would not surprise me if Queues were faster and hidden (somehow) inside some of the Channel Wires, but I'm willing to pay the 70 nanosecond time penalty (I made that number up) for clarity in being able to glance at a Block Diagram and "see" the Asynchronous Data Flow -- the Human (Design and Debug) element is so much slower, time (and clarity) saved (and gained) seem more than worth it to me.

Bob "Channel Wire" Schor

---

Thanks for your detailed description.

Given the discussion shown by Frozen and the use of my application (and my current knowledge/time available) I will stick to a QMH architecture for now.

But as a side project I will definitely look into Channel wires for possible future projects.

[crossrulz]

---

@Kevin_Price wrote:

Rumor time: I was at NI Week 2018 and thought I detected some subtle hints from a deep NI insider that "Channels" might in the future evolve to include network-level messaging or data delivery.  Nothing at all definitive, but it's part of the reason I think Channels are very much worth keeping an eye on, even as I keep sticking with Queues for the time being.

---

To keep the rumor mill going...Last I heard, the Tag API was going to be doing that.  I have not heard anything of Channels being used for going between targets.  But it would make sense in NXG to create the communication paths in the system view and then you access that on your target VIs.  So it would be similar to channels, but not really.

[Bob_Schor]

I have become completely resigned to the implemention of Channel Wires living outside the Project in the User's LabVIEW Data Folder.  True, on opening a large Project with a few dozen Channel Wire instances will add 5 seconds to the loading, the tremendous improvement in "clarity of code" and having "wires" (or "pipes") running in the direction of Data Flow makes my objections almost trivial.

There is an occasional "glitch" when the Channel Wire count gets high and LabVIEW seems to hang, but these have become less frequent.  When they occur, it is often because the Channel Instances folder has become "crowded" with identically-named Channel Wires from different Projects.  The "fix" is to delete the Channel Instances folder and reload the Project, forcing it to re-create all of its Channel Wires "from scratch", which might take 15-20 seconds.  It might also sometimes "hang" -- here the fix is is to stop LabVIEW, reopen the Project, load a few lower-level VIs that use Channel Wires, then some more, then the Top Level VI.  This almost always works (and if it doesn't, try again and do it "more slowly").

I use Channel Wires all the time, and problems are rare.  I certainly cannot conceive of thinking about trying LabVIEW NXG until they get Channel Wires!

Bob Schor