Shared Variable Timeout Explanation

[DailyDose]

Hello, using shared variables in my system.  While using 'Read Variable with Timeout Function' I was hoping I could get some clarification on the specifics of the timeout. 

First off (and this is just a gripe) the help specifies that timeout has a default of 0, however the input is still bold and required which is interesting.  Not sure if that's an oversight or intentional.  

Second (and this is the actual question), what exactly does timeout imply in this?  If I input a value of 10ms, does this mean that LabVIEW will wait up to 10ms for data to be available or does this mean it will wait 10ms for new data to be available? 

(Also... Shared Variable(s) is apparently not a working Label)

From what I know about shared variables (please correct me if I am wrong), a value for a shared variable remains on the network always. So as long as there is an existing shared variable, the timeout will essentially be ignored because the data is there.  So from a good programming practice, don't rely on the timeout as a sort of wait for the inherent loop like one might do for a serial read?

[tyk007]

Shared variables are hosted on a machine and are a TCP service, just like many other services eg. Port 80. A small service application runs on the host machine (tagsvr.exe) that responds to connections on specified TCP ports in order to "share" those shared variables. In order for another PC to read those shared variables it has to be able to connect to the machine that hosts the variables via the correct TCP port in order to send/receive the specific protocol messaging. At the end of the day shared variables are just an abstraction over TCP service connectivity, even if the host machine happens to be the same PC as the one running your LabVIEW application.

My understanding of the timeout is that this is the time given for your LabVIEW application to retrieve the shared variable value ie. perform the necessary messaging over TCP to retrieve the value from the remote server.

[DailyDose]

Okay, so it's a matter of the data either being there or not being there.  Couldn't care less if it was different.  Thank you

[tyk007 · Accepted solution]

It has been a while since I looked into this, and I think I have given you bad information. I have put you wrong with regards to the way the client connects to the server; NI-PSP is an event based system rather than polling. Read this paper here for details "under the hood" http://www.ni.com/white-paper/4679/en/ and this presentation https://forums.ni.com/t5/ALARM/All-You-Need-to-Know-About-Shared-Variables/gpm-p/3525900

Based on that I tried an example of using the Timeout on a PSP Read node and I believe you are correct in your suspicion - if you set a Timeout on the node (ie >=0) then if the data does not delta within the timeframe you will receive a timeout indication. This makes sense if the data is event based - there is no new event broadcast so the node does not receive a new notification in the allotted time. The data returned by the node is the last received value even if the Timeout occurs. If you do not set a Timeout (-1) then the node simply blocks until the notification is received which may also not be desired behaviour.

The behavior is the same if you use a shared variable node rather than the PSP API. The shared variable node is, in essence, a thin wrapper around the PSP API. Without Timeout terminals the node as a default Timeout = 0ms and returns the previous cached data value if no new event has been received (effectively timed out).  Adding the Timeout terminal exposes the Timed Out terminal and thus you can see the timed out action occurring.