shared variable timestamp strange behavior in LV8.5

[Garvacious]

Can anyone explain this behavior to me?

When reading the timestamp from a network shared variable,  the timestamp is incorrect if I stop and re-start the VI that is reading the shared variable.  It seems that when the reader VI is restarted it resets the timestamp to the time that the reader VI starts.  I dont understand this behavior- if the timestamp is stored in the SVE, why does restarting the reader VI affect the timestamp at all?   Isn't the timestamp supposed to indicate the time that variable was last written to?

Another observation is that when the Variable Manager utility is running and the shared variable has a "watch" enabled on it, this behavior does not happen- resetting the reader VI does not reset the timestamp.

[Kameralina]

Hello Garvacious.

I tried to reproduce the issue that you described, and I indeed did observe the same behaviour.  My feeling is that this is not expected behaviour.  However, it is important to note that any VI that references a shared variable will automatically deploy the library containing that shared variable.  If nothing else is in run mode, perhaps the library gets redeployed when the reader VI is relaunched, thus changing the timestamp.  Having the Variable Manager open may prevent the library from being redeployed.

I will look into this further and most likely report this to R&D since I was able to reproduce the issue in LV 8.6.

[Garvacious]

Thanks FieldKam-  I will try to deploy the SV library programmatically in the host application, maybe that will help.  However, the host app right now will "Autodeploy" when it is started so I'm not sure why the reader app would have to re-deploy the library.  Thanks for the help though and I'll let you know if I discover anything new re: this issue.

[Garvacious]

OK, this is now becoming a major problem.  The erroneous updating of the timestamp is preventing me from "checking" the variable for stale data when I read it.   Is there any other workaround for this problem other than keeping the Variable Manager open?  

BTW- I do have the shared variable library "Autodeploy" option checked, so it should not be redeploying the library every time I restart the client program.

[Kameralina]

Upon looking further into this issue, we do believe that this is expected behavior. I now believe there are a few ways around this though.

One easy one would be to turn off Autodeploy. When deploying you should get an updated timestamp. If you don't autodeploy you shouldn't see this issue.

Another thing you might try would be to set up a variable on the client machine and use network binding to bind those variables together.

[Garvacious]

Sorry, my statement in the earlier reply should have read: "BTW- I do have the shared variable library "Autodeploy" option UN-checked, so it should not be redeploying the library every time I restart the client program."  Apologies if that caused some confusion.

To clarify, it does not matter whether the library is being auto-deployed or not, even if the library is not re-deployed upon starting the reader vi, the timestamp is updated.  

I have noticed this when using the Datasocket API to call PSP variables too, the Datasocket Read reports new data on the first call, becuase the timestamp has been updated.

I hope that this is corrected in an upcoming LV version- it does sort of defeat the purpose of having a timestamp on the shared variable.

[NordicViking]

Hello,

I am having exactly the same problem with wrongly updated timestamps of Shared Variables, namely the timestamp updates when I do a read via the datasocket. Is there meanwhile any solution around or any new knownledge on the problem?

I still persists with Labview 8.6.1

Thanks, Normann

plass@kerntech.de

[David_L]

This is still known behavior which is being investigated in R&D. Reading a shared variable doesn't actually update the timestamp. However, the timestamp for an unbound variable is not persisted when there are no clients connected to the variable, and so the timestamp will change when a client connects. My suggestion would be to simply leave your VI running when the variable is expected to change.  Or you can save your previous timestamp when the VI stopsand reload it when you restart to VI.