LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variable not updating before releasing the error value

I have found this strange behaviour of shared variables: it seems that they act as they have performed their duty (and released their error value, allowing the flow to proceed) 20ms before the variable is actually updated. In this way I incur in race condition, even if I link the error line, use semaphore or sequence case. Is this the normal behaviour? Is there a way to prevent it?

In attachment there is the VI I used to test it.

0 Kudos
Message 1 of 6
(3,117 Views)

@Daniele88 wrote:

it seems that they act as they have performed their duty (and released their error value, allowing the flow to proceed) 20ms before the variable is actually updated.


It should actually be 10ms.

 

The way the shared variable works is it writes into a buffer.  When the buffer gets full (8kB) or a timeout (10ms) occurs, the buffer is then written to the variable server.

 

Read up the help for the Flush Shared Variable Data.vi for all of the details.  Use this function to force the buffer to be written.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 6
(3,114 Views)

Sorry, I reported your answer as the solution befor actually testing, and now I found that even the flush VI allows the flow to go on before its task is actually completed. The delay between the release of the error value and the update of the stored value is usually reduced to 0.25ms, but the actual delay is randomly distributed with a larger spread: one time the measured delay was of 257ns, enough time to perform 265000 reading instances between the data flush and the actual update.

Again, I attach the VI I used to performed the test, along with the results of 1000 tests.

0 Kudos
Message 3 of 6
(3,063 Views)

Can't run your VI without the library containing the shared variable.  But this behavior does not surprise me, especially if they are network published shared variables since TCP/IP transactions must happen in order to get the update to the variable value.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 6
(3,046 Views)

So, build something that check the variable and keep the code frozen until the variable is updated is the only way to avoid race condition? And why this kind of thing is not already implemented in the definition of the variable itself? And how can the VI check if there is en error during the writing, if the error value is passed before the writing is done?

 

By the way, you can replace the shared variable in my VI with the one of your choice, what is important is the general behaviour of this element.

0 Kudos
Message 5 of 6
(3,034 Views)

I have had so many timing problems and race conditions with shared variables (particularly network shared) that I now avoid them for anything that is timing critical. They are excellent for some applications, particularly for transporting data between machines across a network (eg. from a DAQ rack to a display pc) and the ability to access them programatically is incredibly useful (and should be expanded to single process vars too if possible) but if the application is time or update critical then use wires, globals, FGs, queues, or some other more deterministic mechanism for getting data from one place to another.

 

Daniele88 is right with the 20ms - I know NI state 10ms in the documentation but I too have had cause to measure the delays and 20ms was what i got too!

 

Yes, the flush does speed things up, but still not without delays. You write a value, and the Shared Variable Engine goes off and does its thing (writing to the buffer and possibly flushing the buffer too). Meanwhile, elsewhere, you read the value. The read node performs the read of whatever is there and releases its data regardless of whether the SVE has finished updating the value or not. If you want the read node to wait for new data then you can use the timeout facility on the read node, and that can be very useful. But for your application, if it is that time critical, perhaps SVs are not the best tool for the job.

0 Kudos
Message 6 of 6
(3,029 Views)