LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Practical use of channel writers?

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.

0 Kudos
Message 1 of 6
(449 Views)

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.

0 Kudos
Message 2 of 6
(403 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 6
(373 Views)

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

0 Kudos
Message 4 of 6
(368 Views)

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 

Screenshot 2021-07-23 075256.png

 

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.

 

  1. Control Loop
    1. Main control loop for entire program
    2. Initializes instrument communications 
    3. Initializes power sources, loads, and DC switching 
    4. Controls power sources, loads, and DC switching for each test step
    5. Starts and stops the other program loops
    6. Saves the Yokogawa measurement buffer
  2. Yokogawa/Safe Operating Limit
    1. Receives power analyzer configuration from the Control loop
    2. Initializes the power analyzer
    3. Continuously takes measurements and places them into a Stream Channel wire
    4. Streams measurements to the Log/Display loop
    5. Compares measurements to the Safe Operating Limits
    6. Notifies Control loop to shut down test if safe operating limit exceeded
  3. Log/Display
    1. Receives Data Logger configuration from Control loop
    2. Initializes data logger
    3. Receives measurement stream from Yokogawa/SOL loop
    4. Saves most recent Yokogawa data to a file at regular intervals
    5. Takes a data logger measurement and saves it to a file at regular intervals
    6. Displays live Yokogawa measurement buffer
    7. Displays logged measurements taken at regular intervals
  4. GUI (Event driven state machine)
    1. Handles user interface events
========================
=== Engineer Ambiguously ===
========================
Message 5 of 6
(350 Views)

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

Message 6 of 6
(318 Views)