Slow update of shared variables on RT (cRIO) after building exe

Hi,
I've been struggling with this for the past few days. I am having a problem with slow updating of shared variables on my RT project....but only after building the application into exe's.
The application consists of an RT target (cRIO 9073) sampling inputs at a rate of 1sec. I have a host PC running the front panel that updates with the new acquired values from the cRIO. These values are communicated via shared variables.
Once the cRIO samples the inputs, it writes the values to the shared variables, and then flags the data as 'ready to be read' using a boolean shared variable flag. The hostPC polls this boolean shared variable and updates the indicators on the front panel accordingly.
Now, this worked fine during development, but as soon as I built the RT exe and host exe's, it stopped working properly and the shared variables ended up being updated very slowly, roughly 2-3sec update time.
To give you some more background:
I am running the Labview 2010 v10.0.
I am deploying the shared variable library on the RT device (as the system must work even without the hostPC). I have checked that its deploying using Distributed System Manager, as well as deploying it into the support directory on the cRIO and not the exe itself.
I have also disabled all firewalls and my antivirus, plus made sure that the IP's and subnets are correct and its DNS Server address is set to 0.0.0.0.
There are 25 shared variables all in all, but over half of those are config values only used once or twice at startup. Some are arrays, plus I dont have any buffering and none of them are configured as RT FIFO's either.
The available memory on the cRIO is about 15MB minimum.
What strikes me is that it works fine before building exe's and its not like the cRIO code is processor intensive, its idleing 95% of the time.

Thats exactly what I'm saying, it takes 2-3seconds to update the values.
I have tried taking out the polling on the PC side, and registered an event on the changing of that shared variable and that doesn't do anything to change the slow update time. Even if I stop the PC, and just monitor the shared variables in DSM it updates slowly.
I also tried utilising the "flush shared variables" vi to try to force the update....that does nothing.
I wire all the error nodes religously. Still no luck.
Its very strange, I'm not too sure whats happening here. These things should be able to update in 10ms.

Similar Messages

Slow update of Shared Variables on FP-2015

My application consists of a VI running on an FP-2015 which collects and transmits data from/to various I/O modules (DI-301, aI-111,Do-401 etc.) and passes this data to a Host PC using Shared Variables. It runs embedded on the FP-2015 so that it can react to certain conditions I/O conditions and implement the appropriate safety measures independently of the host pc. When I try to change some of the values of the shared variables from the host PC, it seems to take a long time for them to update on the Fieldpoint controller. For instance, if I try to change the value of a Digital Output on the DO-401 from the Host machine, it can take anywhere from 1-3 seconds before the I/O point actually toggles. I am using an Array of Booleans as the shared variable type. I am pretty sure the code is running at the correct speed at that this delay is caused by the shared variables because if I remove the shared variable and toggle the digital outs from high to low and low to high, they switch at the appropriate rates. Has anyone had any problems with using shared variable on a FP-2015? (The shared variables are hosted on the PC, not the 2015)
Also, I have seen some postings which say the FP-20xx do not have enough memory to run the shared variable server. Should I be OK if the server is running the Host pc? The link below says the shared variable engine will not work properly on the FP-2015 because it does not have enough memory but the second link below says 32mb are required (although 64 are recommended), which the FP-2015 has. Any confirmations whether the shared variables will work properly on the FP-2015. In all, I presently have 6 shared variable, each on being an array with a length of 20 elements.
http://digital.ni.com/public.nsf/allkb/6e37ac5435e44f9f862570d2005fef25
http://zone.ni.com/devzone/cda/tut/p/id/4679
Thanks
Damien

Thanks Tommy, I appreciate the advice. However, I think I will be abandoning the network-published shared variables for now. Before I left the office yesterday, I found the "communication wizard" for the Real-Time module. It allowed me to select my top-level VI and it automatically set up a communication routine to transmit all the controls and indicators from the RT target to the VI running on my host PC. It allowed me to select from multiple communication protocols (I selected TCP) and everything is working well now. I would have liked to use shared variables because they seem to be so simple to use but I do not want to waste time trying to hunt down a problem I may never fix. For now, out with the shared variables, in with TCP.
PS. I didn't change any of my code, (I was using timed loops in case you were wondering), and by changing over to TCP communication all my delay problems were solved. This reinforces my suspicion that the delays were caused by the shared variables.
Damien

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

I want to Host my Shared Variables on a cRIO, but use DSC for Logging/Alarming/SCADA

