Strange notifier behavior

[St3ve]

Hi all,

I've been experimenting with notifiers before I use them in a project and have noticed what I think is some very strange behavior. This is what happens (using attached vi):

1. Press button 'generate new value'. This writes a value to a notifier.
2. Press 'Read Value' button. This grabs a reference by name to the notifier, waits for a notification (0ms) and then closes that reference. The FP indicator 'CV at Reader' displays the value read and 'timed out?' shows if the wait on notification function timed out. Also the reference is displayed as a numeric so we can see what's happening.

Now here is the confusion . The first time you press read value it returns the correct value, then if you press it again and again and again... you don't ---> the wait on notifier times out every subsequent time.

This behavior is confusing because each time we are grabbing a new reference to the notifier therefore we should expect the same behavior each time. If we were reading from the same reference each time then I would expect to get a value the first time and timeout on all subsequent reads until a new notification is asserted.

Now for double confusion ! Now if you generate a new value then press 'read value' and then 'read value 2' both return valid data without timing out ---> What is the difference between pressing 'read value' twice and pressing <'read value' followed by 'read value 2'>. In all cases we grab a new reference to an existing notifier, read from it and close it.

It seems that a new reference is 'newer and more unique' when called in a different loop??

Thanks for any help,

Steve.

P.S. Further confusion is that as we create the reference to the notifier in the read loop AFTER the notification was asserted we should NEVER see that notification in the read loop. Unless we are using the 'wait on notification with history' primitive which incidentally does work as would be expected.

[tst · Accepted solution]

An important thing to understand about the behavior of the Wait primitive (and this is documented in the help) is that each instance of the primitive on the diagram maintains its own history. The reference is irrelevant in this case, as long it points to the same notifier.

This should also help explain your second issue - each instance of the primitive has its own notification and until it reads it, that notification remains there waiting for it to read it.

As for your third issue, have a look at the Ignore Previous input, which defaults to F.

The wait with history was created precisely because of this issue and mainly to handle a case where you use the same instance for multiple notifiers (such as iterating over notifiers in a loop). The help should say that it has some overhead.

[St3ve]

Thanks,

It is indeed in the documentation, my error for not reading thoroughly! I had got a bit hung up on the labview paradigm of open ref to X > operate on X > close ref to X. It seems like the wait on notifier node doesn't strictly follow this and that is why I was confused.

After reading the help documentation properly I still have a couple of points I am unclear on:

1) In what scenario can deadlock occur using the normal wait on notification? and how does the 'with history' prevent it?

2) I am interested in using the 'wait on multipe' function. Essentially, I am thinking of using a number of notifiers as a 'current value table'. There will be a network comm loop waiting on all of these notifiers (using the wait on multiple) so that the CVT can be synched with another CVT over the network without having to poll it. After reading the help I am thinking I actually need to use the 'wait on multiple with history' as it talks about not dropping messages. Where do the dropped messages occur with the 'wait on multiple' and how does the 'with history' prevent them?

3) how much overhead does using the 'with history' actually introduce?

I'm currently experimenting with these functions trying to really understand them before using them as the backend of my Comms/CVT. Any light you may shed on the ins and outs of their functionality is much appreciated.

Thanks, Steve.

[tst]

If you want to see what caused NI to include the history functions, have a look at this thread.

NI has an implentation of a CVT. You may wish to use that instead of writing your own. I can't say I thought about it, but I'm not sure how much work you'll need to do to create your own. Also, remember that once a W4N primitive reads a notification, it won't be able to read it again. You have to preview the notifier if you want to get the current value (and you can't use a timeout for that, thus sending you back to polling).

I haven't really used the history prims, so I can't comment on their actual performance.

[St3ve]

Thanks for the link it's useful to see these things.

I have seen the NI implementation, it is based around 2 FGVs so you can't access any of the variables independantly of one another as they are all essentially wrapped up in one FGV. I've been thinking about a CVT with either single element queues as a back end or notifiers. This isn't for a particular application but more an exercise for future projects.

Notifiers seem attractive as I can have functions which are waiting on a value change. Single elemnet queues on the other hand can be used to automatically enforce a mutex if required - if all writers are first required to read then, if a writer has popped the element all other writers will be forced to wait untill it writes the new value back.

This is a bit muddled in my head at the moment and I haven't really had time to get much further. Anyway if I ever make any progress I will post it back on the forums and would be grateful for comments from those with the knowledge!

Many thanks.

[tst]

If you're using 2009, you may wish to use a DVR instead of a SEQ. They're not named, but it's harder to cause deadlocks when using them.

As for the CVT, you should consider whether you actually need the feature where you want your code to wait on value changes. If you want it all the time, you can use W4N with an infinite timeout. If you don't want it all, you can use the preview prim, and if you want to select programmatically, you can wrap the prims in a case structure.

[St3ve]

I am using 2009. I had't thought about the DVR as a CVT but it seems another likely candidtae, I quite liked the flexibility of named access of the SEQ's and notifiers.

The idea of waiting on value chages is specific to a cRIO where I want certain values from the CVT on the RT to be synchronised with the host PCs CVT. I thought rather than polling the CVT I could have a W4many node that on seeing a value change in one of the varibles triggered the value to be synchronised accross the network.

As I said, it's not even clear in my head yet. Howvever, any ideas and suggestions are always welcome.