Shared Variable refuses to deploy correctly!

My problem seems like one that has been encountered before, but with no good answers on the NI documents or forums. When trying to run a VI that deploys shared variables, I keep getting an error that the shared variable engine cannot be found. This seems to be almost random, because I was able to deploy shared variables perfectly fine. It might have been when I restarted my computer that this problem started to occur.
I've tried disabling the firewall, that had no effect. LabVIEW 2009 reports the following when I try to run my VI:
"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 writing the following Shared Variable:
\\.\fake_data\flow_sh
\\.\fake_data\flow_sh"
I'll include all pertinent files so that you can see exactly what I'm doing. The purpose of the fake_data program is just to practice using shared variables, very simple. Thanks for any insight you can offer!
Solved!
Go to Solution.
Attachments:
fake_data.zip ‏145 KB

Is it possible you meant "net start ..." for the second command?
LabVIEW Champion . Do more with less code and in less time .

Similar Messages

Dsc 8.2.1 cannot write to shared variables error 1950679035

I am getting error 1950679035 ni_tagger_write when I try to write to my shared variables. I recently upgraded from labview 8.2 to 8.2.1. I also upgraded to DSC 8.2.1. During the install, I had to upgrade my computer to SP2 (windows xp), which installed mdac 2.8 sp1 for use with dsc 8.2.1.
I have the windows firewall turned off, I checked with our IT dept and no upgrades were completed overnight (as the program worked yesterday using 8.2). I checked and MAX will get a connection with the fieldpoint unit. Everything is deployed from my machine, currently running under the dev environment.
I have looked at this thread, but I was not able to get anywhere, http://digital.ni.com/public.nsf/websearch/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument and here.
Even though I have windows firewall turned off, I added all of the execptions to the windows firewall list.
It appears that the shared variable library is deploying correctly, as the the windows says that it has (when you run a vi). I am progmatically deploying the vi.
I looked at the variable manager and I attached a screenshot below. I am not sure if that means that it did not deploy correctly or not.?? (I was only watching a couple of the variables, I have about 20 total)
thanks
Kenny
Attachments:
variable manager.jpg ‏55 KB

It appears that my problem has been solved. Apparently our network had an internal error for a quick second and my nic did not like it. So after I restarted again (fourth of the morning) it started working now.
Kenny

Deploying cRIO as Shared Variable Engine

I am finishing up a project where a crio will be continuously recording data and the computer is running a program that will download the data once daily as well as comunicate with the program running on crio device over shared variables. Since the crio will be using a cellular modem to connect to the internet, connection loss is expected. For this reason we have made the crio serve the shared variables so that if connection is lost to the PC, the crio will continue to record data normally without problems when it writes to or reads from the shared variables.
The crio will be running headless. I built a real-time application and deployed it as startup successfully on the crio device without warnings or errors. I connected to it via font panel to confirm it started up and is working properly. I will eventually use the application builder to build an installer that will install everything needed to run the program on the PC side. However, when I open the 'Belle Glade System PC' and run it, it attempts to deploy the shared variables on the crio device. It warns me that it will close any applications running on the crio device. This is not what I want. The shared variable engine is already deployed on the crio device and the program is running. All the PC program (Belle Glade System PC) needs to do is run and connect to the shared variable engine already deployed. I am obviously doing something really fundamentally wrong here and I could use some help.
[will work for kudos]

I apologize for not posting the solution to the problem.
Basically what you end up having to do is create two nearly identical shared variable libraries, one on the pc and one on the crio. The library on the PC has each of its shared variables binded to the corrosponding variable in the cRIO Shared Variable library by PSP URL (ip address and variable location). To do this, open the PC shared variable library and go to the properties of a specific variable. Check "Enable Aliasing" and under the bind to drop down menu select PSP URL. Then hit browse and find the variable on the crio. Do this for each of the variables on the pc.
This option does not seem to be 100% reliable as it has trouble detecting connection problems between host PC and crio device. This is because shared variables look for a connection to the shared variable engine. However, both the pc and the crio have their own shared variable engine running as a host so there is always a connection as far as it knows, lol. This solution worked ok for me since I could not find a more relable option.
There is a better explaination on this post: http://forums.ni.com/t5/LabVIEW/cRIO-Shared-Variables-amp-stand-alone-application/m-p/797139?query.i...
[will work for kudos]

VI cannot find shared variable in engine despite successful deployment