Hi everyone,
What I'm trying to do is this:
-Host shared variables on my RT targets (cRIO-9022) for reliability
-Use the DSC module to log to database, track Alarms, develop distributed HMI
The problem I'm running into is that the DSC engine (it seems) needs the shared variables it is monitoring to be hosted on that computer. The DSC engine can not run on a real-time target.
My end goal is to create a plant-wide network of cRIO's that are all linked back to a central server/PC that runs DSC to collect and stores data in a database. The plant HMI would also connect to the central server and get their information from there (not directly connected to the cRIO process). Is this possible/does any one have ideas on how to do this efficiently?
Thanks for the help.
--CLD--
LV 6.1, 8.6.1, 2011 SP1, 2012 SP1
Solved!
Go to Solution.

Sachsm,
Thanks for the input. I tried to create a test project for this type of architecture (bound NSV's) but am running into some errors.
I have attached a screenshot of the project and front panel showing the binding status of each variable **see attached picture**
Hosted on PC:
-Clone (Variable1) ---- This is bound to Variable1 on cRIo using the "Create Bound Variables" option in the Library
-Variable3
Hosted on cRIO
-Variable1
As you can see, when I drag variable 1 directly onto the PC front panel, the variable connects (indicator is green). Likewise, when I host Variable3 on the PC and drag it to the front panel, it connects. However, when I drag the Clone (variable bound to Variable1 on cRIO) onto the front panel, it cannot connect. Any thoughts?
--CLD--
LV 6.1, 8.6.1, 2011 SP1, 2012 SP1
Attachments:
Binding Error.jpg ‏127 KB

Updating of shared variable

Hello There
I am using Shared variables (SV) on an RT host. The use of these variables seems to be functioning correctly. However, after certain events, which are not that frequent, I write the values in this variables to a spreadsheet.
What has happened on a number of occasions is that previous values that were stored in the SV are being written to the spreadsheet. I have been careful to employ VI to write to spreadsheet after the values are stored in the SV. I may or may not have had the file download link between the RT host and the desk top at the time of these errors.
I have independent hardware and software checking the operation of my RT controller, which was all correct, so the problem is simply related to file storage.
Can anyone help.
Thanks MAC_D

Thanks for your reply Wayne.
The shared variable is reading and writing correctly and there is no errors.
I am using these shared variables to control digital outputs, and i have verified using external hardware and software that my application preformed correctly.
The issue is that the correct values of the shared variables were not written to file correctly. Previous values were replicated.
Kindest regards

Can not read shared variable on cRIO, error -1950678968 nitaglv

Hardware setup:
Laptop
Laptop connected via USB to a frammer garber.
Laptop IP: 192.168.0.2
NI vision calculating a diameter and setting a network varaible
cRIO
cRIO connected to the laptop
cRIO IP: 192.168.0.1
Project has the shared variable in the cRIO library
NI vision writes to the variable on the cRIO. I can see the variable properly updating in system manager on the cRIO. I can also run a VI in my computer that shows the variable properly updating. But...... When I read the variable with a VI running on the cRIO, I get the folowing error and the variable never updates:
Error -1950678968 occurred at Shared Variable in Main.vi
Possible reason(s):
LabVIEW: Failed to load nitaglv, which is required for Network-Published Shared Variables.
This error or warning occurred while reading the following Shared Variable:
\\NI-cRIO-OASIS\cRIOVariableLib\BubbleDiameterFromVision
\\192.168.0.1\cRIOVariableLib\BubbleDiameterFromVision
(I do not get any errors at deloyment)
So everything (NI Vision, a VI deployed on the laptop, NI Distributed System Manager) can see the variable on the cRIO being updated by the NI Vision.... Except for a VI running on the cRIO.
I have verified that I have Network Variable Engine and Variable Client Support for RT installed on the cRIO. I have tried reinstalling all s/w on the cRIO. Tried rebooting all. And talked in a nice, positive, reassuring voice to the chassis.

Hi!
I just had the same issue with my cRIO 9073 using NI RIO 3.6.0.
The problem is not caused by a corrupted project, but the improper installation of the OS on the target. There is nothing you can do using the SW installation wizard in MAX, as it does not matter if you intall a full RIO SW, minimal or custom.
You have to install the full install or a custom one with Shared Variable support. Then you have to FTP to the cRIO, and manually edit the "ni-rt.ini" file located in the root of the controller.
Make sure you have a line in the "[MODULE VERSIONS]" section which shows the version of the nitaglv.out file. (The problem is caused because this dll is not loaded when you try to access a SV) Mine looks like nitaglv.out=6.3
Then you have to insert "nitaglv.out;" without quotes to the [LVRT] section's StartupDLLs key's value. I did it after the taggerrt.out name. So my key entry now looks like this:
[LVRT]
StartupDLLs=nisysapirpc.out;NiViSrvr.out;NiRioRpc.out;taggerrt.out;nitaglv.out;sysstatepublisher.out;
memoryChecking=False
LABVIEWRTDir=/c/ni-rt/system
PATH=/c/ni-rt/system/;/c/ni-rt/;
CDIntervalTicks=55
WebServer.Enabled=FALSE
RTTarget.VIPath=/c/ni-rt/startup
RTTarget.IPAccess=+*
RTEnetRcvMode=2
RTCPULoadMonitoringEnabled=True
RTTarget.ApplicationPath=/c/ni-rt/startup/startup.rtexe
server.tcp.access="+*"
RTTarget.LaunchAppAtBoot=True
RTTarget.EnableFileSharing=True
server.tcp.serviceName="Main Application Instance/VI Server"
After you are done with the editing, you have to save the file, and overwrite the original one. You have to reboot the controller for the modification to take effect.
After this you will be able to host your variables on the cRIO and also read/write them from the application running on that same target.
I hope this will help for you too.
Regards,
Peter

Can't set intial value for cRIO boolean shared variable

LabVIEW 8.0 gives me a configuration error when I try to force an inital value for a Boolean shared variable in my cRIO library. Is that a bug, or am I overlooking some (probably obvious!) limitation of the cRIO hardware?
Jeff
Climbing the Labview learning curve!
Sanarus Medical
Pleasanton, CA

There are 3 screenshots attached to this post. Suppose I create a Boolean shared variable under My Computer in the project directory, then set the inital value as shown in BooleanInitialValue.gif.
If I drag a copy of that Boolean shared variable to my RT target block diagram, the run arrow breaks and I get the error shown in ErrorList.gif.
If I create a Boolean shared variable under my Real Time target (Compact RIO) in the project directory, then set the initial value and hit OK, I get the error shown in FixConfiguration.gif.
Message Edited by Jeff in Pleasanton on 07-19-2006 03:42 PM
Message Edited by Jeff in Pleasanton on 07-19-2006 03:44 PM
Jeff
Climbing the Labview learning curve!
Sanarus Medical
Pleasanton, CA
Attachments:
FixConfiguration.gif ‏6 KB
BooleanInitialValue.gif ‏13 KB
ErrorList.gif ‏13 KB

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]

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

