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.

Similar Messages

Using shared variables in a rt target

Hi all,
I wrote a diesel engine ECU in LV 7.1 FPGA and ran it for the past year, using TCP VI's to communicate between the Host and cRIO-9004.
Next, I translated it to LV 8.0 (with some difficulty recompiling the FPGA) and it worked fine up to that point.
Next step was to use the much-touted shared variables to eliminate all the TCP overhead. I defined 2 shared variables as big clusters with lots of controls and data passing back and forth. This worked fine while running under the source code. However, once I compiled the Host and cRIO code (ECUHost.exe and C:\NI-RT\startup\startup.rtexe), the sharing stopped.
I tried defining and binding the variables under My Computer and also tried under the cRIO target, with no success. I was able to get source code to talk to compiled code (I forget which one was which), but not when both were compiled.
Thanks for any suggestions,
McSynth

That is quite strange. Here is some information regarding shared variables and building stand alone applications that may or may not help:
Using Shared Variables in Stand-Alone Applications or Shared Libraries
If you plan to distribute a stand-alone application or shared library (DLL) that uses shared variables, do not include the .lvlib file in an LLB, the executable, or the DLL. Use the Source Files Setting page of the Application Properties dialog box or the Source Files Setting page of the Shared Library Properties dialog box to change the Destination of the .lvlib file to a destination outside the executable, LLB, or DLL.
Best Regards,
Jaideep

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?

How to use shared variables to address multiple Watlow controllers on the same COM port

Hello,
I am trying to use LabVIEW 2010 to control 4 Watlow temperature controllers on one COM port. 3 are Model 96 and 1 is an EZ zone controller. Each controller has a unique modbus address, and I am trying to read from and write to individual registers (such as closed loop setpoint) using shared variables. I am getting return data when reading (although the data appears to be invalid), but am unable to change the value in the register by writing. How can I be sure that the Modbus server is sending commands to the correct controller?
Chuck
Solved!
Go to Solution.

Peter,
Thanks for the reply. I have actually solved that problem. I realized that the Modbus server address has to be the same as the controller's Modbus address.
I have, however, run into another problem. Perhaps you could help me with that. I have a system with 4 Watlow controllers, 3 are series 96 controllers, one is PID only and 2 are ramping. The 4th controller is an EZ zone. I am using RS485 for communications and the controllers are all wired in parallel for communications and power.
I have set up 2 Modbus servers for 2 of the controllers.
This is the first I have ever worked with Modbus based communications. I have successfully programmed using the Modbus read/write VIs, and am wanting to move to shared variables. My questions right now revolve around addressing, Modbus I/O servers and COM ports. Specifically, at this point, I know the addresses need to match up between the server and the slave device (Watlow controller in my case), how many servers can I create and use on one COM port? If the number is limited, is there a way I can specify an address that I want the server to talk to? Will the broadcast mode work to request data values from the controllers?
I'd appreciate any information you can help me with, or if you could point me to some sort of concise 'How-To' for Modbus communication.
Thanks.
Chuck

How to find Shared Variable Processes on RT target

It seems like it should be possible to query the SV Engine on a RT target for a list of all processes running and also the SV's within those processes.
The DSM (Distributed System manager) can do it, why can't I?

Also, you might also want to check out this KnowledgeBase.
Regards,
Claire Reid
National Instruments

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.

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

Shared variable, missing data, the same timestamp for two consecutively data

hello
I have a problem with missing data when I read from a network published shared variable.
Host VI:
In a host VI on my Laptop (HP with WinXP Prof.) i'm writing data to the shared Variable "data". Between two consecutively write operations is a minimum of Milliseconds waiting time. I use that because I want to be sure that the timestamp for each new data value is different then the preview one (resolution shared variables is 1 ms)
Target VI:
the Target VI on a cRIO-9012 realtime device is reading only new data in the way that it compares the timestamp of a new value with the timestamp from the last value.
Problem:
rarely, I'm missing a datapoint (sometimes everything works fine for several hours, transferring thousands of data correctly before suddenly the failure happens). With some workaround I'm able to catch the missing data. I've discovered that the missing data has the exactly same timestamp then the last readed datapoint, therefore is ignored in my "legal" data.
To sum up, the missed value is written to the shared variable in the host, but the target ignores him because his timestamp is wrong, respectively the same as the last value has, despite the host waits every time for a minimum of 10 milliseconds before writing a new value.
Note:
The shared Variable is hosted on the Laptop and configured using buffering.
The example is simplified only to show the principle function, in real I use also a handshaking and I secure that there is no over- and underflow.
Simplified Example:
Question:
Has someone an idea why two consecutively data can have the same timestamp ?
Where is the (wrong) timestamp finally coming from (system?) ?
What would be a possible solution (at the moment with shared Variables) ?
-> I tried a workaround with clusters where each data gets a unique ID. It works but it is slower than comparing timestamps and I could get performance problems.
Would it change something when I host the shared Variable on the RT-System ?
Thanks for your help
Regards
Reto
Solved!
Go to Solution.

