07-23-2021 02:07 AM - edited 07-23-2021 02:15 AM
Hi,
I'm playing around with channel writers just to get a better understanding of them and to see what are their practical use case. At the first glance it looks that channel writers can be used for example to realize the QMH design pattern functionality using a channel instead of a queue and by using a channel the structure may be a bit cleaner.
On the other hand I have never seen a project which actually uses channel writers, so I'm wondering if they are really practical or not. Also I dont think using channels would end up a lot cleaner block diagram.
Does anybody here use channels? If so what are use cases, what are benefits over other patterns?
Thanks.
07-23-2021 05:00 AM
Channel wires are relatively new. So there are no established architecture templates using channel wires, as there simply hasn't been time to establish.
You are right, channel wires can be used in stead of queues. You can certainly make QMHs or Producer\Consumers with channel wires.
Channel wires can also be used to distribute current value tables throughout an application (for instance a 'stopped' value, stopping all parallel loops).
One advantage of channel wires is clarity on the block diagram. However, once things need to be dynamic, that advantage goes away.
As with all new technologies, there where (are?) some problems. The scripted code lives somewhere outside the project, and things can get complex. I think there where some issues with channel wires on PC and RT for instance. Over time, these issues need to be ironed out, and people will over time start to trust channel wires more and eventually maybe start to depend on them.
They are a solution to something that wasn't a big problem. In a way, they are only a convenience. It will take time for people to switch from proven methods to new methods.
07-23-2021 07:58 AM
wiebe@CARYA wrote:
Channel wires are relatively new.
5 years now (LabVIEW 2016). And I really only know of 1 person who consistently uses them.
wiebe@CARYA wrote:
You are right, channel wires can be used in stead of queues. You can certainly make QMHs or Producer\Consumers with channel wires.
The Producer/Consumer is where I really see the use. If the functionality made it into the FPGA (I think they did in LabVIEW 2017), then they will help a lot with pipelining. Unfortunately, I have not had an application that needed either of those, so I have not given them a good try.
07-23-2021 08:12 AM
@crossrulz wrote:
wiebe@CARYA wrote:
Channel wires are relatively new.
5 years now (LabVIEW 2016). And I really only know of 1 person who consistently uses them.
So do I. Good change it's the same person 😁.
If we ever get a target structure, and channel wires work across targets, that would be neat too.
07-23-2021 10:00 AM - edited 07-23-2021 10:34 AM
I recently got into Channel Wires and love them.
The Channeled Message Handler makes so much more sense to me than the QMH
Here's a picture of my block diagram and part of my documentation
General Overview:
This generation of the Qualification Platform program uses a Chanel Message Handler architecture consisting of four independent state machines that communicate through Channel Wires. This architecture has the advantage of being able to constantly monitor UUT for safe operating conditions, display real time measurements, and log to a file at regular intervals. While keeping the GUI responsive to user interactions.
All loops except for the GUI loop use Dequeue Message vi to check for incoming messages on the Message Channel at the beginning of each iteration. The incoming message contains a command and an optional Variant payload. The incoming command will override the next state and perform the incoming command instead. This allows the program to automatically abort the test and shutdown the UUT if an error occurs, or safe operating limits are exceeded.
The optional Variant payload can contain any LabVIEW data type and is used to send information such as error codes and configuration parameters between loops.
The timeout on the Dequeue Message vi can be set from 0mS (no wait) to infinity (wait forever). This is also used to prevent loops from consuming %100 of the CPU cycles during wait states.
Safe operating limits are constantly monitored at 100mS intervals when the UUT is powered. If either limit is exceeded for longer than the Trip Delay, the program automatically aborts and shuts down the UUT. Also, the last ten seconds of Yokogawa measurement data taken immediately before the SOL trip event is appended to the data file to aid in UUT failure troubleshooting.
07-23-2021 04:31 PM
OK, OK, I guess I'm the Channel Wire Afficianado. Except in very special circumstances, in the last 5 years, I've used Channel Wires almost every time there was a need for asynchronous data communication, whether something like a Queue (simple Producer/Consumer), a Message (QMH), a Notifier, etc. I mainly use Messenger, Stream, and Tag Channels in their "Vanilla" flavor (no Abort, Schedule, Ack modifiers).
I like them for several reasons -- perhaps the main one is their mnemonic quality to say "This is an instantaneous communication mechanism that jumps over the boundaries of LabVIEW Structures (demonstrating Instantaneus and Asynchronous) while maintaining normal left-to-right flow of data". [Contrast the Channel Writer, whose output is on the right, with Enqueue, whose output is on the left].
Separating Stream Channel Wires (which generally do not branch, but are for one-to-one "streaming" of data, like Queues, but with built-in Sentinels to safely close the Channel without errors) from Messenger Channels that can safely branch, is also a plus in my book.
I find them easy to use, easy to understand (and explain to a LabVIEW novice), mnemonic, and attractive. Any other questions?
Bob (Knight of the Channel Wire) Schor