How Can i retain the Shared Variable Values after PC rebooting

Hi all,
I am facing a paculiar problem with Shared Variables. I have an application in which shared variables are used for data communication.
One of the application requirement is to retain the variable values eventhough PC is rebooted or started after crashing.
As per the my understanding, the variable values will retain eventhough the PC is rebooted. But here i can observe a paculiar problem like some library variables are retaing the values while some others not. I enabled logging for all the variables.
I tried many ways. like logging enabled, logging disabled, changing variable names, changing process names etc... But i am not getting a consistent behaviour.
I hope some you can help me in solving this issue.. "How Can i retain the Shared Variable Values after PC rebooting"
Thanks and Regards,
Mir

Hi Blackperl,
Thanks for the post and I hope your well.
What do you mean by not getting consistent behaviour.. this will all depend on excatly when the crash happens i.e. before the write or after.
Surely a better method would be to log the data to a file during the reboot...
I beleived the value read back
will be the default value for the shared variable's data type.
The LabVIEW DSC 8.0 module adds more functionality to the shared variable, including initial values and alarms.
If you enable an initial value on a shared variable, when the variable
engine comes back on-line it will default to this value. Setting a bad
status alarm for the shared variable is also a good way of handling
this type of event. Additionally, if you are using a LabVIEW Real-Time
target such as Compact RIO or Compact FieldPoint, it is appropriate to
consider hosting the shared variable engine on the real-time target.
These devices have watch-dog capabilities and are typically the
hardware controlling the critical pieces of an application. Most
Windows or PC-based targets do not have these fail-safes.
I guess, if you could explain to me again that would be great. From my point of view, if I have a cRIO and a Windows PC. If the windows PC crashes, the cRIO will still update its shared variables. Then once the PC has started up its own shared variable engine, and the bindings are loaded, it will once again continue to update its copies of the variables.
Please let me know what you think,
Kind Regards,
James.
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

