LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Notifier or queue for checking if data exceeds limits?

Solved!
Go to solution

I have a continous acquisition based on a queued message handler, and my DAQ is acquiring  voltage and current and displaying both. Data is passed to the display using a notifier and to log on a queue.

 

I have a loop for checking that the voltage and current aren't exceeding certain limits, and if they are acting accordingly. Would it make more sense to send the data to this loop using a queue or a notifier?

 

I *think* a notifier would be fine, as it doesn't really matter that this loop receives every single piece of data, it just needs to recieve enough of it such that if a limit is exceeded it will pick up on it. However it seems like notifiers are more often used to do with syncing, and so i don't know if a queue might be better because of something I haven't thought of. Just want to check. 

 

Thanks

 

 

 

0 Kudos
Message 1 of 16
(1,629 Views)

Working on a similar program but I have never been a fan of the QMH. I am going to use Channel Wires. One loop will be acquiring data as fast as it can and putting in into a Channel Wire. I can then branch this one Channel Wire to both my logging loop and my safety limit loop. Using the Channel Wires with Abort my safety limit loop or any other loop on the Chanel Wire can stop the test through the same Channel Wire.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 2 of 16
(1,595 Views)

Fair enough. My program is already built and in use so I don't wish to convert it from a QMH,

this data scanning is just an addition.

 

Which type of channel would you use for this? I wasn't aware that there are any channels which can communicate one-to-many where every reader gets every piece of information.

 

It seems to me my options are either use multiple queues/channels or use a single notifier, but I don't know if the notifiers are appropriate for continuous data reception, or if they're more just used for syncing.

0 Kudos
Message 3 of 16
(1,542 Views)

@Shiv0921 wrote:

 

Which type of channel would you use for this? I wasn't aware that there are any channels which can communicate one-to-many where every reader gets every piece of information.

 

 


A "Tag Channel" does exactly that and can even have multiple writers

 

Here's a screen shot of my "proof of concept" I have been working on...PoC2Capture.PNG

I know I said I dislike QMH and this is going to become basically an SMH, it just makes more sense to me...

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 4 of 16
(1,530 Views)

Others can probably offer better advice. I mainly use User Events to communicate between loops and occasionally queues for other communication.

 

Queues are lossless, that is data is not lost. They work best one-to-one or many-to-one. You could have one-to-many if you DON'T CARE about which loop receives the data. An example of the latter is you have a bunch of loops that save data and a loop which gets the data. For that case you don't care which loop saves the data.

 

Notifiers are lossy, that is data can be overwritten. So if you have a bad event, it may be possible that a good event overwrites it, and thus you miss the bad event. I don't know how your setup is, so I don't know if Notifiers will work for you. Notifiers can go one-to-many with the same data, but as I said earlier, it is a lossy communication method.

 

Channels, I don't use. I highly recommend you look up Bob_Schor's posts about them. They are highly informative.

 

User Events - very flexible, but a bit of more work in the beginning. User Events are lossless and can be many to one, one to one, one to many, many to many. You can also have one event respond to different user events, like a queue receiving information from multiple queues.

 

Hope that helps.

 

mcduff

Message 5 of 16
(1,526 Views)

Thanks for your response mcduff, that helped clarify a lot.

 

Yeah I definitely wouldn't use one queue, am deciding about using multiple queues or one notifier. I think the notifier would be sufficient. The idea is that if the voltage for example goes over a limit, it will trigger other things to change and therefore lower this value. If the voltage goes above for 1 second and I miss it using the notifier, but it then drops back down on its own then it doesn't matter whether I've missed it as it's already dropped back down so I don't need the system to react. If the voltage goes above and stays above then the notifier will catch it as it will be multiple signals above, and that's the event that I need to program to react to. I don't need any logging of whether the voltage has ever exceeded the limit either, as my logging is queued and is elsewhere, so signals being overwritten is fine.

 

I already have one of these other loops using a queue to check the data, but as I came to add another it dawned on me there might not be a need to have so many queues, when they can all tap in to the notifier going to the display that I already have set up.

 

If anything it seems to me that a notifer would in some ways be more responsive(?) I don't want fifo if it means for any reason data builds up, I just want to know what the most recent value is.

0 Kudos
Message 6 of 16
(1,500 Views)

Thanks for that RTSLVU, that's interesting.

 

I think for now due to time constraints I'm going to stick with what I know. But you've peaked my interest and I will do more reading into channels before my next project, lest I miss out on any of their advantages, so thanks for that.

0 Kudos
Message 7 of 16
(1,496 Views)

@Shiv0921 wrote:

Thanks for that RTSLVU, that's interesting.

 

I think for now due to time constraints I'm going to stick with what I know. But you've peaked my interest and I will do more reading into channels before my next project, lest I miss out on any of their advantages, so thanks for that.


There are some things to watch out for when using channels regarding moving the project containing a VI with channels to a different computer.  Also some stuff about updating typedefs.  Some other things as well.  I haven't thought about channel wires in such a long time because I got stung by some of those caveats and didn't want to deal with them again until I better understood everything about them.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 8 of 16
(1,479 Views)
Solution
Accepted by Shiv0921

With your further description, a notifier sounds like the simplest effective option.  I wouldn't consider notifiers to be *more* responsive than queues or user-defined events, but they can be *equally* responsive and simpler to implement.

 

It sounds like you're ok with (and probably *prefer*) the fact that Notifiers are inherently lossy.  Be aware of the 'ignore previous' input to the "Wait on Notification" function.  The attached vi showed some surprising behavior for me, but I suspect this is very system dependent.

 

Specifically, when the producer's "Send Notification" lines up *exactly* with the very short time between iterations of the consumer's "Wait on Notification" while 'ignore previous' is True, it's possible for a single notification to be missed *entirely*.  That's how it worked here on my end with the default inputs.  When I tweaked the timeout or the stall by a  single millisec OR any time 'ignore previous' was False, the notification was received.

 

This *exact* timing lining-up is based on Windows software timing.  If I felt like running this example 1000 times, I'm sure I'd *sometimes* see the notification due to Windows timing irregularities.  My point is simply *awareness* that there are specific circumstances where 'ignore previous' = True can make you miss things you might have expected to catch.  It's a potential not-particularly-obvious pitfall of a Notifier.

 

 

-Kevin P

 

notifier example.png

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Download All
Message 9 of 16
(1,474 Views)

@Kevin_Price wrote:

Specifically, when the producer's "Send Notification" lines up *exactly* with the very short time between iterations of the consumer's "Wait on Notification" while 'ignore previous' is True, it's possible for a single notification to be missed *entirely*.


A Notifier is great for sending tag information to many threads.  Because you are constantly checking the Notifier, do make sure the Ignore Previous is set to FALSE.

 

I have tried using a Notifier with the Ignore Previous set to TRUE before to try to catch an event I was causing.  But it caused way too many weird race conditions.  In this condition, I found a queue to be easier to get right.


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
Message 10 of 16
(1,468 Views)