无法通过cRIO Real-Time编程访问LabVIEW共享变量

Question

I would like to use programmatic access to manipulate shared variables on a computer and an NI cRIO 9033, but cannot get programmatic access to shared variables on the cRIO.

I have boiled the situation down to a very simple example to try to explain what I am seeing. The shared variables are hosted on the cRIO. I am using the same VI to perform the accesses on the computer and the cRIO. On the computer, access to the shared variable via a shared variable node and programmatic access both work. On the cRIO, access to the shared variable via a shared variable node is functional, but programmatic access to the shared variable does not work.

The error code received when trying to to a Read Variable or Open Variable Connection on the cRIO to the shared variable is -1950678943. The error text reads "Timed out while attempting to open a connection to the variable."

I'm quickly becoming confused as to why the cRIO should have trouble reading a shared variable programmatically that is hosted on itself. The web searches I have done haven't turned up such a simple scenario causing this error, so I'm wondering if I've stumbled into a beginner mistake.

Back Panel of the VI for accessing the shared variables:

Result of running VI on the computer (all shared variable accesses - via shared variable nodes or programmatic access work):

Result of running VI on the cRIO (all attempts at shared variable programmatic access do not work):

EDIT: I appreciate the help troubleshooting this, but in the end I couldn't get shared variables to work for my application of programmatic access from a CompactRIO. I instead chose to use Network Streams , which seem to function fairly well. Upside: Connection details between my client and server can be better encapsulated, since shared variables no longer need to be given to them to allow communication. Downside: a bit more book-keeping to ensure that both reader and writer to the Network Stream are connected correctly (I found this dissection at National Instrument's forum useful when formulating that logic).

Answer 1

It is difficult for me to reproduce your problem without your architecture. Could you try making a test VI with the structure shown here and let me know what happens? (Plug in your variable library path where I have an empty library constant).

A couple of things to note:

1. You want to open a connection to the variable, read from or write to the variable (or access properties), and close the connection in series. Ideally if you will be doing lots of reading and writing, you only open the variable once and close it once at the start and end of your program. It is important that you explicitly force LabVIEW to open the connection before reading/writing though.
2. By wiring the stop condition on your For loop, you can get some idea of which (if only one) variable is giving you a problem. The For loop will quit on the variable the throws the error, and your Variable Names output will only show values up to that variable.
3. You could use the Read Variable VI instead of accessing the variables name with the Variable Property Node , but I figured the name would help you locate which variable is causing the problem.

Hopefully just explicitly opening a connection before reading from your variable will solve the problem, but let me know what ends up happening on your end.

Edit:

After a bit of discussion, I modified the VI to include a short delay at the beginning before we try to access the shared variable engine. The shared variable engine needs a bit of time to start up, so it could be failing to start up before timing out. You could adjust the delay a bit and see if that solves the problem.

Here are some additional troubleshooting tips from NI. A big one to double-check is that your shared variables are, in fact, deployed. If you can access them from the PC though, then I would imagine that they are deployed.

Another thing to note: if you are using your variables in a loop on your RT machine, make sure that there is some delay between iterations of the loop. The shared variable engine can get starved out by RT loops if they do not leave time for the processor to handle lower-priority tasks.

Lastly, just wanted to throw up a link to the documentation on network shared variables. There is a lot of useful information in there, although I am not sure that it necessarily helps with this issue.