Shared Variable Alias vs Programmatic Assignment, which is better?

Hello,
I am programming an application for a cRIO platform using the scan engine in LV2009SP1. I'd like to use the cRIO as a standalone controller, and only connect a computer to it occasionally to download data. I decided to do this using shared variables. So far I've been successful at doing this in two ways, both involved creating nearly identical sets of shared variables on the cRIO and on the PC, which I think (correct me if I'm wrong) I understand is the way it should be done. The differences are the following:
The first method was to create a parallel loop on the RT VI which would assign the values passed through the shared variables to the individual I/O channels.
The second method was to Enable Aliasing on each shared variable and bind it to the appropriate I/O channel.
After deploying the RT code to the cRIO for each case and running the UI on the PC, I noticed that both worked, however, the second method showed a short lag between command and feedback (~200ms or so). The test I ran was to wire an analog output to an analog input, command the AO, and read back the value on the AI. I can deal with the delay on the UI since it's only for reference - what I'm really interested in is the data that's logged on the cRIO controller. My question is: Is one of the two methods better or more appropriate than the other? Is there something even better?
Thanks,
-NS

No Substitute wrote:
I decided to do this using shared variables. So far I've been successful at doing this in two ways, both involved creating nearly identical sets of shared variables on the cRIO and on the PC, which I think (correct me if I'm wrong) I understand is the way it should be done.
Hi NS,
No correction necessary. These are both valid ways of sharing data between your Real-Time controller and your PC. Here's a forum that discusses some similar options to accomplish the same task (
Shared variable architecture for distributed crio system)
Regarding the latency issue with method 2, take a look at KnowledgeBase: Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?
I hope this helps!
- Greg J
Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?

Shared Variables, Scan Engine & Multiple Targets

I am seeking some general advice about the structure of my LabVIEW project.
The project consists of a laptop with LabVIEW, and a joystick connected, and a CompactRIO connected via ethernet. I had been running the cRIO in FPGA Interface mode, however a change in some things caused the project to have to be shifted to scan mode.
As of now, the code on the laptop updates shared variables on the cRIO, and reads from shared variables on the cRIO for monitoring. I want the shared variables hosted on the cRIO because it will also need to operate without the laptop connected. Before switching the cRIO to scan mode, I found that I had to first run the laptop code, and then run the cRIO code, or the shared variables would not communicate properly. Now that I have switched to scan mode, I have to run the cRIO code first, and even then the shared vars do not communicate properly for more than a few seconds, and are much laggier.
My ideal project solution is a system that can run with or
without the laptop connected, and obviously not having all these shared
variable issues. I would like to autostart the code on the cRIO, and
have the user run the laptop code if necessary, but in the past this did
not seem to work with the shared variables.
I am really confused about why this is happening. Hopefully I have explained my problem well enough. I don't really want to post the entire project on here, but I can email it to people if they are willing to take a look at it. Thank you for taking the time to read this.
I am running LabVIEW 2010 SP1 with the Real-time, FPGA, DSC, and Robotics modules. I have the Feb '11 driver set and NI-RIO 3.6.0 installed and all completed updated on my RT cRIO.
Solved!
Go to Solution.

I do this type of stuff all the time...
Move all your NSV libraries to the cRIO. From the project you must deploy to the cRIO and from then on they are persistant until you reformat.
From your windows HMI app, you can place static NSV tags on the block diagram or use the dynamic SV API to R/W. Also you can bind HMI controls and
indicators directly to cRIO NSV's (This is what I do) Also I create a 'mirror' library in the PC HMI that is bound to the cRIO library. This library has DSC Citadel
data logging enable and will automatically save historical traces of all my important data - very nice. PC hosted libraries can be set to autodeploy in the app build.
also the project has a autodeploy option for the Development Environment which I normally turn off. If you have PC to cRIO binding setup then you need to be cautious
about any sort of autodeployment since it will potentially force the cRIO app to stop when you deploy. To get around this, you can use PSP binding (IP address rather than project
process name) and use the DSC deploy library vi's in your HMI app. Once you are using the scan engine you can use the DSM (Distributed System Manager) app to view, proble and
chart all of you IOV and NSV's on your network.

Shared Variables for Real-TIme Robot Control

