LabVIEW
Notifier clarification
Solved!
I can't seem to find an exact answer to this so I wanted to ask. I use notifies to pass data from a primary loop to a secondary loop for the secondary loop to do disk write operations. Do I need to use the cancel notification once I read it, or periodically clear the notifier in anyway? This is on a RT target that will run 24/7 - 365.
I actually just thought of another question. Lets say I also have several primary loops calling the single secondary loop. Does that change the answer to my question above?
I have included an example picture.
@erfigge wrote:
I can't seem to find an exact answer to this so I wanted to ask. I use notifies to pass data from a primary loop to a secondary loop for the secondary loop to do disk write operations. Do I need to use the cancel notification once I read it, or periodically clear the notifier in anyway? This is on a RT target that will run 24/7 - 365.
No... "Wait on Notification" will execute as soon as there will be any notification available, and you need not clear it...!!
@erfigge wrote:
I actually just thought of another question. Lets say I also have several primary loops calling the single secondary loop. Does that change the answer to my question above?
I have included an example picture.
What do you mean by "several primary loops calling the single secondary loop"??
From what I can see by looking at your simplified VI you do not need to worry about cancelling the notification nor clearing it periodically. The notifier does not build a queue and therefore you will not be clearing up any memory by cancelling the notification. One thing to be aware of, notifiers are "lossy", meaning that when you send a notification it automatically clears the previous notifications. Consider this, you are using this to log errors to a file, theoretically if the secondary loop is writing to the file and two more errors occur in the primary loop before you finish writing to the file, you will only have record of the last error when the loops comes back around to check for notifiers again. For something like logging errors, I would highly recommend that you use a queue instead of a notifier and flush the queue everytime through the second loop. That will ensure that you don't miss an error message.
Sorry, I should have been more clear on the naming of my loops. Lets say loop 1 and loop 2 are doing something, and either one of them could trigger the "true" condition at any time. The bottom loop receives the notification and writes something to disk. Would this be the correct way of doing this soft of thing?
@Charles_CLA wrote:
For something like logging errors, I would highly recommend that you use a queue instead of a notifier and flush the queue everytime through the second loop. That will ensure that you don't miss an error message.
Using flush a queue will not ensure that no error message will be missed from getting logged... Also flush isn't required in secondary loop, just Dequeue should work fine... What say??
@erfigge wrote:
Sorry, I should have been more clear on the naming of my loops. Lets say loop 1 and loop 2 are doing something, and either one of them could trigger the "true" condition at any time. The bottom loop receives the notification and writes something to disk. Would this be the correct way of doing this soft of thing?
Ohh this should be avoided, as suggested QUEUE is appropriate for such requirements... or in case of Notifiers, there are good chances that the data might be overwritten/missed out.
@moderator1983 wrote:
@Charles_CLA wrote:
For something like logging errors, I would highly recommend that you use a queue instead of a notifier and flush the queue everytime through the second loop. That will ensure that you don't miss an error message.
Using flush a queue will not ensure that no error message will be missed from getting logged... Also flush isn't required in secondary loop, just Dequeue should work fine... What say??
A flush will still ensure that all of the error messages are processed. I much prefer using Dequeue if I am acting in another loop. If this is a final action, then flush works perfectly. (I admit I haven't read the rest of the thread to get a good context).
Flush queue allows you to grab all messages and process them at the same time. Some file IO takes longer to access the file than to physically send the data, hence if I flush the queue and send it as a block, it should be faster than writing line by line. Using a queue vs a notifier is what will allow him to not miss a message. Using the flush vs dequeue will allow the loop to be efficient
Ah, good point on the data loss......
So, I would say then this should be good (I forgot to rename the top loop to loop 1 when I copied it) for logging errors with a queue:
Lastly, just to verify on the notifier I am understanding it correctly, when the ignore previous is set to false, if there is a notification sitting there which hasn't been seen before by that instance of "wait on notification" when it initializes, it will trigger. If the ignore previous is set to true, even if there is an old notification sitting there, since it is timestamped before the "wait on notification" was initialized it will will not trigger until another notification is sent.
Other than potential data loss, is there another reason for queue or notification over the other?
@erfigge wrote:
Other than potential data loss, is there another reason for queue or notification over the other?
That's pretty much it. Use a notifier if you only want the latest data, use a queue if you have to have all of the data. I explain them to novices this way:
A queue is like a to do list from your wife, once on the list it doesn't get off until you do it.
A notifier is like status updates to your boss, you can send him as many as you want but he will only ever read the latest.