Hi Reto,
I had a look on your modified Example.
Because the Shared Variables didn`t work like Queues or Notifiers (No Event or Interrupt when a new value has been written. And for sure the´re not possible over a network) you will see the issue, that the code is reading the values more often with the same timestamp (Polling Problematic) if the reader is faster then the writer. And because the timestamp is written with the value you´re able to program like you do. Filter out whats duplicated when you have the same timestamp.
Everything is described in here:
http://zone.ni.com/devzone/cda/tut/p/id/4679#toc1
Laurent talked about a second depth of buffer. Please have also a look at the link. Somewhere in the middle of the tutorial you see the explanations of Buffer and RT-Buffer.
Regarding your question: Would it change something when I host the shared Variable on the RT-System? --> No
In my experiences, you should consider to place the Shared Variable Engine after asking some questions regarding the application.
You will find the Answers to this 3 Questions also in the link:
Does the application require datalogging and supervisory functionality?
Does the computing device have adequate processor and memory resources?
Which system is always online?
And you`re right the smalles time interval you can see in the timestamp is 1ms.!
What you also can do is working with an enabled "timed out". This might be more performance efficient than reading the timestamp.
What I don`t know and not find up to now, is if LabVIEW or the OS adds the timestamp. It´s taken from the system time, this looks like LabVIEW is taking the value and adds it.
I hope this helps
Alex
NI Switzerland

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

Custom Shared Variable: Setting default values

Hi All,
Is there any way to set default value to a custom shared variable (2D Array of Strings) hosted in cFP-2220 target.
Problem: Reading a custom shared variable after rebooting the target, doesn't contains the recently updated values.
Thanks,
Bhaskar

To me the one way it is possible is to log the details to a file and upon launch read the file.

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).

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?

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

RT Shared Variable Engine stops publishing

I have an RT system (PXI-8106) that hosts quite a few network published shared variables (NPSVs) for communicating to a Host PC. My Host and RT executables have been functioning fine on their respective systems for weeks, but just recently, I started running into problems with my NPSVs. My Host application has indicators to display DAQ data being acquired on the RT target and transferred via NPSV, and lately the application will update normally fine for several hours and then the displays will stop updating all of a sudden. If I reboot the RT target, the communication is restored...for a couple hours, anway, until we get another NPSV lockup. I can see no rhyme or reason as to why it stops updating the variables when it does; it seems to just randomly crap out.
It just happened again, so I brought my development laptop down to run the Distributed System Manager. Sure enough, the NPSVs all stopped updating (latest timestamp was about 30 min previous to my check). I know, however, that the RT system is still running (I can open remote front panels), and none of the NPSV calls use their error input clusters, so an upstream error would not be causing the issue. Also of note, I have a couple NPSVs that are aliased to PSP URLs (NI_SystemState\CPULoad), which do continue to update while the remaining NPSVs do not. So that seems to indicate to me that it is not a networking issue, nor is it a Shared Variable Engine issue.
I also programmatically deploy the NPSV library from the Host to the RT target on initialization, so I know they are deployed properly. Redeploying does not kickstart the RT SVE into updating. The only thing that seems to solve the problem (albeit temporarily) is a reboot of the RT target.
Does anyone have any ideas as to what might be causing the RT to stop updating the NPSVs? I have already check the NPSV Troubleshooting KB (http://digital.ni.com/public.nsf/websearch/6E37AC5435E44F9F862570D2005FEF25?OpenDocument), and none of those suggestions appear applicable in this case (most address networking issues that result in never being able to read the NPSVs in the first place, whereas my problem is NPSV communication dropping out arbitrarily). Has anyone else run into such a problem?
Thanks!

I think I have an idea as to why my NPSV communication was freezing. One of my NPSVs is a 2D String Array of Alarm History Data, which just published infomation about alarms that have been triggered on the RT system; each new alarm appends a 10 element string array onto the 2D string array. For the most recent testing we were running, there was a recurring alarm condition that was not applicable (i.e. did not need to be handled--it just kept adding new elements onto the history array), and I am guessing that the array may have just gotten too big. When the RT target kept updating the NPSV (at 1 Hz) with more and more 2D String Data, it may have caused a buffer overflow for the shared variable.
I will attempt to recreate the problem on another system to verify the cause.

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
~~

Shared Variables, Scan Engine & Multiple Targets

Similar Messages

Maybe you are looking for