I am unable to use Shared Variables to communicate between VIs located on my PC and the VIs located on my cRIO-9014. This is a new development as I have been running the same VIs for over a year without this problem. The only recent development is that the IT department at my company installed new virus protection software and changed some windows firewall settings on the PC that I am using. This problem first began as soon as I got the PC back from IT. I have since unblocked LabView in Windows Firewall but that has not fixed the problem. The error I get every time I try to read a shared variable on the real time target is:
Error -1950679035 occurred at Shared Variable Read in RT Interface.vi
Possible reason(s):
LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
I have redeployed all of my shared variables and according to LabView the deployment was successful, yet I still get this error every time. Is it likely that something the IT department did with the Antivirus/Firewall software has blocked communication between the cRIO-9014 and my PC? I have used Measurement & Automation Explorer to check communication with the device and as far as I can tell everything seems fine.

After adding LabVIEW to the exceptions list of Windows Firewall, my issue seemed to be cleared up. I am now getting the same error message once again, but now I get it every time I run a VI with shared variables and it actually pops up an error message asking me to continue or stop. Again, according to LabVIEW the shared variables deployed successfully. I looked at the two KB articles that were posted and it seemed like this error has three causes:
1-Unsuccessful deployment - everything seems to have deployed
2-Firewall Issues - were taken care of to fix my original problem
3-Shared Variable Engine not running
I've looked around and I found a reference to 'repairing' the shared variable engine but not a guide for how to do that. I have opened variable manager (I am using LabVIEW 8.5) and have stopped and started the shared variable engine with no effect.
What are steps I can take to ensure the Shared Variable engine is running properly?

Debug shared variable array

I am passing data between a PXI RT Target to a PC Host using Shared Variables. Everything passes correctly between the Host and the Target, but Shared Variables that are arrays do not pass between the Target and the Host. Single elements whether boolean, numeric, or string pass from Target to Host with no problem. I use NI Distribution Manager to examine Shared Variables. How can you find the content of a Shared Variable that is an array, without writing my own VI?

This tool doesn't give me any more information than the Dist Sys Mgr. The SVs that are working show quality "good" vs "no know value" for the SVs that are not working.
My network-published SVs are single-writer 1D arrays (U32/SGL) of varying sizes (64-1005).
When I write to the SV I get error -2147024891 with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer.
When I read the SV I get warning -1950679044with the source being \\My Computer\Lib\mySV\\xxx.xxx.xxx.xxx\Lib\mySV where xxx.xxx.xxx.xxx. is the IP address of My Computer. I get this warning when I'm reading the SV either from the target or the host.
I've checked the properties pages for the SVs and I don't see how LabVIEW is interpreting the network path twice. What could be causing this?
Also, if I delete a SV from my library of SVs it still shows up in the Dist Sys Mgr until I restart LabVIEW. Why?

Shared variables not updating in exe

Hi,
I've created a project with 2 vi's, they share data via Networked Shared Variables, one vi writes while the other reads.
The data is passed between the 2 vi's whilst running in the Labview 2009 SP1 development environment, but when I create an exe, the screen values in the reader vi do not update at all.
In the build specification I've tried both including the vi's which reference the shared variables and the
option to list the shared variable libaries for deployment at run time, as methods to overcome the problem.
Please, any clues why the exe should fail to allow shared variables to pass data ?
thanks,
Gary.

Hey Gary,
I've just created a project to replicate the issue you are having and indeed when I built the application, the Shared Variables were no longer working. This is because I hadn't deployed the Shared Variables in code; which I think may be the problem that you're having at the moment. When create a Network Published Shared Variable library in LabVIEW, it auto-deploys itself for the development environment; but this is definitely not the case for when you build an executable. Instead, you must deploy the library yourself in code.
In the attached zip folder, please follow the following instructions and hopefully you'll be able to fix your VI:
Unzip the folder and extract the files.
Open up the project.
Look at the project layout. Notice the SharedVariableLibrary.lvlib and inspect the Shared_Double variable.
Look at how the Reader.vi and the Writer.vi interact with the variable.
Go into the Main.vi. See that I make an Open Application Reference VI and Invoke Node to manually deploy the library in code. You'll have to change the path to this library to match the directory structure of your own computer, so just make sure it navigates to the library in the extracted folder.
Check out the Build Specifications. I've done nothing here except ensure I only include the Main VI. Finally build the VI and run the executable.
You should see that this will give you a working Shared Variable setup. The Machine Name input for the Open Application Reference is blank because you only want to communicate with the localhost i.e. Your computer. Therefore by explicitly deploying all libraries you require, your VIs should be able to communicate effectively.
Does this solve your problem?
Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)
Attachments:
GlobalVariableProject Folder LabVIEW 9_0SP1.zip ‏26 KB

