Connect to a Real-Time Target Running a Startup Application Using Shared Variables

Updated Nov 6, 2023

Reported In

Software

  • LabVIEW Real-Time Module
  • LabVIEW Real-Time Application Builder Module

Issue Details

  • I made a real-time executable (RTEXE) and set it as the startup executable.  However, I can't connect to it using my host PC.  I am using Network Shared Variables hosted on the real-time target.
  • When I try and connect to my real-time target, I get a Conflict Resolution window and my application stops running (Alternative: My application only runs when I hit deploy. Once deployed, if I disconnect and reconnect, it doesn't run)

Solution

There are several options you can try to solve this, noted below:
  • Option 1: Right-click on the  controller and select Disable Autodeploy Variable
  • Option 2: Open and run the PC host VI outside of the project
 
  • Option 3: Create a build specification for the PC Host VI and run the built executable
 
  • Option 4:  Use two separate libraries; one on the host and one on the real-time target. The variables in the host library, which may or may not be Network-Published depending on your needs, should be bound to the remote library.

If none of these options work, it is worth verifying that your RT target is actually running the startup VI.  Repeatedly blinking the User LEDs is sufficient proof.  If it is not, consider Reformatting Your RT Target .

Additional Information

The reason that this is happening is that the Host VI is trying to redeploy the Shared Variable Library to the target before it connects to it. In order for this deployment to be successful, it has to abort execution of the RTexe. Once it has connected, since the RTexe was aborted, it won't run. This is why redeploying the application works.

Since the library only needs to be deployed once, we can connect to the RTexe without redeploying the library by using any of the methods noted above. The reason this works is as follows:
  • In Option 1, by disabling auto-deploy, the Host VI will just connect to the Shared Variable Library that already exists on the target. If changes to the library need to be made, then it will have to be manually deployed once again.
 
  • In Option 2 & 3, since we are running the Host VI outside of the project containing the Shared Variable Library, it won't try to redeploy the library.
 
  • For Option 4, having two separate libraries removes the dependency of the host VI on the existence of the remote library. If the remote library is non-existent, the Host VI will return an error but will not ask to deploy variables to the remote machine