LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Notifier clarification

Solved!
Go to solution

Thanks Charles.  Using your example of "flush queue" you are probably using the preview queue element to wait on data and once data is present you actually go to the flush que?  My sub vi isn't set up for an array, but that is easy enough to fix.....

New Bitmap Image.jpg

0 Kudos
Message 11 of 13
(661 Views)
Solution
Accepted by topic author erfigge

@erfigge wrote:

Thanks Charles.  Using your example of "flush queue" you are probably using the preview queue element to wait on data and once data is present you actually go to the flush que?  My sub vi isn't set up for an array, but that is easy enough to fix.....


Precisely, I use preview to wait (I wish flush had the capability to wait natively) then flush. Flush works better in scenarios where you are opening the file, writing the data, and closing the file in the loop. This is typically the case in error logging, hence why I recommened it. One other piece of advice, I would wrap the error clusters with another cluster and add a string to denote which loop fed you the error. sometimes you can tell just by looking at the error and other times... well not so much Smiley Happy

Charles Chickering
Architecture is art with rules.

...and the rules are more like guidelines
Message 12 of 13
(657 Views)

You do seem to be getting the jist.  Ignore Previous == False will process anything already in the notifier Ignore previous == FALSE will only process new notifications.

 

Notifiers are often chosen for a one to many use case.  Since wait on notification does not remove any information from the "Single Element Queue" that a notifier really is underneith all "Listeners" have the opportunity to respond to the latest message

 

Queues are perfered for Many to One use cases since they have a memory and more than one "Talker" can write to the queue without overwriting data from another source.

 

You also stated this is going on a RT system.  One caveat should be discussed.  DO Set a maximum queue length on a RT system.  Make it big enough to handle a few messages but do not let the queue grow to the point it impacts system performance (Or generates a "Not enough Memeory" Error).  If the queue starts growing larger and larger you may have a file I/O problem and your system should handle that error state without crashing by some other method (Log to alternate file/disc, Go to safe state and notify User, Forget the log it's not that vital, etc... something you can live with that isn't a crash)


"Should be" isn't "Is" -Jay
Message 13 of 13
(654 Views)