LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variables crio RT not working after compile

Solved!
Go to solution

I found "NI Distributed System Manager" and it shows "PCVars" apparently deployed on both the local host and the networked items..

 

Not sure if this is what you were referring to.

 

 

0 Kudos
Message 11 of 22
(3,303 Views)

Tried deploying the shared variables in the VI and it appeared to work (I see the PCVar library running in the distributetd system thing).

 

But they are still not being updated.

 

I need to take a break, lol, it's Sunday 🙂

 

 

0 Kudos
Message 12 of 22
(3,292 Views)

When deploying programmatically the shared variables (PCVar.lvlib) deploy because I can see them with the distributed system monitor but I also get the following error:

 

Error 1 occurred at Invoke Node in PRC_Deploy.vi->NI_DSC.lvlib:Deploy Library.vi->Frontscreen-Main.vi

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

Method Name: Library:Deploy Library

 

 

 

0 Kudos
Message 13 of 22
(3,288 Views)

Using the Distributed System now I see the variable being updated.

 

However, in the vi I see this error:

 

Error -1950679035 occurred at Shared Variable in Frontscreen-Main.vi

Possible reason(s):

LabVIEW:  (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine.  Deployment of this variable may have failed.

This error or warning occurred while reading the following Shared Variable:
\\My Computer\PCVars\SPM
\\192.168.1.101\PCVars\SPM

0 Kudos
Message 14 of 22
(3,284 Views)

ONe last observation lol.

 

When I have the distributed system open and I can see the variables, everything works fine until I exit the main VI, then it appears that the engine shuts down..??

 

After the host VI quits, all of the variables say "nonexistant"

 

 

0 Kudos
Message 15 of 22
(3,275 Views)
Solution
Accepted by topic author jeff_scharpf

I know this sounds ridiculous, but just in case ..:smileywink:
In MAX there is an option - Halt system if TCP / IP fails - pl make sure it is unchecked.

Consider the ideal situation:

The host program* on the RT Controller (set as startup) runs independently.
The exe program on the PC runs independently
During run time the only way they share info is through shared variables.

The RT Controller publishes the shared variables according to their current status. If the application program on the PC writes to the shared variables on the RT, and if the application is not running, then the RT host program (Set as startup) will continue to run, but the shared variable status indicates "non-existant" in NI Distributed systems manager.

In your case, I doubt that the RT controller start up program closes when the PC application program accesses it. When you close the application on the PC the other vi's on the RT Controller also stop working. This can happen when the PC application program acts as a remote panel and communicates directly with the RT, instead of through shared variables.

To confirm this, build and deploy a small program (say a random number generator) on the RT controller. Also build a small executable on the PC, in which the PC application program only reads shared variables from the RT controller. Close the application program, labview and see whether the shared variable is getting published using NI Distributed system manager. Every time you run the application program on the PC, the shared variables should be read in the program. Expand the program to include write operations (on shared variables) also. This way you may be able to debug the issue.

 

* (BTW, when I refer "host", I am referring to the RT Controller acting as host to the FPGA. program. In this particular case, the PC may be directly acting as host to the FPGA program and hence when the PC application program stops or closes all other applications on the controller are affected)

 

Good luck!:smileyhappy:

Message 16 of 22
(3,261 Views)

Hello Jeff,

 

There were a couple of things I wanted to add to this discussion.  First of all, variables cannot be programmatically deployed from a Real-Time target.  This may be the cause of some of your problems.  Also, you are only going to want to host the variables on either the PC or the RT target, not on both.  From the sounds of things, your best option would be to host the variables on RT by deploying them from the project.  These variables should then remain hosted on the target until explicitly undeployed.  You will not have to redeploy them each time the controller boots.  Then, you can use these same variables in your host PC code without hosting a new instance of them.  I hope this helps.

Message 17 of 22
(3,237 Views)

I'm wondering if you're on to something Bruce and maybe I need to modify my thinking about this.

 

According to this link

http://digital.ni.com/public.nsf/allkb/AED9E710A06A6C56862574EF0053DFA1?OpenDocument    I'm supposed to keep a copy of the shared variables on BOTH the host and RT, but bind the host variables to the RT variables.

 

 I did get it to work by manually deploying the shared variables on the host but when I did this, it warned me that it was changing something on the RT (I had previously setup the RT VI to auto run).

 

So, after manually doing this on the host (not the RT), THEN recompiling and setting the RT to run automatically, and rebooting the crio things worked.

 

I was providing you with bad information also. Inside the HOST VI code, there was a section that deployed the library of shared variables. It also undeployed at exit. The problem I had was when I exited the program it would no longer work the second time.I removed the exit button so the operator clicks the "close window" box thus not undeploying. This solved all my problems for now 🙂 It doesn't get to the root.

 

In any event, I appreciate everyones feedback. I am taking a break from this for a day or two so I can get my head straight lol.

 

Jeff

Message 18 of 22
(3,221 Views)

jeff_scharpf wrote:

  I did get it to work by manually deploying the shared variables on the host but when I did this, it warned me that it was changing something on the RT (I had previously setup the RT VI to auto run).

 

So, after manually doing this on the host (not the RT), THEN recompiling and setting the RT to run automatically, and rebooting the crio things worked.



 

Glad to hear that. Smiley Happy

 


jeff_scharpf wrote:

 

According to this link

http://digital.ni.com/public.nsf/allkb/AED9E710A06A6C56862574EF0053DFA1?OpenDocument    I'm supposed to keep a copy of the shared variables on BOTH the host and RT, but bind the host variables to the RT variables.

 


As per this document, my executables should not be working Smiley Wink , but here it is working perfectly even if I don't include a library in Host PC.

 

Either the document is really 'misleading' us or I didn't understand the exact scenario it is referring to.

 

Message Edited by kikiduu on 01-20-2009 02:19 AM
------

"A VI inside a Class is worth hundreds in the bush"
യവന്‍ പുലിയാണു കേട്ടാ!!!
0 Kudos
Message 19 of 22
(3,208 Views)
I agree with you Kiki.  I am also able to get my application to work with only one set of variables.  I am going to look into this some more and possibly make changes to this document.
Message 20 of 22
(3,187 Views)