Shared Variable Deployment and Hosting

Hi all,
I am writing a labview RT application where a host PC will communicate with a RIO 9074 to write/update some 400 I/O simultaneously..
I have decided to write an entry level VI on the host PC so that I can pass all data to the RIO and then receive the processed data back. Here is my question... Where should I create the network shared variables in my project?? Under the host PC or under the RIO target?? What would be the difference between hosting the network shared variables in my host PC or hosting them in my cRIO??
Cheers,
Harry

There are some questions you need to ask yourself before you make those decisions. The following tutorial has that covered under the title 'Recommendations for Shared Variable Hosting Location'. Have a look and let us know if you have any further questions:
Using the LabVIEW Shared Variable
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

Similar Messages

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

Shared variable version on host and RT target

Hi,
Is it possible to use different shared variable engine on host computer and RT target? We use shared variable to communicate between RT target and host computer. Once the products shipped to customers we will keep the software on RT target unchanged but we would like to keep updating the program on the host computer with newest LabVIEW version. Is it possible to just update the host computer without updating the RT target?Thanks for help!
Tao

Hi Tom,
Are you getting an error code or some thing else?
Attached are two zip files. The 8_5.zip is a LabVIEW project that was written in 8.5 and deployed to a cFP. The 9_0.zip is a LabVIEW project written in LabVIEW 2009 (9.0), that reads the shared variable off of the cFP running the 8.5 code.
This works for me, so if you could give a little more detail, hopefully I can help you out.
Justin Parker
National Instruments
Product Support Engineer
Attachments:
8_5.zip ‏36 KB
9_0.zip ‏30 KB

Difference between Shared Variable Refnum and Control

Dabbing my toes in Shared Variables for another project. Glad to see A LOT more support from NI in terms of Shared Variables (especially now that built executables can be set to automatically deploy shared variable libraries...thats a big help).
In the Shared Variable block diagram palette (under Data Communication) there are a number of VIs that can be used to progmatically access and consume shared variables. Awesome. One thing that I have noticed is there is a difference between a "Shared Variable Control" (from the I/O front panel palette) and the "Shared Variable Refnum In" that you obtain from right-clicking one of the VIs from the Shared Variable palette and selected "Create Control".
My first thought was that these two were one and the same, but they are not. Visually they look different:
Also, the reference input to the VIs in the Shared Variable palette only take the "shared variable refnum" control as input. The control from the "I/O" palette does not work.
This wouldn't be much of a problem, but I prefer the look of the Silver Shared Variable Control much more to the control I get from the "Create->Control". Also, the variable browser in the Shared Variable Control is A LOT nicer than the control refnum gives me.
Here is the Shared Variable refnum variable browser:
Here is the much nicer looking browser that pops up from the Shared Variable Control:
So I guess my questions are:
Why are there two reference data types that seemingly perform the same function but are incompatible with one another in LabVIEW?
How can I use the Shared Variable Control with the Shared Variable palette VIs?
Thanks for your input.

Hello Nickerbocker,
You actually want to use the Shared Variable Control in the context of Alarms, I/O Servers and other categories inside the DSC Module. Like you already saw, to use the basic functionality of a Shared Variable, such as programmatically reading / writing to it, you need to use a refnum.
Regards,
Daniel REDS
RF Systems Engineer
Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.

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.

-1950679023 Shared Variable Engine and the NI 9148

I'm running an RT application on a cRIO-9074 that calls I/O from a connected cRIO expansion chassis (NI 9148). At some point some digital input variables throw he following error
-1950679023, The connection to the server was disconnected.
What's strange is that its only some of the inputs that have this problems. Other variables on the same module work just fine. What's going on here and how can I get my system to recover from this error once throw?
I'm running RT 2011.0.1 and Network Variable Engine 1.8.1
Craig

Hi Craig,
Do you see these same problems if you place the two offending modules in the 9074's chassis instead of an expansion chassis? If you do make this switch do you then see errors on other modules?
Have you tried programmatically reading the variables instead of using shared variable nodes? You can find an example of this if you're not familiar with it here, https://decibel.ni.com/content/docs/DOC-12548.
When you see these errors does your application stop running, or do you just see the errors being carried through the variables as it continues to run? Also, just to double check, you're seeing these errors intermittently not every time you run correct? Also is there anything noticeable happening when this error occurs other than the error itself?
Finally, could you post a little bit of your code, or some screenshots of where you're accessing these variables and how often you're doing so?
Thanks,
Miles G.
National Instruments
Applications Engineer

Shared Variable Properties and DSC

Is there a way to assign engineering units to a shared variable as a
configuration parameter? This should be on the "Scaling" page of
the shared variable properties. It seems this is a logical and
convenient place to track units. Assigning units programmatically
using the Scaling:Units property is awkward (to say the least).
On similar lines, why aren't shared variable properties automatically
saved to the DSC historical database? Every trace should have a
set of information that exposes ALL the shared variable properties that
created it. Take something like engineering units for
example: then you would know what kind of historical trace you
are looking at! This seems so basic I can't imagine why it was
missed.
Unless I missed something -- please enlighten me.
Regards,
David Moerman
TruView Technology Integration Ltd.

Hello David,
You are correct in that the units property is not exposed on the
Scaling page of hte Shared Variable properties dialog, and it sounds
like you are already well aware of the existing method to access this
property through the property node interface. As you have also
discovered, the Citadel database that we use with DSC does not have a
built-in provision for storing metadata about the shared variable from
which a trace originates. You can emulate this with, for example, an
array of strings which is also logged to the database, with each string
containing the metadata for a particular trace.
Since it seems like having these features would benefit you, I
encourage you to let our DSC development group know your needs by
filling out product feedback, accessible on our site at
http://www.ni.com/contact . This will send a feature request
directly to the appropriate R & D group, who reads and evaluates
every suggestion made. This is your most direct way to let us know
what features would best meet your needs.
Cheers,
Matt Pollock
National Instruments

