How come my shared variable updates are one behind?

[Brian_Beal]

I want to write new values to shared variables by first reading other shared variables.  I have an event case that triggers when a front panel control value changes.  That control is bound to a shared variable.  In the event case, I read the changed shared variable using a node, then do some calculations and write to other shared variables.  The front panel shared variable doesn't change.  The front panel control does, though.  If I probe it, the old value is still there.  The next time I change it, the shared variable updates, but with the value I wrote previously.  It doesn't always do that.  Sometimes it updates right away.  I have even tried a for loop that reads the node several times with a delay between loops, but that doesn't seem to help.  I have tried using buffering and not using buffering, but nothing gets it done correctly.

[altenbach]

I'm not good reading words. Could you attach a simplified version of your code. It would make things much clearer to us. Looks like a race condition, though.

btw, what's a " front panel shared variable"?

[Brian_Beal]

I will try to make a simple example when I get to a computer with Labview on it.  The "front panel shared variable" refers to the shared variable that I am attempting to change using the front panel control.  The front panel control changes, but if I read the shared variable using a node, the value hasn't updated.

[altenbach]

Also try to run the program in "highlight execution" mode and watch the diagram.

[Ben]

HI Brian,

I ran into a similar situation with alarm events in DSC. THe value reported with the event was always stale (alarm would indicate HiHi and the value was below the threshold).

I ended up using data socket reads to grab the data and always had to read it twice to get the actual value.

I hope this helps,

Ben

[Brian_Beal]

Hi Ben-

I will try that.  I switched to Datasocket writes, but that didn't seem to help.

Brian

[Brian_Beal]

I am now using Datasocket Reads instead, and am doing it twice before I write to the other variables.  That seems to be working.

What is the difference between using a Datasocket Read by itself vs. Datasocket Open-Read-Close?  Any issues with using the Read by itself?

[Coal_Man]

The DataSocket Read will open the connection for you, which is fine if you only need to read once, but using the DataSocket read inside of a loop or somewhere where it will be accessed over and over again creates a lot of overhead for opening the connection at each read. 

To avoid this, you can open the connection when your program starts, read and write as many times as you want, then just close the connection when you are done, as opposed to opening and closing the socket for each read.

[Ben]

In my case I only used the "read" flavor and opened the datasocket when the app started.

The "read twice" still smells like a bug to me.

Ben

[cirrusio]

OK, I apologize to all who no longer care about this thread for reopening it, but here we are 5 y later and I am also having this problem.  It took about 15 h of staring at a screen and repeatedly starting and restarting my RT program before I finally could pinpoint the problem.  I too share this problem of my updates being 1 s behind, but here is a more complete description:

I have a switch that the user can update through a front-panel hosted on a local laptop that is connected to a PXI chassis via ethernet.  The control on the front panel is bound to an SV which is handled on the PXI chassis (there is no code on the host related to the switch other than the terminal itself).  When the switch is directly operated by the user, there is no "apparent" problem (I say apparent, because there is likely a delay that is not observed by the user).  The user can select a mode of operation in which the switch operates on a fixed duty cycle (x seconds high and y seconds low).  When the user uses this, the state of the switch is stored in an object that is polled by the main VI.  When time has elapsed in the current position, the switch is flipped via the same SV that is bound to the front panel control.  Immediately following the VI which flips the switch on the SV, the state of the SV in question is polled to see if anything has changed.  In this case, no change in state is registered the first time, so the switch state itself is never updated and the code rolls around again with the switch in the previous state and the time still elapsed.  It sends (again) the same command to flip the switch and so we now have two changes in SV state that are queued up to be handled.  This results in the switch flipping and then reverting 1 second later to it's initial state.

I can work around this, but this seems like undesirable (and undocumented) behavior of the SV (ok, maybe the undocumented thing is unfair since I may be too lazy to dig far enough ).  Since the previous poster solved his problem via datasockets, would someone from NI (or anyone who is familiar with this issue) like to return to the original question and 1) explain whether this behavior is expected or not and 2) why?  I actually like SVs, but this kind of thing frustrating.

Thanks, Matt