Shared Variables not visible on cRIO 9068

[pallen]

I've run into a strange problem with a cRIO 9068 and shared variables.

For reference, the project I am working with is the LabVIEW FPGA Control on CompactRIO example. 

Previously, using the same host PC, I was able to adapt and run this project on a different cRIO target successfully.

The 9068 was discovered in MAX and identical software was installed to the target.  A new project was modified to target the 9086.  The FPGA VI complied to the target and operated interactively. 

The RT Main VI deployed the shared variables successfully.

When I ran the Main UI, initially I had an error in Open Variable Connection in the Initiate Connection VI.  I was looking at settings in MAX while attempting to connect.  Then suddenly it was connected, but throwing an error related to the shared variable used to pass memory tracking information.  The 9068 is a Linux based device, so I changed the property node as per the documentation and on the next connect everything worked. 

When I closed the project and closed MAX, I was prompted to save changes in MAX.  I didn't recall making any, but thought it best to save anyway. 

On reopening the project, the shared variables were no longer discoverable either by the Main UI or by the Distributed System Manager. 

I can still connect to the other cRIO and see shared variables from that device.  But so far nothing has been able to restore them to the 6098.  I have reinstalled the cRIO software and tried creating a new project.  The variables always seem to deploy to the target fine.  But they cannot be contacted.

The Shared Variable Monitor gives an interesting error when attempting to see the shared variables.  

Cannot enumerate items in this hierarchy:

Could not set current folder to

\\NI-cRIO-9068-01c329a2\Shared Variables.

error code - 0x8abc5003

Unknown error 0x8ABC5003

So far nothing I've tried has worked.  But it did work...if only very briefly. 

Windows is still working, as I can see the variables on another cRIO just fine. 

I've also tried completely disabling the firewall...just in case.  But exceptions were already in place and working. 

I'm fishing for ideas at this point.  Any would be appreciated.  🙂

[pallen]

I won't call this the solution just yet.  But resetting the MAX database may have helped. 

I'm still experiencing odd connection errors after recompiles and after the development PC has been in sleep mode.  I have switched to connecting in link-local mode and so far restarting LabVIEW has been solving those issues.  But I am finding that I need to restart quite frequently.  Something I did not see with the 9076. 

Perhaps there's a compatibility issue with LV2014 SP1 and this hardware.

[Davidvilla87]

How would you describe these odd connection errors? What happens when you compile the VI?

[nanocyte · Accepted solution]

Sounds like the variable service is buggy on the windows PC. It could be a bad install on that end or some random configuration issue. Maybe check your services and see if everything is on the up and up there.

You'll want to make a simple VI that will isolate the problem. Make sure you are catching any error codes that are being thrown on both the host and the target side. If you make an RTEXE, maybe someone with the same target can test it for you. We can probably make you an windows exe to test.

Also, check your RT error logs

[pallen]

I haven't had the chance yet to test on a different host PC.  But based on what I've seen so far, it is looking like something is/was a little buggy with the host PC. 

This PC has had multiple versions of LabVIEW installed and updated over time.  It's entirely possible something is conflicting.