How come my shared variable updates are one behind?

[cirrusio]

I realized that I should add an example of what I am trying to do.  Here is a VI that simulates expected behavior.  The switch in the SV discussed above is the switch labeled Speaker.  Two things impact the behavior of this switch.  First, if the user selects Auto Speaker in the control under flags, the Speaker switch will go high for 5 seconds and low for 10 seconds.  Second, if the user selects the Link to Filter switch under the Flags control, then when the user changes the switch position labeled Filter, the Speaker should go high for 5 seconds following the switch of the filter from low to high.

I apologize that the logic is so obtuse, but it is necessary for my simulation purposes because we have an array of events that can effect the behavior of the two switches below (Filter and Speaker).  The code is faithful to the use - the loop containing the event structure would reside on the host and the loop that processes the switch state would reside on the server (PXI chassis).  The version is 2011.  Enjoy and let me know (if you choose to look at this) if you have any questions.

Cheers, Matt

[Zach-H]

Are you using the Queue to represent a shared variable you pass for flags between the host and the target? Or are you using another method to compete that? 

How do you handle updating the front panel speaker control from a shared variable for the autospeaker and link filter cases?

Race conditions are a common place with shared Variables. I wonder if that's not the case here. 

[cirrusio]

Thanks, Zach.  Race conditions are not the case -  have verified this over and over again.  The queue here is used to handle user interaction and set the flag byte properly.  The code you see in the consumer loop is pretty true to what is on the chassis, but on the chassis the variable 'Speaker' is a shared variable, not a local variable.  One thing that is important to note is that this is observed with no user interaction (so, once you hit auto-speaker, you can pretty much remvoe the top loop and the bottom will represent exactly what is happening on the chassis).  What I am observing is what was posted by the original poster 5 years ago - I update the shared variable, which is handled in a VI that is on the wire down the line from the VI where the shared variable is updated.  The handling VI reports no change in the value of the variable until one iteration (one second) after the initial update of the shared variable.  From the diagram I provided, you can see what will happen - the timer times out and flips the switch on the shared variable.  When the shared variable indicates that the state has changed, it updates the switch class with the new state and resets the clock.  But since the SV is one second behind, the SV state is updated twice thus resulting in the boolean bein set and then reset the following iteration.

When I get a chance (I am in the field right now), I will try to put something together that maybe you guys can run on your systems to observe this behavior.

Cheers, Matt

[Zach-H]

That would be great, Thanks Matt

[cirrusio]

OK...so I am unable to reproduce this behavior on another chassis.  I probably need to give a little more background regarding the issue.  The shared variable engine resided on an RT PXI chassis.  The controller used is the quad-core, 8110 that sits in an 8 channel chassis. We collect data on a 1 Hz basis from the 7 cards that reside in the chassis.  One of the cards is an 8 channel, S-series card that we collect data 2.5 MHz on all 8 channels.  Data from this card is aggregated each second and we attempt to fit 1000 exponential signals to 1000 chunks of data on each channel (8k exponential fits).  The details are not important, but it is sufficient to say that this is extremely CPU intensive - coupled with some of the other analysis we have to do, we use about 80% of each core on the 8110 during this processing time.

You can imagine that the system gets pretty hot in a properly climate controlled environment.  And unfortunately, we have been operating in a non-ideal environment (in a plane on a tarmac with no air conditioning on a hot - 90F+ - day).  It is possible that there was damage to the controller on one day when this system was operated in a very hot environment (a USB drive in the controller was hot to the touch).  Now, recently the system has been showing signs in the error logs of distress (and the users have been complaining that other things associated with some of these SVs are going wrong) - I have the error -195067023 being generated occasionally on the system hosting the SVE and there have been instances where the chassis has ceased communicating altogether.  All signs seem to be pointing to the fact that all of a sudden the controller can no longer handle the load.

So, for now, I think this may be beyond any software solution.  I will let you all know if there is anything else that seems fishy, but I will put my observation of this SVs behavior on hold.

Thanks, Matt