LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variable failed deployment

Hello,

I am having an issue with a shared variable (the same issue as in this post but I am not using field point).  My application has 6 shared variables (All 6 are Array of Double Network-Published with no binding).  Occasionally I get an error for one of the variables, always the same one, the error is 1950679035 and states "Unable to locate variable in the Shared Variable Engine.  Deployment of this variable may have failed."  I find it odd that it is always the same variable that is failing and that there is no pattern (atleast not yet) for why it fails.  Do you think a solution would be to select the "Use Buffering" option under shared variable properties?  It is all that I can come up with.  Any thoughts will be appreciated!

Cheers!
0 Kudos
Message 1 of 17
(5,686 Views)
Have you tried using the Shared Variable Manager?  It is located in the National Instruments folder Start => Program Files => National Instrument => Variable Manager.  See if the variable you are trying to use is listed.  Try to delete them and they should be recreated on program deployment.  Also, always write the variable once before you read it if possible.  I have had issues on the first read.
 
Hope this is helpful,
 
Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
Message 2 of 17
(5,675 Views)
Hi jmcbee,
 
It does seem as though your variable isn't being deployed or there isn't data to read from when it attempts to read. You might want to take a look at this KB: Shared Variable Error Explanations. The links in the table show several different ways to try to fix this problem.
 
Let us know if this works for you.  
Regards,

Hillary E
National Instruments
Message 3 of 17
(5,660 Views)
Hey jmcbee,
 
Is there any way any of your shared variables (especially strings, if you have any) are growing beyond the space you have reserved for them?
 
I had a similar problem -- spurious shared variable errors (number -1950679035).  It appeared occassionally when attempting to read a particular shared variable: a simple boolean. What was odd is that there appeared to be no pattern to the errors. My system would run flawlessly for 10-15 minutes with no problems, then it would start. A single shared variable error every 2 or 3 minutes when attempting to read this particular boolean. The value for this particular variable is polled 2-3 times per second, so it was working the vast majority of the time, and fairly only occasionally. My network utilization was somewhere around 2-3%, so network collisions or something related to the network seemed highly unlikely.
 
The clue came for me while driving home after puzzling on it for a couple of hours. I remembered that I had changed the NUMBER of buffered items for another shared variable (-- a cluster flattened to a string) , but I had neglected to increase the number of character allocated for that particular shared variable. And even though the shared variable that contained the flattened string appeared to be working properly, I wondered if LabVIEW was moving pointers or somehow compensating for the fact that my buffer was no longer large enough to accomodate the larger number of buffered items I had specifed in the Shared Variable set-up dialog.
 
When I increased the number of characters in the buffer for the flattened string shared variable, lo and behold... the read errors disappeared from the boolean shared variable!
 
I'm not going to suggest I really understand what is happening under the hood, but based on these observations, it appears that if you don't allocate enough space for shared variables that can change size (specifically strings or buffered shared variables), then error -1950679035 might show up when attempting to read another, totally unrelated shared variable. I suppose the problem could also be related to shared variable arrays -- presuming that LabVIEW must resize the data space as the array size changes. If a resize operation is underway when a read request comes in, and a pointer is temporarily unavailable, it makes sense that an error like this could occur. But again, all of this is based on speculation and observation. What I can say is that care should be taken to make sure you have allocated enough space for buffered shared variables. If you encounter intermittent -1950679035, have a look for potential buffer over-runs and under-allocated buffer spaces.
 
Hope this is useful.
 
Regards,
 
-- D.
     
Message 4 of 17
(5,545 Views)
I'm absolutely unable to use shared variables outside of the build machine. It does not seem to work. Questions:
1. If shared variables are part of a library is there some way to force them to be "Static" as in part of the executable binary? Deploying using a builder does not seem to work as the version in the project file conficts with that in memory no matter ehat I do... even when the builder doesn't tell me that it conficts whith the version of the vi that's in memory...
 
2. The documentation I have found does not specidy anything. Can the target host be other than the machine the build is on? Can I use the hostname in the network domain? How about the IP address. None of the above seem to work.
 
3. I used the Invoke Node on the target build. My understanding is that the Target host name is given at the host entry as a string. The path should be the path on the built result whare the binary executable will find the file after the installer has run on the target machine. This should be ./data in the "Program Files/Resutlant Program" tree.
 
4. I keep having to remove and recreate the build and installer portions of my project over and over. Any change once the thing is in there causes these entries to break giving me something like "Error 56003 Occured in Invoke Node in...". It seems unable to copy the bibrary to the installer somewhere.
 
It's hard to believe that the specifics in the documentation do not seem to cover any of this in any detail. I'm back in the lab away from the internet most of the time. VS2005 local documentation is better than this.
 
Bob Taylor
0 Kudos
Message 5 of 17
(5,281 Views)

Hi Bob,

For clarification on building Shared Variables with executables you'll want to check in LabVIEW help for an article titled "Caveats and recommendations for Build Specifications and Builds." There is a paragraph at the bottom about Shared Variables.

Another good resources are How Do I Deploy Network Shared Variables from a Compiled Executable?

CAn you provide further clarification on your third statement? Do you have a particular question?

As for your fourth statement, can you provide the exact error number and message you are receiving? That will help with troubleshooting.

Regards,

Hillary E
National Instruments
0 Kudos
Message 6 of 17
(5,260 Views)
Yep! I know all about it. Invoke Node still fails. The SingleBool.lvlib is always put in the .\data installation directory and I've attempted to use "C:\Program Files\Tiny Reader\data\SingleBool" as the path. "Tiny Reader" is the project. The IP address is set to the development box. I ham not attepting to "compile it in" or anything. It refuses to open the shared variable deployment library. Why is this so hard?
0 Kudos
Message 7 of 17
(5,253 Views)

I see error 7. The failure is in Invoke Node. The shared variables are deployed on the development host. Invoke Node points there. I'm a bit confused as Im not sure which host Invoke node should point to; localhost or where the shared variables reside. SingleBool.lvlib resides in ./data and that library contains the shared variables.

 

Bob



Message Edited by EWTech on 08-06-2008 02:35 PM
0 Kudos
Message 8 of 17
(5,239 Views)
Bob,
 
So when your build your executable you add all libraries that contain network shared variables to the Always Include (previously Support Files) list? Do you also set the Destination of the library(s) to be Support Directory in the Source File Settings category?
 
Are you seeing Error 7 when you run your executable or when you build your executable? If you are deploying your shared variables on your development machine then your invoke node should be pointing to that location unless you want to deploy them on your current machine.
 
Can you post the specific text that accompanies the error?
 
Regards,

Hillary E
National Instruments
0 Kudos
Message 9 of 17
(5,230 Views)
So when your build your executable you add all libraries that contain network shared variables to the Always Include (previously Support Files) list? Do you also set the Destination of the library(s) to be Support Directory in the Source File Settings category?

Yes I did. I am assuming that the destination is the ./data directory on the target machine in the Program Files installation location.
 
Are you seeing Error 7 when you run your executable or when you build your executable? If you are deploying your shared variables on your development machine then your invoke node should be pointing to that location unless you want to deploy them on your current machine.

This is when the client executable runs on the target machine. The Invoke Node is pointed to the IP address of the development box where the server is writing values to the shared variables. I had thought that the client would read the shared variables from the development box.
 
Can you post the specific text that accompanies the error?

I have the rest of this week off. I'm at home and I'll try it when I get back to work and answer that question then.
0 Kudos
Message 10 of 17
(5,209 Views)