Shared Variable event handling--spurious events

[pltrogon]

Has anybody tried a very simple example like this to attempt to reproduce this behavior?

If you add more SVs you should see more events in the indicators. With the value "changes only" option selected, you will only see this behavior if the SV has a value.

[Edit: removed extra wire from diagram]

[viScience]

I tested this out with my system and some random collections of NSV's on both the cRIO and PC and it works as expected.  One thing I did notice

is that even with the registration set to value changes only I still received notification when I update a NSV with the same value, I did not expect that.

Is it possible your NSV's are actually being updated but the values are not changing?

[pltrogon]

No, the SV's are not being updated. Just to be sure, I checked the timestamp in the Distributed Systems Manager and the current value is quite old.

[pltrogon]

What version of LV/DSC are you using? I can't think of any other variables that would explain the difference in behavior between my setup and yours.

[viScience]

LV2010SP1

[pltrogon]

That's what I'm running too. Very odd...

[viScience]

Here is someone else with some similar problems

http://lavag.org/topic/14195-shared-variable-value-change-event-behaviour/

[JohnCS]

The behaviour you are seeing with NSVs may not be all that unexpected. To follow what is actually happening, I used a modified version of your sample VI with the array indicators moved inside the loop and put indicators on the Event Data Node. With this VI and by following the activity of the Distributed System Manager, I found that the timestamp of the first variable event that is returned predates the start time of the VI. Multiple restarts always come back with the same timestamp.

When the NSV event is registered, the SVE treats the registration itself as an event. This can be seen by looking at the Alarms and Events View in the Distributed System Manager the first time the VI runs. After the VI runs, the variable is active and remains deployed until it is undeployed, the project is closed or the process is stopped in the SVE. Even then the value and timestamp are still stored in the SVE. On the first event and subsequent changes, the current value of the variable is returned with the timestamp of the last change. 

If the variable is empty, then an event is not generated.

If the NSV is not deployed or the process is stopped when the VI is started, an event will not be generated.

If you start the VI with autodeploy off and the variable undeployed, there will not be an event until the variable is deployed. Then an event will be generated and the current value of the variable will be returned.

If you could think of it as the 0th member in an array of events, this may not be an undesirable trait since it records the starting point of the VI run.   

As to disabling this behaviour, I haven’t found a way to do this yet. 

JohnCS

[pltrogon]

JohnCS:

Thanks for the great reply. This is essentially a much-better-informed version of what I wrote above [or tried to, at least]. What you said sounds right, but I'm still mystified that this is the default behavior. When I register for a "value change only" event, I don't want a "SV deployed" event. I think this behavior should be [A] documented and [B] disable-able but I agree that it is likely not a bug.

[JohnCS · Accepted solution]

I agree with your comments. I didn't find anything new but now we know the boundaries of the "feature."  

Here is a white paper I just found that documents the behaviour we've seen.  

http://zone.ni.com/devzone/cda/tut/p/id/12176

Down the page near fig 7, it says 

.  .  . If a Shared Variable already has a value associated with it and a new accessor comes online, the accessor side buffer will contain the Shared Variable’s current value.

and later on

.  .  .  . If an accessor comes online when there are already values within the accessor side buffer, the accessor’s View will have the last value written to the Shared Variable. 

It looks like there is no way to turn this feature off.  If you want to do something following an event, one needs to ignore or filter out this first event. The time-date stamp seems to be the only reliable way to detect an old event. Looks like your original solution is the one.