Appear to lose connection with the Shared Variable Engine

Have been through the boards, but with no success regarding the specifics of my problem.
I am running a real-time application on a PXI-8108. The host software is taking care of user interface, etc. Information exchange is handled using Unbound Network Shared Variables (located on the host, though problems occur no matter where the variables are located). Everything deploys fine. Software runs swimmingly. I have backed off the DAQ/communication processes until the RT cores are at <10% busy. However, occassionally while running, I get a popup "Waiting for Real-Time Target xxx to respond..." If this message stays up for long enough, then the target's attempts to read the Shared Variables start erroring out with an error -1950679035. As the variables have already been deployed and used prior to this instant, I find this curious. If I filter out the error, eventually the real-time software comes back up and everything progresses as though nothing happened. However, this is a potential deal-breaker for the users who can be impatient with having to wait a few seconds for the software to respond.
Any idea what is happening? I'm not pumping huge amounts of data over the network, no threads should be starving. Kinda confused.
Dan M.

The shared variables are being used much like how a queue would, directing each loop to perform an action should the host require it. If no action is required, then the loops default to check their respective bus or DAQ.
Currently, I am running 13 timed loops (whose periods I have extended signficantly during debug to no detrimental effect of my software, but to no improvement in the issue in question):
RS-232/J1708 converter loop (50ms period)
CAN loop (50ms)
DMM loop (250ms)
Oscilloscope loop (250ms)
DAQ loop (50ms, includes 1 AI task, 4 DI tasks, and 6 CTR in tasks)
Switch loop (50ms)
RS-232 loops (50ms for the main, 1 additional loop at 1Hz)
RS-485 loops (50ms for the main, 4 additional loops at 1Hz)
Both cores appear to share the load, usually the aggregate load is under 15%. When the popup appears telling me that the host is waiting for a reply from the target, the PXI controller monitor output still updates the CPU loads, which do not show anything unusual, such as a spike or a freeze in loading. The target loading does spike up to about 30% total after the communication is reestablished, but that appears to be the software attempting to "catch up" with the events that occurred during the "black out".
The error reads like this:
Shared Variable in Main Target Application.vi
This error or warning occurred while reading the following Shared Variable:
\\My Computer\Host-Target Interface\RS-485 Messages to Target [<--insert other variables here]
\\192.168.1.122\Host-Target Interface\RS-485 Messages to Target
Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
Are there any other drivers that would be starving the Shared Variable Engine? For example, if a VISA or NI-DAQmx driver goes to sleep, could it hold up the SVE? What execution system are they running under?
Thanks for your help!
Dan M.

RT cRIO: Shared Variable Engine Errors

