Discussion:
shared variable failed deployment
(too old to reply)
mfitzsimons
2008-01-14 23:40:08 UTC
Permalink
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,
 
DAQ Dude
2008-02-28 00:10:06 UTC
Permalink
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.
     
EWTech
2008-08-04 22:40:06 UTC
Permalink
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
Hillary_C_E
2008-08-05 19:10:18 UTC
Permalink
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 <a href="http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6?OpenDocument" target="_blank">How Do I Deploy Network Shared Variables from a Compiled Executable?</a>
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.
EWTech
2008-08-05 22:40:05 UTC
Permalink
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?
EWTech
2008-08-06 18:40:10 UTC
Permalink
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&nbsp;resides&nbsp;in ./data and that library contains the shared variables.
&nbsp;
BobMessage Edited by EWTech on 08-06-2008 02:35 PM
Hillary_C_E
2008-08-06 21:10:08 UTC
Permalink
Bob,
&nbsp;
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&nbsp;set the&nbsp;Destination of the&nbsp;library(s) to be Support Directory in the Source File Settings category?
&nbsp;
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.
&nbsp;
Can you post the specific text that accompanies the error?
&nbsp;
EWTech
2008-08-08 18:10:07 UTC
Permalink
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&nbsp;set the&nbsp;Destination of the&nbsp;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.
&nbsp;
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.
&nbsp;
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.
Hillary_C_E
2008-08-11 16:40:09 UTC
Permalink
This post might be inappropriate. Click to display it.
EWTech
2008-08-11 17:40:05 UTC
Permalink
Hillary,
The path to the SingleBool.lvlib seems to be an issue. I recieve the following error:
shared variable write in tiny.vi -&gt; Timed Structure(es): L43127408&lt;append&gt; This warning occured while writing <a href="file://\\My" target="_blank">\\My</a> COmputer\SingleBool\flash (<a href="file://\\localhost\SingleBool\Flash" target="_blank">\\localhost\SingleBool\Flash</a>).
Both paths are wrong and I'm having trouble editing either the installer or the executable build entries in the project as if it never changes after editing the tiny.vi code.
&nbsp;
Bob
EWTech
2008-08-11 19:10:08 UTC
Permalink
This post might be inappropriate. Click to display it.
Hillary_C_E
2008-08-12 17:10:07 UTC
Permalink
Hi Bob,
So, you're using LabVIEW 7.1.1?
Where is the library you're referencing, on your original computer or your end computer?
How are you referencing your host computer in the executable? Are you referencing it by IP or localhost?
Let me know if you can't get this worked out with your sales engineer.
EWTech
2008-08-14 21:40:09 UTC
Permalink
Hillary,I am not using LV 7.1.1 on this project. It is running a program on the network using data sockets. &nbsp;In either case I was able to deploy the variables. Alan Loprete, our local rep. here (Columbia office) showed me that the Invoke Node function was not required to deploy the variable. It worked fine without it and trying to open the included library separately caused the executable to gak. Once I removed the offending fuctions and reworked the panel as needed it worked fine. It deploys the variables as required. Since the display panel is just that and does no calculations at all it's just made up of indicators bound to the shared variables on the server machine - no code at all other than a reasonable update loop. Works like a champ. All *processing* is done on the server end with a C# DLL saving the values to SQL Server. &nbsp;Many thanks for your help.&nbsp;Bob
Loading...