Shared Variable issues with real-time executable

[neophyte_ab]

Hi,

I am facing the same issue that Adrian faced, except that his solutions have not been able to solve my problems. In specific:

1. When I save my project, "Build" my real time application, and then finally "deploy" this application as a startup application, it deploys ok, no problem. Now, because my application is a startup VI, I have to reboot the target (I want it to run standalone). When I right click on the target in the project library amd point to "Utilities --> Reboot", the target gets disconnected from the "project" and does not automatically get connected back again once the target has rebooted. When I try to right click on the target again and try to "Connect", LabView tries to deploy the project AGAIN, and this stops the VI that is running on the target. Is it possible for Labview to connect to the target without trying to deploy anything?

2. If I run my host VI (compiled as an exe), without trying to "Connect" as above, then my host VI cannot read any of the variables in the Shared Variable Library (that should have been deployed by the target by then). It doesn't matter how many times I stop the host VI and restart, the result is the same.

However, when I run the Vi directly (not as a startup application but directly from LabView, it runs fine without problems; but this is obviously not what I need for a standalone application).

Would be great if someone can resolve this issue.

Thanks

Atul

[Christian_L]

Atul,

Can you describe your HW and SW configuration in a bit more detail please.

It sounds like you have a Window host target/development machine and a RT target (cRIO? PXI?). In the final application you plan on having an RT exe and a Windows RT that will communicate with one another using shared variables? Will they use any other communication mechanisms in addition to SVs?

Where are you hosting the SVs that you use for communication? i.e. where are you running the SV Engine? Can you attach your project or include a screenshot of it with the relevant folders (shared variables) expanded.

When you deploy shared variables to an RT target or to a Windows target they exist on that target until they are explicitly undeployed/removed. Even when you reboot a machine (RT or Windows) the shared variables will exist on the target without redeploying them. The shared variables configuration is stored in a binary file, so for example when the RT target reboots, the SV engine is started and looks in the binary file to determine which shared variables to create and host. If your are hosting the shared variables on the RT target, make sure you deploy all shared variables at the same time as deploying the RT EXE.

After deploying the RT EXE and rebooting the RT target, why are you trying to reconnect to the RT target? You are right that when you try this, effectively the development environment on your Windows machine is taking the RT target from run-mode back into interactive development mode and trying to redeploy different parts of the project thereby stopping the RT EXE that is currently running.

[neophyte_ab]

Hi Christian,

Thanks for your post. Below are answers to your questions:

HW: PXIe 1082 chassis with 8102 embedded controller running rtos.

SW: LabView 2010 RT

Yes, the RT application will be standalone and I am planning to host the network SVs on the target so that it can be standalone. I am not planning on using any other communication mechanisms.

How can I know where the SV engine is running?

When I deploy my application, the status window has messages that indicate that the SVs are also getting deployed. However, the application is not able to "talk" to these variables once it is running.

I guess I should not try to reconnect, so please do not worry about the reconnecting part. My project is attached.

[neophyte_ab]

Sorry forgot to mention this: Please unzip the folder directly to the C drive.

[Christian_L]

---

neophyte_ab wrote: 

How can I know where the SV engine is running?

---

The SV engine and shared variables run on the target on which you have the SVs defined in your project. In your case the SV library is defined in your RT target. Therefore the SVE and SVs will be on the PXIe system. Once you have deployed them there they should exist every time you reboot the system.

One easy way to verify that they are being hosted and to check their current value is the Distributes System Manager (DSM) in LabVIEW. Tools >> Distributed System Manager

The DSM allows you to connect to any system on your network and see what variables are hosted there.

---

neophyte_ab wrote: 

When I deploy my application, the status window has messages that indicate that the SVs are also getting deployed. However, the application is not able to "talk" to these variables once it is running.

---

This sounds like it is related to how you connect the SV nodes in the HMI VI to the SVs on the PXIe target. Take a look at the Help information for the Shared Variables and how it uses the Aliases file to find the target based on it IP address.

[neophyte_ab]

Hello Christian,

Thanks again.

I was looking at the System Manager and could see that the shared variables have been deployed. However, the target VI is supposed to initialize those variables (see FPS Maintenance Init in my project), which is not happening. Its almost as if the target VI goes dead once it deploys the SVs (or as soon as it starts).

I have pretty much similar code running another project, and that seems to work fine most of the time. Could it be related to the fact that the variables I am trying to communicate over the network are too large for the SVM to handle? What would be the maximum size you would recommend?

Thanks

Atul

[Christian_L]

---

I was looking at the System Manager and could see that the shared variables have been deployed. However, the target VI is supposed to initialize those variables (see FPS Maintenance Init in my project), which is not happening. Its almost as if the target VI goes dead once it deploys the SVs (or as soon as it starts).

I have pretty much similar code running another project, and that seems to work fine most of the time. Could it be related to the fact that the variables I am trying to communicate over the network are too large for the SVM to handle? What would be the maximum size you would recommend?

Thanks

Atul

---

I tried to reproduce this issue, but in my case FPS Maintenance Init.vi does what it is supposed to do (initialize the SVs).

You can eliminate TQG3 Deploy Shared Variable Library.vi from this process as it doesn't do anything. LV RT can not deploy SVs to itself at run-time. In your application the SVs are already deployed to the RT target and the configuration is stored in a binary file used by the SV engine. I don't think that this VI is causing any problems though.

It sounds like something else is causing you RT EXE not to run properly when compiled and deployed.

There is no theoretical limit to the size of SVs that can be used other than performance. Your largest cluster is only 248 bytes which is not much.

I would work on debugging the RT EXE and determine if it is running or why it is not. Start by breaking it down into small components and compiling them to a startup EXE.

[neophyte_ab]

Chris,

I have a suspicion that the communication between host and target at my place isn't exactly setup perfectly.

The network connectivity icon at the bottom right-hand side of my taskbar shows "limited or no connectivity", but I have been ignoring this warning because LabView was able to "see" the target and the system manager was showing all the variables, and I assumed that this is evidence that the network connections have been set up correctly. Which brings me to how I set up the host computer.

The TCP/IP settings on the network connection (on my host) are setup to normally access the internet and the company mail server. I just unplugged the network cable and replaced it with a crossover network cable. This caused the network icon to have a warning on it, but as I said above, I have ignored it until now. So to summarize, Windows does not seem to recognize the target. Could this be a problem?

Please let me know your thoughts as to how I can setup a better connection.

Thanks much for your help

Atul

[Starla_T.]

Hi Atul,

If you are having network issues, this could definitely explain why you are having connection issues.   If Windows does not recognize the target, this could definately cause issues.   I agree with Chris.  Break down your code and work on getting simple portions of it work first.   Try create a very simple VI that just wires a constant to your shared variables and see if this works.  If this doesn't work, you know the issue is related to your network.