Shared Variable event handling--spurious events

[pltrogon]

This is more of a nuisance than anything:

Using the DSC module to register for shared variable events, the event structure always fires once for each variable registered for. For example, if I register for the shared variables "Var1" and "Var2", upon entering the event structure [in a loop], I'll immediately see two events [one for Var1 and one for Var2] even if the values for Var1 and Var2 haven't changed.

I originally figured that it's intentional--it appears to be impossible to use SV events without this "feature"--except it doesn't happen in "highlight execution" mode, which I find puzzling.

Why does this exist, and is there some magic way to disable it? Or is it a bug? Anybody who has ever used SV events undoubtedly has some way of dealing with this. Right now I just burn off the first N events, where N is the number of shared variables I'm registered for. But that's extra diagram junk and it really shouldn't be necessary.

[viScience]

Just curious...do you use the initial value property of your SV's?  I also use NSV events but have not noticed this problem.

[pltrogon]

Good question... but no. Some of the SV's have initial values but some don't [and some can't; they're custom data types].

I should have mentioned that I'm using 2010 SP1.

[Kyle_M]

pltrogon,

Are you able to post the code youre working on, or a simplified version which demonstrates this behavior? 

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

[pltrogon]

Kyle:

Here's a sample project with two SVs and an event handler VI. SV1 has an initial value but SV2 doesn't.The array displayed in the front panel should be empty after running--the SV's are not written to anywhere. I get two entires--one from each event--when I run the VI.

I noticed some new behavior when I put this together. In this example I use the timeout condition to terminate the loop. There is a timeout value around 110ms that defines the cutoff for this behavior--but the value is not consistent. With timeout values ~110 and below, I get no spurious events. But I DO get them for any timeout value of above that. So perhaps this issue is invisible to anybody who is generating events faster than ~10Hz. This may explain why I've been having inconsistent behavior when using the execution trace.

[edit: reposted as archive]

[Kyle_M]

pltrogon,

Can you include the  disable/enable/request value change notifications VIs so I can open the VI?

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

[pltrogon]

Kyle:

Sorry about that, here you go.

[pltrogon]

Any updates on this? I'm having occasionally inconsitent behavior with this which results in me losing some events [rarely the spurious events DON'T appear and my method for squelching them kills the next real event].

[viScience]

Just curious...Did you try to disable events on timestamp changes?  That is an option on the Request Value Change Notifications vi.

[pltrogon]

thanks, sachsm:

I tried and it didn't seem to help, but then I just noticed this:

When I select "value change only," any SV that does not have a value does not fire an event on initialization. All SVs with a value--not just an initial value but any current value at all--still fire off extra events. This feels a little bit like a feature now--a current value is, after all, just a value change in the pre-registration past--but if so I would expect people to be familiar with it and I'd sure like a way to disable it.