Notifier or queue for checking if data exceeds limits?

[BertMcMahan · Accepted solution]

To you guys who love your channel wires- is there a good "Channel wires for someone proficient in LabVIEW" article out there? Each time I tried to read up on them they focus on "Look how simple they are compared to queues!" which doesn't help me at all and gives me an "ExpressVI version of queues" feel. However, I do know a lot of very experienced devs like them, so I know I'm probably missing out... but I can't seem to find any great discussions of what that might be.

And so I stay on topic: OP, you should probably first define exactly what "going above a threshold" means. That will define whether or not you could use queues or notifiers. I've had some applications where the user could tolerate up to several minutes of "over limit" behavior, and some applications that needed to stop RIGHT NOW (within milliseconds if possible) when a value went over some threshold. If it's the first, then (like others have said) notifiers are probably your best option.

Consider the differences between the two "message" types. Queues are lossless, and Notifiers can be lossy if not checked frequently enough.

Take the case where you're checking your "read" function (i.e., Dequeue or Wait on Notification) MUCH faster than you're updating it (i.e., Enqueue element or Send notification). In this case, your system will not miss any data, and there is no difference between the two techniques.

Now take the case where you're checking your Read function at a similar rate to, or slightly slower than, your Update function.  With Notifiers, you will only see the most current data. With Queues, you will see old data, and there will be newer data sitting in the queue. You mentioned earlier that "if it's back down below the limits, there's no need to stop it". Since that's the case, and we're assuming here that you're not reading the messages "much faster" than writing the messages, you will actually be missing out on the current state of the system. In short, a Notifier will tell you where the system is now, where a Queue will tell you where the system has been.

If you only care about the value being over range right now, use Notifiers. If you care if the value was ever over range, use Queues.

Then again, if you think your system might change from the former to the latter one day, you could always use a single-element Queue to make it "lossy". Down the road you could take away the element limitation and regain "did it ever go out of range" functionality.

Personally, I could see the case for someone reviewing the data in your log, noticing that it went over-range but didn't stop, then asking "Hey there, why did the program not stop when it went over range? I thought it was supposed to stop if it exceeded the limits!"

[Shiv0921]

Personally, I could see the case for someone reviewing the data in your log, noticing that it went over-range but didn't stop, then asking "Hey there, why did the program not stop when it went over range? I thought it was supposed to stop if it exceeded the limits!"

---

I see what you're getting at. But the program isn't supposed to stop if it exceeds the limits, it's supposed to deal with the issue, so no one will ask that. This program is to run experiments on an electrolyser, and these limits are in place because we know that the electrolyser will occasionally push voltage/temperature/water level outside of the range that is safe for the materials we're using, and we need the power supply/heater/valves to be able to react accordingly to keep it under control. It'd be frustrating if the program just stopped as these are foreseeable events. That being said, for certain events (eg water level too low+ error opening fill valve) the program does stop, but the limits are set with enough leeway that no damage will occur even if shutdown does take a few seconds.

But yeah I can see that what you're saying probably would make sense for other programs, and perhaps if i didn't already have logging handled elsewhere, it's just not a requirement of ours.

Otherwise thanks, your explanation was very explicit. I have already decided notifiers will be most appropriate, but your explanation reinforces that so cheers.

[Bob_Schor]

I'm glad that RTSVLU piqued (not "peaked") your interest in Asynchronous Channel Wires.  I've been an enthusiastic user (and "abuser") of this feature since before it was "new feature" in LabVIEW 2016.

They are related to a number of the features on the "Synchronization" Palette.  These functions, included Queues and Notifiers, provide mechanisms to communicate quasi-instanaeously between LabVIEW Loops running in parallel.  To avoid violating the Principle of Data Flow, where information cannot leave a LabVIEW Structure via it's "output" (right) side, Queues and Notifiers use the input connector as a "two-way" communication path.

Asynchronous Channel Wires provide a direct method (and metaphor) for synchronous, yet "directed", transfer of data from the Channel Writer (or, in some case, Writers) and Channel Reader (and/or Readers).  The "Asynchronous" (= instantaneous) nature is symbolized by the "Pipe" appearance of the Channel Wire that goes "over the top" of Structure edges, bypassing "tunnels".

In addition, Asynchronous Channel Wires gained several useful "missing features".  I'm particularly pleased with the "Sentinel" feature (implemented by "Last Element?" Writer input), which makes closing the Channel Wire nicely "requested" by the Writer (or Producer/Consumer "Producer") and acknowledged by the Reader ("Consumer"), much cleaner than having the Producer destroy the Queue and make the Consumer "error out" to exit.

Bob Schor

[Shiv0921]

Thanks Bob, that's very interesting. (and for the spelling correction too! Every day is a school day) 

Are there any caveats with the channel wires to look out for? 

[Bob_Schor]

---

@Shiv0921 wrote:

Are there any caveats with the channel wires to look out for? 

---

Two come to mind.  One is a design "feature" -- Channel Wires are implemented by software code created during the Development process, and are stored in a common Folder across all of your Projects.  [Note -- this is the "default" situation.  It didn't occur to me until I was writing this very note that possibly (but I doubt it) you could designate a separate "Project-oriented" location for your Channel Wire support ...]

One consequence of this design decision is that if you have two Projects that involve Channel Wires, they must name their Wires differently (the Wire names include the type of Wire, so you can have a Tag called "My Wire" and a Stream called "My Wire" without conflicts).  If, by accident, you create a Conflict and can't figure out how to "undo" it, you can always do the following:

1. Close the LabVIEW Project(s).
2. Go to your LabVIEW Data folder
3. Find the folder 20XX(yy-bit) that corresponds to the LabVIEW Version you are using (in my case, "2019(32-bit)".
4. Open the folder, open the ExtraVILib folder, and delete (or rename, if you are nervous) the ChannelInstances folder.

You've now "erased" all of your Channel Wire support code.  When you open your Project again, it will take 30 seconds or so and generate all of the Channel Wires you use in the Project (that it can find ...).  As the "conflicting Project" hasn't (yet) been opened, the Conflicts will be gone.  I recommend that you take the opportunity to change the name of the "conflicting wire" in one Project or the other at this time.

The other annoyance I found, which might be something I'm doing, or might be something not quite ready (and possibly fixed in LabVIEW 2020, I haven't tested this) is that Channel Wires (for me) don't seems to work consistently when used in both the Host and Remote parts of a LabVIEW Real-Time Project.  I've reported this to NI, and in the meantime have returned to using Queues for the RT Target.

Bob Schor

[Shiv0921]

Thanks Bob, it's good to know what to look out for as well as the advantages. Thanks for mentioning about the issue using them with RT as well, my next project is a real-time one so I'll bear that in mind if I do choose to use them