shared variables problem

[JChec]

I've just started using shared variables and having problems with them. The problem is straight forward, so maybe I'm just missing some valuable information which I should know about them.

I have a host PC and and remote device (CVS).On the host PC, I have a section of code which sets a boolean shared variable to true (tell the CVS to run some code) and then goes into a while loop which runs until the same boolean shared variable reads false. (this false is set by the CVS to say its finished its code)

The remote device waits in a while loop until it reads the shared variable as true and then runs some code and sets the shared variable to false to tell the PC its finished. So its quite simple, but as the PC enters the while loop, it reads false straight away before the CVS has got any where near to writing a false to it.

I've tried changing the bufffer, Fifo, but not helping. Any suggestions?

I've read through some of the forum discussions, but theres just too many on shared variables to actually find 1 which solves my problem.

Thanks

[ThHagel]

Hello,

today I had a problem using shared variables that maybe is comparable to yours:

I found out that writing a new value to a SV does not update it immediately. If I try to read from the same SV directly after writing it, I receive its old value. I wrote a small test-vi that measures the update time and I found out that it takes many milliseconds (I measured up to 40) until the SV delivers the new value.

For my problem I found an easy way to avoid that write/read sequence, but in your case it might be necessary to check the SV value changes. You could do this by using the value-change-event, but I guess this is only available if you have the DSC-Module installed (ValueChangeNotifications-VI's). Another way would be polling or maybe also a wait-operation (but who tells you how long to wait? hmmm).

You could also use two variables instead of one. One triggers your CVS to start and the other one tells your PC that CVS-Routine is finished. If you always reset the boolean Trigger-Variables directly after detection of a True-Value, this might work well for your application and avoid the update-delay-problem.

Maybe someone else knows how to avoid this update-delay for network-published SV in general. I would also be interested in a more direct solution for this annoying problem.

Regards,

Thomas 

http://www.hagel-engineering.com/NI_Forum/Test_SV_Update.zip

[JCFC]

Hello to all,

I think the delay depends of the buffer size.The new value is placed in the last part of the buffer and DSC extracts one by one until it gets the new value. Just guessing, maybe someone can test it and confirm or denie it.

[ThHagel]

Hello,

the update-delay occurs even if buffering is disabled.  Try the test-vi...

[JCFC]

my LV is 8.2

[Wayne.C]

JChec,

You've created a race condition.  There are not guarantees as to how fast the value will be updated in the SVE.  Suggest you add a second variable to signal when the other process is complete.

[JChec]

Hi all,

thanks for your input, tried some of the original suggestions but strangely my initial problem went away after upgrading to labview 8.6, but still 1 of my shared variable problems exists. i'm sending image data from my CVS to my PC and the data seems to be taking a long time to be correctly read, much more than 40ms..itherwise i read old images. the data's sent as strings and unflattened on the PC side

[ThHagel]

Hello,

good to know that an upgrade solves a part of your problem, I will also upgrade. Another good reason to upgrade is that LV8.5.1 gets very slow while programming as soon as you use many Shared-Variables and LV 8.6 doesn't (hopefully).

The problem with transferring data across a network using shared-variables, is that you have no control about the transfer itself. In earlier projects we used a simple tcp-connection to transfer large amount of image-data from a CVS to a PC. It worked very well for us. I've never tried it with shared variables.

If you want to try that (it's quite simple) check the LV-Examples for TCP communication.

Good luck,

Thomas

[LabBEAN]

JChec,

In LabVIEW 8.6 you can right click your shared variable and show the input (I32) and output (bool) timeout terminals.  Before conducting any operations on your variable, drop down a shared variable read node, show the timeout terminals, and set the timeout input terminal to 500 ms.  It is necessary to initialize communications with your variable each time your VI runs.  The value you receive will be invalid.  If you set your initial read timeout less than 500 ms, then you may get error -1950679035 (variable not deployed) or warning -1950679034 (no value).  This is strange behavior, as the variable does not actually timeout regardless of the timeout setting (per the timeout output terminal).  By setting a 500 ms timeout on my initial read, I've been able to get around polling for good values before starting (and subsequent long delays [> 50 ms] between writing and reading).

The last post on the following discussion implies that the initial read (in their case, looping) must be done once per data source:

http://forums.ni.com/ni/board/message?board.id=170&message.id=231104&requireLogin=False

Then, for subsequent reads, wire a timeout of at least 50 ms to guarantee new data.  For unbuffered shared variables, the timeout output terminal will be True when the same value is read, even if the same value has been newly written.  This is not the case for buffered variables.  If you enable buffering (see Shared Variable Properties >> Network in LabVIEW 8.6) and set the buffer size to 1, then the timeout output terminal will be True when the buffer is empty.  That is, timeout will be True when the variable does not receive a value of any type during the specified timeout period.  In this case, the shared variable will post a warning 180121602 (buffer empty) and return the last known value.

So, for your application, you could use a shared variable with a buffer of 1 and key off the timeout output terminal to guarantee new data.

Quick Note:  If you are deploying your variable libraries programmatically via DSC or the Application.Library.Deploy Libraries invoke node, make sure you deploy before your main application begins (e.g. use VI Server to deploy then run main application). 

Regards,
Jason

Blue Ridge Test, Inc.

[LabBEAN]

Update:

Initial read with 500 ms timeout may not be necessary.  A 50 ms dumb wait at the beginning of the VI seems to allow future Reads to function.  I'm working with NI to understand whether "warmup reads" are necessary, as there is conflicting information.

Use Read / Write shared variables wherever possible!  You only need to deploy your libraries outside your main application (e.g. with VI Server) instance if you're using Write Only variables.  (Otherwise, the Distributed System Manager quality will be Nonexistant for ~45 seconds.)

Undeploy LVLIBs before deploying new LVLIBs (this could be related to restarting NI OPC Service).

Bound shared variables ignore repeat values.  The timeout output terminal reflects this:  Read times out if the same value was just written.  This is what I was seeing when I posted about timeout behavior above.

See attached for Demo VI which uses shared variables and OPC.  You can walk down the buttons on the left to shutdown NI OPC Servers (Tools >> Options >> Service tab >> check "Automatically start as a Windows NT Service"), programmatically load a new OPF file, start NI OPC Servers, Deploy libraries, and exercise different types of shared variables.

Jason

Blue Ridge Test, Inc.