Shared Variable issues with real-time executable

[viScience]

I would really like NI to clarify this issue.  I have heard it said over and over again that the Deploy Library vi simply will not work when run from a RT target.  I have tried it myself and cannot get it to work.  It is true that the help for this method states that it CAN be used for RT.  NI please resolve this contradiction, this is an important function and I simply do not understand why it should not be possible to deploy a library from a RT app.  I think it would be good for NI to also explain what is happening under the hood when you deploy a library to RT target.  I believe that the library is stored as a type of xml file on the rt target and is able to reinstate itself between power cycles and reboots. 

[The Specialist]

Hi Sachsm,

I believe the final answer is that an RT Target (aka cRIO, RTPXI, or cFP) can NOT deploy shared variables.  A windows OS machine can deploy shared variables to RT Target at run-time, but under no circumstances can a RT Target deploy SVs to itself or another machine. 

Can I get a blue to confirm/deny this with the corresponding documentation?

[Christian_L]

The Library.Deploy Library method on the Invoke Node for the Application object will not work on LabVIEW Real-Time to deploy a Shared Variables Library to an RT target. This is stated incorrectly in the Help File for this method in LabVIEW 8.6 and has been corrected.

This method can be used on a Windows target to deploy a SV library to an RT target on the network.

[abanica]

I am a bit suprised by this statement because what this would tell me is that no system would be able to run headless (with no Windows based client connected) if it is using shared variables. This goes against my experience outlined earlier in this thread which seemed to indicate that it does work. I have tried another simple experiment: added a string variable to my shared library on the PXI RT target, initialized it to something and then used RT Debug String to display it on a target monitor. Created an executable using the shared variable engine deployment method described above, disconneted the target from the Windows machine and cycled power. The variable engine seems to be deployed since the variable is correctly initialized and read back for display. Am I missing something?? Is there another mechanism that would cause these variables to work? I have also used the trace tool quite extensively and you can clearly see the SVE task running and taking quite  few resources soon after bootup. If indeed the statement that the shared variable engine can not be deployed when running RT by itself is correct, then that would be a fatal and significant flaw that absolutely has to be corrected.

[Christian_L]

The short answer is that shared variables deployed to the SVE on a RT target persist between reboots. So once you deploy a Shared Variable or a SV library, it will exist in the SVE on the RT target, even if you reboot the system. To remove the SV or library from the SVE on the RT target you must explicitly undeploy it from the project, remove the process in the Distributed System Manager, etc.

Information about which variables/libraries are currently deployed to the SVE on an RT target is stored in binary files in the \ni-rt\system directory on the RT target. This means that deployed variables will be replicated to new RT targets when replicating RT application images using the RT Target System Replication tools.

Abanica,

In your previous example the fact that you deployed the string variable to the PXI target, means that it automatically existed on your target even when you disconnected the system from the Windows host and rebooted it. The fact that you included the shared variable engine deployment method (Library.Deploy Library) did not affect the SVE on the RT target.

In addition, it is good to remember the difference between the Shared Variable Engine (SVE) and deployed shared variables. The SVE is installed on the RT target using MAX (Measurement and Automation Explorer) when you install a particular set of SW on your RT target. The SVE starts running on the RT target when the system is booted, based on the settings in the ni-rt.ini file.

Shared Variables (SV) are hosted in the SVE. If there are SVs configured to be hosted in the SVE when the system is booted (based on the binary files stored on the RT target) then these SVs are instantiated after the SVE is started. Additional SVs can be deployed to the SVE on the RT target while the SVE is running from the project in the LabVIEW development environment on the Windows host or from a VI running in Windows. SVs can not be deployed to the SVE from VIs running on the RT target.

Lastly the Shared Variable configuration for an RT target is not part of an RT executable. To deploy an RT application on multiple systems you can not simply copy the RT executable to a new RT target, as this will not copy information about the deployed shared variables. The recommended method for duplicating or deploying RT applications is to create a master RT application target ("gold master") where you deploy the shared variables and your RT application. Then use the RT Target System Replication tools to create an RT application image (an image of the harddrive of your RT target) and copy/deploy the application image to other RT targets.

[reddog]

In the context of variables, it may be easier to think of deploying to be equivalent to running an installer.  To deploy variables, you must invoke a deploy command from a Windows host computer.  You can either do this by using right click commands on the library from within the project or by using the invoke node.  In the case of the invoke node, you can deploy by using the deploy method on the Application class or the Project class.  The deploy method on the Application class requires that you reference a library file on disk and supply the IP address of the target.  The deploy method on the Project class requires that you provide an array of references to other items in the project that you want to deploy.  Regardless of which method you choose, you must be on a Windows host PC to execute it.

Without getting too much into the implementation details, the deploy process itself will pull configuration information from either the library file on disk or the project item within the project.  It will then transform this information into a form that is suitable for the RT target and download it to the target.  The RT target then stores this configuration information in a manner that persists across reboots of the RT controller.  Next time you reboot the controller, any variables that have been deployed to it in the past will still be available to any startup applications or VIs running on the controller.  The only time they go away is if you reformat the controller or undeploy them from the Windows host.  If you want to change the configuration of variables that have already been deployed, add new variables, or remove previously deployed variables, you must do so from a Windows host.  It can't be done directly from a program or VI running on the RT controller.

[viScience]

Thats right - we need to use the System Replication tools.  Unfortunately they are not working at the moment.

[viScience]

What I am wondering is why the SV data structures are stored in binary (which files exactly?) instead of xml.

[Christian_L]

---

sachsm wrote:
Thats right - we need to use the System Replication tools.  Unfortunately they are not working at the moment.

---

Mike,

I have posted an update to the RT System Replication tools in the following DevZone Community entry. This update adds some extra Wait times in the processes which retrieves files from an RT target and places files on an RT target, in order to give the FTP server more time to free up used sockets for additional operations. This resolves the issue you have described earlier.

http://decibel.ni.com/content/docs/DOC-5102

[abanica]

Very interesting discussion and very useful. Going back to the issue I had that started this whole train of thought, the failure to initialize shared variables at bootup, I think that now there might be a different explanation for what was going on. The problem seems to have been that when I was trying to write to these shared variables (very close to the start of code and <0.5 sec into execution), the SVE was not fully loaded yet (even thought the user code started executing). I could see this in the trace output (within the limitations that it has). Experimentally I derived that it takes about 5-8 seconds for this to fully load. So the addition of the Invoke Node method was a distraction, in the end it was the 10 sec wait delay I added that did the trick.

To summarize then: when booting into an RT executable, ensure that shared variables are not initialized/accessed right away. Based on the group's knowledge of the inner workings of this, does this seem as a reasonable answer?