What triggers the non-server vi to connect to shared variable server?

[Jeff in Pleasanton]

My application uses cRIO as the shared variable server.  The machine control algorithm also runs on cRIO.  The event-based user interface vi runs on My Computer.

I used breakpoints to determine that the "My Computer vi" does not connected to the shared variable server in cRIO before or during the first pass through the timeout (25 ms) event case.  In fact, I cannot figure out exactly when that connection takes place.  I cannot find a vi or primitive to force the connection.

This is an issue because two of the shared variables are misbehaving at startup.  They work fine after the initial glitch.  The glitch is that two of the shared variables revert to zero (their default value, I assume) for one 25 ms event timeout period, then jump back to the initial values I assigned to them.

Does anyone know if there is a way for me to force the non-server vi to connect to the shared variable server?

[Jeff in Pleasanton]

Replying to my own question...

I've heard that my problem is caused by a shared variable bug that was fixed with 8.20.  Can anyone confirm/deny?  Thanks!

[JLS]

Hello,

I searched our CAR database but didn't find an indication of this problem and corresponding fix in 8.2.  Did you hear this from an NI representative?  Do you have a CAR ID?  Perhaps someone will chime in on that.  I also searched the following documents, but didn't find an indication of the problem - can you confirm that none of the shared variable issues/comments match your description in these documents:

LabVIEW 8.2 Readme Files:

http://digital.ni.com/public.nsf/allkb/9CCBEB839CD79D58862571C00068BB64

LabVIEW 8.2 Upgrade Notes:

http://www.ni.com/pdf/manuals/371780b.pdf

Real-Time Module 8.2 Features and Changes:

http://zone.ni.com/reference/en-XX/help/370622D-01/lvrthelp/rtnewfeatures/

LabVIEW 8.2 Release Notes

http://www.ni.com/pdf/manuals/371778b.pdf

I hope it has indeed been addressed in 8.2!

Best Regards,

JLS

[Jeff in Pleasanton]

I read the 'fixed in 8.20' comments on this message board.

I have not received my quarterly update from NI so I'm still at 8.0.1.  The update is scheduled to get here this Friday, so maybe next week the shared variable startup glitch will go away.

[JLS]

Hello,

I hope so - chime in when you've had a chance to try this and if it's not resolved, we'll explore it in more detail and file a corrective action request to R&D.

Thank you, and sorry for the inconvenience.

JLS

[Jeff in Pleasanton]

I have attached a very small cRIO/Host project that demonstrates the shared variable bug/feature that's giving me grief.  Once the project is loaded, here's how to expose the problem:

1 Start cRIO vi, User1 LED blinks to confirm code execution.

2 Start Host vi (Note breakpoints!  They will enable you to see when the shared variable breaks).

3 Click Continue in Host vi till appropriate lifter status indicator goes green (NOT after 1st read!).

4 Set Host LifterCmd control to true, click Continue till Host indicates LifterUp.

5 Click Host vi Stop and click Continue till it stops.

6 Restart Host vi, CAREFULLY click continue while monitoring cRIO lifter status LED.

7 Note that Host vi read of LifterStat has value of False, which is incorrect!!!

8 Bogus LifterStat value causes Host to send erroneous lifter command to cRIO

My take on this is that the Host vi is not actually reading LifterStat the first time it sees the shared variable read icon.  I've tried adding more shared variable read icons to the left of the while loop to "prime the system", but that doesn't help.  I can't find anyone who can tell me when the non-shared-variable-server vi makes first contact with the server, and if there is any way I can programmatically force that to happen.

[Chris_Cilino]

Jeff,

I've tried this in 8.20 and following your steps, the lifterstat returned the state of liftercmd when i restarted the host. I didn't try this in 8.0, but in 8.20 the program worked as I would have expected.

Chris C

[Jeff in Pleasanton]

Chris, I'm not sure I understand what you mean by "...the lifterstat returned the state of liftercmd when i restarted the host."  When I run these programs per my numbered instructions, the host vi "reads" a value of false from the lifterstat shared variable in step 7.  This bogus false is written to liftercmd.  Note that the cRIO code runs continuously in this example, and that it repeatedly sets the value of lifterstat to true as confirmed by the virtual front panel LED.  I don't know where the host vi gets a lifterstat value of false, but it's not from the shared variable server on cRIO.

I submitted a service request on this problem last Friday.  The workaround provided by the AE is to uncheck the "enable Real-Time FIFO" box in the shared variable properties popup.  Doing so does solve my immediate problem, but it leaves me wondering where the host vi is getting the bogus false from when the enable Real-Time FIFO box is checked.