This is an app written in LV2011 running on a cRIO-9076 (Scan mode), with the August release of software installed on it.
I have gown to great lengths to try an optomize my code, I have reached an impasse. The VERY FIRST TIME I run the code on the target (be it via a self-starting EXE or targeting from my Windows development machine I am able to read and write to several shared variables, but then when I access them again (possibly when I am starting a couple timed loops and the processor is very high) I get this:
Error -1950679023 occurred at Shared Variable in targetIdleLoop.vi->ZDAQ_cRIO_Target_Main.vi
Possible reason(s):
LabVIEW: (Hex 0x8BBB0011) The connection to the server was disconnected.
This error or warning occurred while writing the following Shared Variable:\\ZeeAero-RIO1\variables - network - RT (separate)\RTStatus\\10.10.10.10\variables - network - RT (separate)\RTStatus
If I go back to the Dev machine and restart the code, I don't get this error; it only happens after a reboot.
BUT on this second run (or subsequent VI starts), when we get to that same point, a client priogram running on Windows and reading a network variable successfully suddenly gets:
LabVIEW: -1950679035 (Hex 0x8BBB0005) Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
Which lasts a minute or so, then goes away. The code is made to loop, and when it loops back through this point there are no errors at all.
So, to recap:
1st Run after reeboot, 1st loop :Error on Target (0x8BBB0011), connection to server disconnected
Subsequent Runs, 1st loop: Error on Windows Client (0x8BBB0005) Unable to locate variable in the Shared Variable Engine. Deployment of this variable may have failed.
Subsequent Runs, 2nd+ loop: No error
Here is a link to a screenshot of the installed SW on the Target:
EDIT: I should mention that there are three loops running in parallel on this app; 1 is a Timed-loop (at the moment) set to a period of 10ms with 100 priority, #2 is also a timed loop and is set to 3ms with priority = 50 and the third is a WHILE loop with a 50ms wait. The error occurs during the WHILE init phase, which happens once per run, not repeatedly.
Solved!
Go to Solution.

This is killing me. It's obviously something to do with when the Timed loops start AND when I access the network variables.
See the screenshot below.
Note that I read and write to several network variables in Subroutines to the left of this screenshot at startup. The starting of the timed loops causes the issue with the shared variables. (also note that the periods are set to 100ms and 99ms in my testing after the initial 1st loop.
Now look at the Wait at the bottom set to 10 seconds. In this case, it will work. There is no error at breakpoint 37 if I wait around 10s. If I DON'T wait the 10 seconds, there is an error after the check on the BOOL "stop - Network" variable that NEVER GOES AWAY. If I look at the CPU monitor, there is an initial bump in the cpu when starting the loops, and then it drops to about 15%. But if I don't have that 10s wait, there is ERR 0x8BBB0011 and the CPU spikes to 75% every 5 seconds and it never goes away.
And that's only the 1st loop after reboot. The 10s makes this work, but I still have an issue with it once I start doing individual runs (loops).

Is Shared Variable Engine with LV8 an OPC server ?

Hello
Is the shared variable engine with LV8 an OPC server ?
Does any OPC client can acces to Variable Engine OPC server an read shared variable ?
Can I build an installer and deploy my application with Variable Engine OPC server on other PC without LV8.
Thank you

Hi
You can communicate between an OPC serveur and LV8 and use shared variable. To deploy an LV8 exe application, you must have the run time engine installed on the PC without installing LV8. You can create a setup with LV 8 in which you can integrate the run time engine.
Kamal
NIF

Shared Variable Engine on Windows PC w/o full install of LabVIEW

I have the NI Developer Suite (8.20) and need some conformation before I get too deep in a project.
First of all, it is my desire to become very efficient on develop compiled executables with LabVIEW 8.20 as my NI Developer Suite license allows me to deploy these programs to any number of machines without facing copyright infringement. I have been successful with this to a certain degree, but am still having problems in the testing stages of my application especially in cases where the hardware I am trying to target does not exist on my developing station. If anyone can point me to white papers that would help me get the mindset to develop in this way, I would appreciate it.
Onto the topic of this post:
I am just scratching the surface of the shared variable interface that is available in LabVIEW 8.2. My project involves two computers where both of them need to share variables back and forth from each other. I've been reading everything I can get my hands on and I am having a hard time answering my unlying question: Is it possible for both of these machines to be running compiled LabVIEW programs and still manage the shared variables between them? That is to say, can one of the machines have the Shared Variable Engine running on it as a Windows service, or compiled into my application executable.
I've read that I can access shared variables from my compiled LabVIEW application through NI-PSP. I am wondering what my limitations would be sans-LabVIEW installation other then the troubleshooting head ache you get from developing applications without direct access to the hardware.
Thank you for your time and submissions.
-Nickerbocker

I am trying to get the "Shared Variable Client - Server" project example compiled so that both the server and client vi's can be run as executables on a standalone machine.
I have created 3 build specifications:
1. "My Server" which is the compiled EXE of the server.lvib. Added that entire library to the source.
2. "My Client" which is the compiled EXE of the client.lvib. Added that entire library to the source.
3. "My Installer" which is the installation package of the vi's and NI supporting software. In the additional installers I have added:
* NI DataSocket
* NI LabVIEW Run-Time Engine 8.2
* NI Measurement & Automation Explorer 4.1
* NI Variable Engine
* NI Variable Manager
* NI-DAQmx 8.3
Some of those are added for future needs. Installed the package on my target machine and run the server executable it appears to run fine but I get various error messages from my client.exe package (which I won't go into detail here, yet). Upon stopping the server I get the message "LabVIEW: (Hex 0x8BBB0005) Unable to locate variable in he Shared Variable Engine. Deployment of this variable may have failed."
I check the services running and see that the "National Instruments PSP Server Locator" and the "National Instruments Variable Engine" are both in the list and "Started." I open up the Variable Manager that has been installed on my target machine and manually add the "waveform" and the "command" variables under a process I call "server" and start the process. After that I start my server.exe that I have compiled from the server.lvib library. The process gives no error messages until the stop button is pressed, and then I receive the message "LabVIEW: (Hex 0x8BBB0011) The connection to the server was disconnected."
The compiled programs run fine on my development machine as well as the uncompiled VIs within the LabVIEW development enviornment. Something tells me that I simply do not have the Variable engine properly configured on my target machine. Also, the process and variables should automatically be populated under "Local System" in the Variable Manager, right? I do not need to add them manually, or do I?
Thanks for your input!
-Nickerbocker

Shared variable error

HI,
I get this error,
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:
\\RT Single-Board RIO\temp1_lib\Temperature1
\\192.168.1.140\temp1_lib\Temperature1
What do I need to do?

Are you deploying the variable? Right click on the library>deploy.
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

Deploying Shared Variables to Remote Target?

I have a 2-application server/client setup where my client(s) merely read information "published" by the server via a Network-Shared Shared Variable. If I run my server on a "clean machine" (i.e. no LabVIEW development) and I "publish" the shared variable library (via the "Library : Deploy Library" Application method) to the localhost, I have no problems whatsoever reading the data in the client (the path of the .lvlib file provided to the Invoke Method VI is an absolute path to the .lvlib file, BTW). However, I'm having a bear of a time getting the server to deploy the library to a machine running a second client on the same network - to do this I still use the same absolute path to my .lvlib file for the first input to the method (it's in the same place on the target as well as on the host, not that I know what this means for a targeted host) and I specify the IP Address of the target machine on the second input. There is no firewall on either machine (I removed it because I was getting nowhere and needed to eliminate a possible source of problems) and my router doesn't filter traffic going across the local subnet. Am I not using the programmatic publishing correctly to publish to another target (from within the server), or can anyone point out any problems in my usage?
By the way, if I publish to the local host (127.0.0.1 or the host machine's IP address) I do not get an error out of the "Invoke Node" VI. However, when I try to publish to a network target (both machines have the Variable Manager running and both machines work fine if both server and client are on the same machine) I get error code 1 and the message: "Invoke Node in MyServer.vi<APPEND> Method Name: <b>Library : Deploy Library</b>" which is anything but helpful.
Any help would be greatly appreciated!
-Danny

Hi Arun,
I hope you're doing well. I'd like to clarify the architecture that you are actually using. It sounds like you are deploying a network-published shared variable library on two seperate host PCs. You are then attempting to read data from both of these hosts from a RT target using the Datasocket VIs. The RT target seems to be reading from the shared variables from one of the hosts just fine, but you can't read from the other host. Are both hosts deploying their libraries in an executable as mentioned in previous posts, or is the deployment process done through the LabVIEW development system? Also, when you connect to the hosts using Datasocket, how are you entering in the addresses for each item? Lastly, it might help to know whether you have LabVIEW and LabVIEW Real-Time versions 8.0 or 8.0.1. If you could provide some more information on your set up, we can try to give some suggestions. Thanks!
Thaison V
Applications Engineer
National Instruments

Shared Variable Deployment not accessible in Build Specification

Hi everyone,
I have a large project developed in LV 8.6.1 from which I executed numerous applications. I converted the project in LV 11 sp1f1, everything works well in code, everything is saved.
I wanted to build executable without cod change for LV 11 here is what I found:
Build the executable with Build Specifications inherited from LV 8.6 for which I checked on Use Labview 8.x file layout in Advanced. My application programmatically deploys all internal shared variables and when I wanted to access the Shared Variable Deployment in project in Build Specification then labview locked and I have to kill LV. Other time I did not access the Shared Variable Deployment and I start building executable when it looks the build progressing similar as in LV8.6 and last step before popping the attached error all the saved files in the build location were deleted.
I set up a build specification just for this LV 11. Again I wanted to access the Shared Variable Deployment and again labview is looping something from which I had to kill labview. I opened it again, I skipped the shared variable deployment line and I build the application. Because my application programmatically deploys shared variables I included in builder the lvlib where shared variables belong. The build files does not includes this time as output the file *.lvlib for which my inherited LV8.6 code programmatic deploys shared variables.
My question is should I change the code (very large code) taking out the programmatic variables deployment and to relay on the build executable to do deploy them then what should I do with Shared Variable Deployment line in Build Specification which for my large application is not accessible or is any way to still use the shared variable as in LV8.6 but for which I need *.lvlib in build location.
Another important issue: when I launched my application built as I showed in previous second case, first thing that I see is that my application is not able to save errors (I have a log file where I save different drivers or communication errors). Any idea why application even without shared variable deployed is not able to write a text file? I am administrator of my computer with all rights.
Thank you,
Virginia

No, I am not able to close Labview because of the windows error with only one button to close application. The application is correct executed. Next time when I start this project it is asking me if I want o recover even if I accept to recover it looks what I had last time it does not save.
For my application also I am building a VI without diagram built as source distribution for which I set in my builder this top vi and I excluded everything from the project because my application copies instances at the run time of this vi as many times as hardware modules I have in the system and also I have this vi included in my application (for the content of this vi). My vi contains interfaces for hardware configuration as well as drivers functions call for each hardware module I have to control in my application. Everything is good building this vi, but in less then one minute after the build is executed and build interface closes again I have the windows error which force me to close project. Next time when I open project I did not see the option to recover the project.
In the mean time I received second message and I wonder if you refer to files names or to folder names or all together. I checked and the maximum size is 122 characters in the vi paths.
Thank you,
Virginia

Custom data type causing trouble in deploying shared variable to RT target

I seem to be having some difficulty in using a network published shared variable created from a custom data type when deployed as an executable on an RT cRIO target. I'll start by describing why I believe this is where the problem lies. I created my RT VI in the LabVIEW development environment (LV 2012) and everything works fine. This VI is pretty simple because it rapidly devolved in to a debug exercise. The RT VI starts by simply blinking the User LED a couple of times and then starts a simple acquisition loop to read a few values off the hardware using the scan engine (while still blinking the User LED). After reading the hardware, the values are bundled in to a cluster and written to a network-published shared variable defined by a type def custom control. The custom control contains five dbl precision floats. If it matters, the cRIO RT system hosts the shared variable in this case.
So, I deploy this under the development environment and everything works fine. The LED blinks merrily along, telling me that the program is running properly. Running a host VI that reads the network-published shared variable yields the desired result. All is good.
Now I want the cRIO system to run this simple program autonomously at startup. I build it, set it as the startup VI, deploy it and then restart the cRIO target. The LED never starts blinking... the VI does not seem to run. I will spare you most of the debugging work and jump to the end. I basically "Diagram Disabled" various sections of code until the VI started running correctly as an executable. I kept reducing the size of the disabled code until only one thing was disabled: the write to the custom data type shared variable.
So, I guess my question is this: Are custom data types defined by type def'd custom controls allowed in executable RT programs? I've read through the cRIO Developers Guide, my NI Real Time Development course book and the Using Shared Variables white paper and I didn't see anything that forbade it. I know that there are some things not allowed in executables that are allowed in the development environment (front panel property nodes, dialog VIs, OS-specific calls, etc), but no mention of custom data type shared variables. Any ideas as to why my VI runs in the development environment but fails when compiled unless I remove the write to the network published shared variable?
Thanks in advance for your help!!
Solved!
Go to Solution.

Paolo,
So I thought that you meant to disconnect them in the build specification. Under the Additional Exclusions in the build specification, there is a check box for Disconnect Type Defs. I checked that box, recompiled, redeployed and it did not work. At this point I had to give and move forward, so I was going to convert the data typed from a cluster to an array. When I went in to change the data type in the shared variable pop-up from the project explorer, there was a big button under the variable definition that "Disconnect from Type Def". Clicked that button, recompiled, redeployed, restarted and everything worked great. Thank You!!
I suspect that I'll have to be careful if I change the definition of that data type (add an element, etc) since it is no longer connected to the data type. We'll cross that bridge when we need to.
Thanks again

Build specification freezes when trying to view "Shared Variable Deployment" screen

Labview 2009 f3
For some strange reason, any applications that include shared variable libraries will no longer build into executables.
I was able to build these applications without issue a week ago. However, when I went to make an updated build today, the build failed and I had to force Labview to close. When I view the build specification properties, I can navigate through all the option screens except the "Shared Variable Deployment" screen. As soon as I click on that option, the interface freezes up and I have to force Labview to close.
This problem does not occur for applications that do not include shared variable libraries.
I tried removing the shared variable libraries from the applications that were failing, but that did not correct the issue.

I never did find a proper fix to this issue.
One day I attempted to build the application again, but this time I got distracted doing something else. When I finally checked the build status a few minutes later I expected it to still be frozen, but to my surprise I found that the application did successfully build. To this day, that particular application still looks like it is going to lock up, but about about 8 minutes later it finally takes off and builds like nothing was wrong...like every other shared variable application I have created. So I guess my only suggestion is to let the application sit for a while and see what happens.

Shared Variable refuses to deploy correctly!

Similar Messages

Maybe you are looking for