Deploy Shared Variable Engine in localhost

I need to talk to multiple RTs using single computer. It seems
obvious to deploy shared variable engine (libraries) in localhost instead of
RT. However, the problem is the shared variables (read) used in localhost VIs
are not being updated from RTs. But when I am using another local VI to update
the shared variable, it is working just fine. The variable path of the RT looks
like "\\My Computer\Local NPSVlvlib\Test
Data". I think this is the problem why the values are not being updated
because RT cannot resolve the network path ("\\My
Computer\Local NPSVlvlib\Test Data"). Also, I tried to change the shared
variable path in RT but I could not do it. Help Needed!!!!
Solved!
Go to Solution.

Thanks for your reply. I found in this link http://zone.ni.com/devzone/cda/tut/p/id/9900#toc2 that host computer can host the shared variable library and RT does not need the shared variable engine. See below
If your application includes a single host computer and a single or multiple RT targets it is recommended to host the library on the host computer. This will save memory and processor time on the RT targets. Also, by hosting the library on the host computer instead of the RT target, you can reduce the software install footprint on the RT target. The RT target will not need the Network Variable Engine, but will still require Variable Client Support. The Network Variable Engine allows hosting, the Client allows communicating with libraries on other machines. You can see a RIO target with these installed in Figure 4.
That exactly what I am trying to do. Any comments?

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]

Scale cRIO NP Shared Variable AFTER Deploying an Executable

I have a project coming up that has about 140 shared variables deployed on an RT target and sharing data at 1S/s over the network. There is nothing else going on concerning the RT target, just dumping values. I would like to scale these SV's in the .lvproj to avoid having to write a bunch of scaling code in software.
My only concern is what happens when I have an executable application running (without LV 2012 installed on the computer). How would I re-scale these values without having access to the .lvproj? Distributed System Manager doesn't provide for this. Any help would be appreciated. Thanks.
Nathan - Certified LabVIEW Developer

Hy Nathan,
Your Shared Variables are within a library in you LabVIEW project. In your Application Properties make sure to include that library. This is shown in Figure 9 in the below white paper.
http://www.ni.com/white-paper/9900/en/
MJ
Application Engineer
National Instruments

Compact FieldPoint and Shared Variables

Hi Real-Time community,
let me first to describe my problem: I have a project running perfectly on Windows XP machine. The Real-Time Target (compact FieldPoint) is acquiring a data from different sensors and sends them via Shared Variables to the host machine (WinXP). Now this host application has to migrate to Windows 7 machine, which second Ethernet port is also connected to the compact FieldPoint's network. I have created an installer, it run on Win 7 computer but I I see no data there. Shared Variables are standart network-published. What else I need to configure to get Shared Variables visible over there? Thank you in advance for any helpful hint.
Armen

Hi,
we do have the full edition of Signal Express, this is not the problem. We are already logging the information comming from our cFP-1808 : TC-120 and AI-111 module. The problem is that the AI-111 module is a 4 to 20mA module, and we have thermocouple connect to it. We want to read temperature in Signal Express instead of mA.
There's a option in MAX where you can add scaling to a cFP module. This scaling work in MAX, in the OPC server of the cFP, but not in Signal Express. In Signal Express, you still read the mA value.
I know we can add a formula in Signal Express, but we don't want to do that, when there is an other option in MAX.
Thanks

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?

Binding a shared variable to a NI-PSP data object does not work

Hi,
I want to share data between a RT-target and one or more hosts (LV 8.6.1). The network shared variables are deployed to the RT-Target. According to NI accessing shared variables from another project or host has to be done by defining a shared variable on the host and aliasing it to the NI-PSP data object on the target.
I did that and the host shared variable generated an error (0x8BBB0011) during runtime.
Next I aliased to a shared variable deployed on the host from another project. This did work.
Another thing I tried was to bind the variable from the RT-target to a display element:
This is working !!! And as you can see the path of the NI-PSP data object is exactly the same ! So what is the difference between binding a data object to a shared variable and to a display element?
Is there a bug in the SVE or am I missing something here?
The host project:
The publisher VI
Hope, someone has an answer.
Regards
Matthias Quade
Solved!
Go to Solution.
Attachments:
AliasTestWrite-RT.vi ‏8 KB
AliasTestConsumer.vi ‏8 KB

Dear Mr. Quade,
thank you for posting at the National Instruments Forum. There is a known issue with the path of the bound variable with LabVIEW 8.6.1
Please download the patch for LabVIEW 8.6.1, it should solve your problem:
http://joule.ni.com/nidu/cds/view/p/id/1255/lang/de
Best regards from Munich
MarianO

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.

Shared variable no longer updates

All,
I have an RT Systems 2011 and have been using shared variables between the RT and Host. Working for months. Then I renamed a shared variable and it no longer updates. When I try to look at the variable in the NI Distributed System Manager, it reports that it does not exist.
I changed the name back to what it was, it is seen by the System Manager but the current value is not displayed.
I did a remote debug into the RT code and the variable is being updated.
Any ideas\comments\etc would be appreciated?
Thanks

What hardware are you using as your real-time target? When you mentioned that you are using "RT Systems 2011", are you using LabVIEW 2011 and the Real-Time Module?
After you updated the shared variable, did you re-deploy it? I highly recommend reading through the “Deployment and Hosting” section of the DeveloperZone Tutorial linked below:
http://www.ni.com/white-paper/4679/en/#toc3
Regards,
Cameron F
Applications Engineer
National Instruments

Shared Variable Deployment and Hosting

Similar Messages

Maybe you are looking for