I'm really stuck in my efforts to use LV real-time in my hardware control application. I have a 6-axis industrial robot arm that I must control programmatically from my PC. To do this I've developed a dynamic link library of functions for various robot control commands that I can call using Code Interface Nodes in LV (using 8.5). This has worked great, that is, until I tried to port parts of the application to a real-time controller. As it turns out, because the robot control dll is linked with and relies so heavily upon several Windows libraries, it is not compatible with use on a RT target, as verified by the the "DLL Checker" application I downloaded from the NI site. When the robot is not actually executing movements, I am constantly reading/writing analog and digital I/O from various sensors, etc.....
This seemed to suggest that I should simply segregate my robot commands from the I/O activities, using my host PC for the former, and my deterministic RT loop on the target machine for the latter. I set up a Robot Controller Server (RCS) vi running on my host PC that is continuously looking for (in a timed loop) a flag (a boolean) to initiate a robot movement command. Because several parameters are used to specify the robot movement, I created a custom control cluster (which includes the boolean variable) that I then used to make a Network Shared Variable that can be updated by either the RT target or the host PC running the RCS. I chose NOT to use buffering, and FIFO is not available with shared variables based on custom controls.
Here's sequence of events I'd like to accomplish:
1) on my host PC I deploy the RCS, which continuously pools a boolean variable in the control cluster that would indicate the robot should move. The shared variable cluster is initialized in the RBS and the timed loop begins.
2) I deploy the RT vi, which should set the boolean flag in the control cluster, then update the shared variable cluster.
3) an instance of the control cluster node in the RCS should update, thereby initiating a sequence of events in a case structure. (this happens on some occassions, but very few)
4) robot movement commands are executed, after which the boolean in the control cluster is set back to its original value.
5) the RT vi (which is polling in a loop) should see this latest change in the boolean as a loop stop condition and continue with the RT vi execution.
With the robot controller running in a timed loop, it occassionally "sees" and responds to a change of value in members of the shared variable cluster, but most times it does not. Furthermore, when the robot controller vi tries to trigger that the movement has completed by changing a boolean in the control cluster, the RT vi never sees it and does not respond.
1) Bad or inappropriate use of network shared variables?
2) a racing issue?
3) slow network?
4) should I buffer the control cluster?
5) a limitation of a custom control?
6) too many readers/writers?
7) should I change some control cluster nodes to relative, rather than absolute?
8) why can't I "compile" my RT vi into an executable?
Any help would be greatly appreciated. Unfortunately, I'm writing this from home and cannot attach vi files or pictures, but would be happy to do so at work tomorrow. I'm counting on the collective genius in the universe of LV users and veterans to save my bacon.....
David

