shared variables + timed loops + naming conventions + how to find all

[WHAVEman]

Being almost halloween, thought I'd share some more eerie behavior I've noticed with shared variables.

1st strangeness with timed loops already mentioned here:  http://forums.ni.com/ni/board/message?board.id=170&message.id=209475

2nd strangeness:  If you have a shared variable that is network-enabled, it is OK to use a "?" in the name (eg, "RT_Simulate?"). 
However, should you decide to change that variable to single-process, or if you create it that way in the first place, you will get this dandy message from the broken arrow you now have:

"LabVIEW could not generate code for the shared variable. You must open the VI in the project that contains the library where the shared variable resides."

..............whaaa?????      Loosely translated, this seems to mean "Don't use a "?" in your single-process variable names."

3rd strangeness:  I don't know if this has been mentioned before....
If you have an application that references a network shared variable, and the library has NOT been deployed, the app will hang for some time (approx. 7 seconds! on my machine) before returning with an error.  This seems to be the case whether or not the error ins/outs of the variable are wired.  This looks bad to me, and I'm not sure what is causing it (some sort of timeout when attempting communication with the SVE I assume).  Has anyone else noticed this?  It should be easy to reproduce.  Any ideas?

I haven't done any bug notifications yet, but will do if there are no positive solutions by next week some time.


-Have a Great Halloween Weekend

[WHAVEman]

Ok,  it's Monday now, and the 2nd problem I mentioned above seems to make a little more sense. 

I wasn't making the connection that single-process shared variables behave like old-style globals (they actually create a .vi file when you first drop them on the block diagram).   The only single-process vars I had used to this point had the RTFIFO option enabled.  Interestingly, with RTFIFO enabled, the .vi file does NOT get created, and the naming issue doesn't come up.

Anyway, it now makes sense why the 'could not generate code for the variable' error was showing up if you include 'bad' characters in the variable name of a single-process shared variable without enabling the RTFIFO.   And for what it's worth, I don't see much reason to use them in this way anyways!

[Chris_Cilino]

Whaveman,

Do you have autodeply turned on?

Chris C

[WHAVEman]

Nope...

Autodeploy is turned off. 

The host application should dynamically deploy/undeploy the library in the typical case.  However, if the host app is down (and the library then is undeployed) when the external app is started, trying to write/read the network variable hangs.  This only seems to be a problem if the library is undeployed when the external app first starts up and attempts to read from the network variable.  If the host app goes down once the external app was already up and communicating with the network vars, errors are returned much faster (doesn't seem to hang at all).

[Chris_Cilino]

WHAVEman,

Currently (as of LabVIEW 8.20) there isn't a way to programmatically interact with the shared variable engine outside of using DSC. If you had DSC you could "hack" a way to determine if a shared variable was deployed.

I think the best way to get around your program hanging is to have an initialize state where you write a dummy value to each variable. If the variable isn't deployed, then you should get an error out of the shared variable. Problem is that there's probably going to be a timeout associated with determining if the shared variable is deployed. But at least you can use the information from your initialize state throughout the rest of your deployed application.

Chris C