I'm hoping someone else has some insight into an issue I'm seeing when using either I/O network published variables or shared variables in general.
There seems to be an bug when accessing shared variables programatically. In the image below I am trying to remotely access a shared variable hosted on a crio. In both cases I'm accessing the same shared variable on a crio that has been disconnected from the network.
In the top case, the variable will constantly timeout at 100 ms when using a shared variable node. However, in the bottom frame, the timeout is always 5000 ms even though I have set it to 100. There seems to be an internal 5000ms timeout within the programmatic function for accessing shared even when using the "Read Variable with Timeout" and "Open Variable and Verify" functions. The "Open shared Variable in Background" Vi does not solve the issue either. The timeout parameters appear to have no effect if the network is disconnected when first connection. This is a huge problem if I open a GUI and the network connection has been cut. All my daemons using these variable slow to a crawl because I can not specify a timeout.
Not only this but the vi's are not reentrant and are blocking. So if I'm opening variable in multiple places, such as when using different network actors, they will all block in series and create a HUGE network bottleneck.
I'm hoping someone has seen this same issue and has a way to get around it. At this point I'm considering rewriting everything to use TCP/IP instead of shared or I/O variables. Or setting up another layer that maps my calls unto these individual shared variable nodes.
This is still a pain as the shared variable nodes are a LOT less flexible than using programmatic access. In addition I'm also using an Ethernet expansion module and I have to use shared variables to read the data off the modules as there is no real time running on top. Thanks
Solved! Go to Solution.
We can try to explicity open the reference to the Shared Variable as shown here:
When I do this both methods work fine and produce similar results.
Explicity opening the variable using "Open Variable Connection" has no effect on my results. When the CRIO is disconnected from the network, and then i run this VI on the development computer with "auto deploy variables" disabled. I still get a 5000 ms timeout on the bottom sequence but a 100ms on the top. I have attached my project.
The error code you show indicates the timeout is occurring during the Open Variable Connection VI. This is expected if you try to run this application with the cRIO disconnected. To better represent the use case of a disconnected cRIO the Open Variable Connection should be in an initialization step before the main application loop. One important thing to note is that the Read Variable with Timeout will call the Open Variable Connection implicitly if it is not called explicitly. The Open Variable Connection VI will be called if you are going to use Read Variable Timeout one way or the other. Try running this VI snippet and unplugging the cRIO (formatting during upload may kill the snippet functionality and you may have to re-create it manually). The Open Variable Connection VI is called before the main loop and if a disconnect occurs, the Read Variable will timeout as you would expect at 100 ms.
Thank you for taking the time to respond but I don't think we are communicating the same issue.
Here is a little more info about my use case. I currently have a large program where I'm using network shared I/o variable to directly read from the individual crio modules channels. I have a large number of hardware actors that are launched at the start of the program that handle, display, control and feedback from the crio. The issue with this forced timeout is that when launching actors, it the blocking reads are creating a huge bottleneck. Since each call to "Open Variable Connection" is blocking and is taking 5000ms, my program is completely unresponsive until they all timeout if the crio is disconnected when starting the program.
I'm currently in the process of changing my communication method, but this timeout seems like a bug or at the very least an issue that should be changed. You should be able to define this timeout.
I understand the general flow of opening the shared variable and then reading. What I was trying to illustrate with the examples above was the blocking nature and forced internal timeout of these functions. The problem is that the "open shared variable" vi has an internal 5000ms timeout that can't be changed, and is blocking. I understand its called if you read programatically before opening and the point I'm making is that in this case you still have that 5000ms timeout.
If you were to dynamically call the vi you have listed below five times, and the crio was not connected when it started, it would take 25 seconds before the final dynamically called loop started.
The reason I stated this as a bug was that if you used a "shared Variable node" this 5000ms timeout is not locked in. Why does opening a variable connection programatically have a 5000ms lock while the shared variable node does not? Why does this initial "opening" take so long when doing it programatically and why is it blocking?
In Labview 2013, both of those functions have also have a 5000ms internal timeout. I've tried everything in the pallet. The timeout in Open and Verify Connection seems to have no effect if the crio is disconnected when its first called. On my system is exhibits the exact same 5000ms timeout.
Here is a comparison of all the options to open a variable connection.
One thing to notice is that they all seem to be block on each other so no matter how you open the variable it blocks any other methods of opening. Even though i'm opening connections to different variables
I apologize for misunderstanding the intended use case. There are ways to detect the presence of a cRIO that we could possibly use just prior to Opening the variable connections. We can check the system status property or even ping the device with System Exec.VI. There is also an entire library of functions designed to detect and manipulate cRIO devices programmatically called the System Configuration Information Reference Library. I haven’t personally used this library but it appears as though it could be useful.
These options do have some overhead associated with them. In the example below, checking the status of the cRIO takes a few seconds on my machine. Once checked, we can create the appropriate references and any network problems that occur afterward will trigger the appropriate timeouts. This may or not be a viable alternative for your application. Please let me know your thoughts on how cRIO detection could fit into your application and use case.
Thanks for the tip. I had used the CRI library in the past but had forgotten about it. This ended up being the solution to my issue. I still think that programatic options for shared variables should be a little more flexible but i worked around it.
Within the CRI library there is a CRI Get Remote cRIO Controller Info within this VI is another VI cri_RT Ping Controller. This is the key function i ended up using. I just set a super short timeout on the function and check for an error before opening a shared variable connection.