Hi David,
I'm curious why you decided to build a CIN instead of developing the code in
LabVIEW. Is there some functionality that that LabVIEW couldn't
provide? Can you provide some more information about the LabVIEW
Real-Time target you're using? What type of IO are you using?
It is impossible to get LabVIEW Real-Time performance on a desktop PC running
an OS other than LabVIEW Real-Time. Even running a timed loop in LabVIEW
for Windows won't guarantee a jitter free application. Also, no TCP based
network communication can be deterministic. This means Network Shared
Variables are also not deterministic (they use a TCP for data transport) and I
advise against using them as a means to send time critical control data between
a Windows host and a LabVIEW Real-Time application.
In general, I would architect most LabVIEW-based control applications as
follows:
- Write all control logic and IO operations in LabVIEW Real-Time. The
LabVIEW Real-Time application would accept set points and/or commands from the
'host' (desktop PC). The Real-Time controller should be capable of
running independently or automatically shutting down safely if communication to
the PC is lost.
- Write a front-end user interface in LabVIEW that runs on the desktop
PC. Use Shared Variables with the RT-FIFO option enabled to send new set
points and/or commands to the LabVIEW Real-Time target.
Shared variable buffering and RT-FIFOs can be a little confusing. Granted
not all control applications are the same, but I generally recommend against
using buffering in control applications and in LabVIEW Real-Time applications
recommend using the RT-FIFO option. Here's why: Imagine you have a
Real-Time application with two timed loops. Time-loop 'A' calculates the
time critical control parameters that get written to hardware output in
timed-loop 'B'. Loop 'A' writes the outputs to a RT-FIFO enabled variable
with a RT-FIFO length of 50. Loop 'B' reads the outputs from the shared
variable, but for some reason, if loop 'B' gets behind then the shared variable
RT-FIFO will now contain several extra elements. Unless loop 'b' runs
extra fast to empty the RT-FIFO, loop 'B' will now start outputting values that
it should have output on previous cycles. The actual desired behavior is
that loop 'B' should output the most recent control settings, which means you
should turn off buffering and set the RT-FIFO length to 1.
There is also a clear distinction between buffering and the RT-FIFO
option. The RT-FIFO option is used to add a non-blocking layer between
network communication and time-critical code in LabVIEW Real-Time
applications. It also provides a safe mechanism to share data between two
loops running in a Real-Time application without introducing unnecessary
jitter. Network buffering is a feature that allows a client to receive
data change updates from the server even if the client is reading the variable
slower than the server is writing to it. In the example I presented above
you don't need to enable networking because the shared variable is used
entirely within the Real-Time application. However, it would be
appropriate to send control set points from a Windows PC to the Real-Time
application using network published shared variables with the RT-FIFO option
enabled. If it is critical that the Real-Time application executed all
commands in the sequence they were sent then you could enable an appropriate
buffer. If the control application only needs the latest set point
setting from the Windows host then you can safely disable network buffering
(but you should still enable the RT-FIFO option with a length of 1 element.)
Network buffering is especially good if the writer is 'bursty' and the reading
rate is relatively constant. In the robot application I can imagine buffering
would be useful if you wanted to send a sequence of timed movements to the
Real-Time controller using a cluster of timestamp and set point. In this
case, you may write the sequence values to the variable very quickly, but the
Real-Time controller would read the set points out as it proceeded through the movements.
The following document presents a good overview of shared variable
options: http://zone.ni.com/devzone/cda/tut/p/id/4679
-Nick
LabVIEW R&D
~~

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?

Shared variable engine memory problem

Hello,
I have a lot of problems with DSC 8. The server that worked very well in DSC 7, in DSC 8 is creating a lot of problems starting with memory leaks in tagsrv process. I have over 5000 shared variables and when I publish them the tagsrv is around 90Mb of memory. After approx. 30 min is around 130Mb and so on until the computer becomes useless. If I restart the computer the process is the same, even if I don't start the VI that updates the shared variables. I tried to uncheck different things in the variables definition like: no alarming, no buffering, no scaling, with no improvement.
Is there a way to undeploy the shared variables or processes manually, not from the labview project, or Variable Manager. To undeploy the mentioned library with the Variable Manager takes more that an hour (just to enumerate all the shared variables).
Any suggestion is welcomed,
cosmin

cosmin,
I have several thoughts for you. First, I recommend
splitting up
your 5000 variable library into a set of smaller libraries. In
contrast
with the LabVIEW DSC 7 engine, the LabVIEW 8 Shared Variable Engine is
optimized for multiple smaller libraries. I would recommend
having at
most about 1000 variables per library. You'll see some different
recommendations from different people at NI, but in my personal
experience I
think 1000 is about as many Shared Variables that can be easily managed
at
once. For your case this would mean having 1000 variables in 5
different
libraries. --Splitting up your library gives you the added
benefit of being able to
undeploy/disable individual libraries without affecting the other
libraries. Unfortunately, the SCF migration tool will not do this
for you manually so it may take a little time to get everything
organized.
Your comment about ever-increasing memory usage is
concerning. Do
you see this while deploying your library, or while writing
values? If
you write to values very fast (like in an untimed loop) for an extended
period
of time memory usage will increase as the variable buffers
increase.
Please elaborate more on this topic and let me know what happens if you
separate your variables into multiple libraries. I was not able
to reproduce this on a similarly spec'd computer using 10 libraries of
500 variables each.
You can programmatically undeploy libraries using the delete process VI
on the DSC Engine Control palette in LabVIEW. Use this VI in combination
with the get process list VI to quickly remove all currently deployed
libraries.
Also, regarding your question about why variables sometimes show up the
Published Variable Monitor window; the different utilities you described may
use different methods to get that variable list. These methods behave
differently depending on how stressed the Shared Variable Engine is. If
you're in the middle of loading a library with 5000 variables I'm not surprised
that the list won't get populated immediately in the Published Variable Monitor
window. After the library successfully loads though, you should be able
to refresh the view and see all the variables.
Regards,
Nick F
LabVIEW R&D
~~

Slow update of shared variables on RT (cRIO) after building exe

Similar Messages

Maybe you are looking for