How many clients subscribed to shared variable engine

Hi,
I have shared variable engine deployed on RT and want to know how many clients get access to the shared variables. Is it possible? Thanks!
Tom

Theoretically there is no limit for the number of clients (maybe there is a 2^32-1 limit somewhere I don't know about).
However, more clients create more threads and the CPU usage will increase.
So you shouldn't use that much clients or host the SVE at the host computer if possible.
Christian

Similar Messages

How to build a executeable shared variable engine (DSC 8.0)

Hello!
At first a short overview about the actual data-flow at my system: there are several Fielpoints and a Diagnostic-PC which also produces data. All measurement data should be logged at a server. Therefore in Labview 7.1 i used the Tag-Engine and their Datalogging via Citadel-Database. My problem is that we moved to Labview 8 and i have to build a executeable engine (should run without full installation of LV 8 an the server) which has to collect data from the Fieldpoints and the Diagnostic-PC and log this data too. Is there any possibility in DSC 8 to start the SVE with LV code? I miss functions like starting the tag-engine programmaticly with a predefined signallist which was possible in LV 7.1.
Best regards,
Jan

In 8, you do not need to start the engine programmatically, it always run. To load a predefined net list all you need is to use the deploy library.vi from the engine control pallete. So for your server you need to have dsc runtime installed, then build and application where you can pick a library file to deploy and put the exe and library file on the server.

How do I install Shared Variable Engine on a computer not having Labview?

Hi,
I am trying to communicate with a real time program running on Compact RIO through shared variables. I have an executable of the host vi that runs on a Windows computer. If I run this executable on the computer that has Labview installed on it, it functions fine. I want to be able to run this executable on a computer with Labview. I learned that I have to first install Shared Variable Engine on this computer.
How do I do that? Where to install it from? Is that going to be sufficient? Please provide the solution or point me to the right resources.
Thank you.
Anmol.

When you built the installer for the executable, you have a choice to include additional installers. One of them is the "NI Variable Engine". Have you tried including it?
LabVIEW Champion . Do more with less code and in less time .

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 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 Variable Engine OPC Server & Matrikon OPC Explorer

Hello All
I have a shared variable Engine OPC server running on my IPC. I am querying NI OPC Server through Matrikon OPC Client. My situation is if shared variable engine process is switched forcefully off (NI DSM) or communication between server and client is lost then client is crashing which is quite obvious. But the problem is if Server is Up again then the client is not connecting to server automatically.
First of all is it possible, that if server is up again then it will try to send some signals to the priviously connected clients ? If yes then do i have to make changes in shared variable engine properties ? How i can do this ?
I hope you all will understand my problem, if not please post you doubts. I will try to clear my points.
Thanks & Regrad´s
Varun Garg

Hi, just now I face a similar problem. When clients restart connection, the variable engine crash, for now the only way founded is restart the program programmatically, but I'm interested in how fix that.

Shared variable engine OPC delay

Hello All,
I've got a bit of a problem with the delay time of updates between a non NI OPC server and a shared variable engine OPC client. I am using the redion OPC software OPCWorx with a database of around 120 tags to monitor and log data from a small pilot plant. The OPCWorx server has been configured with a 500ms update rate and the NI OPC client as the same. So here is my problem; logged updates occur no faster that 2.5s which is fine as we are exporting in 3 sec intervals (would still like to increase the performance of this to around 1 sec) but the main nuisance is the delay in changing control registers in the PLCs. The controls and indicators are directly bound to the shared variable items where by a change in a boolean control on the front panel to the indicated response can range from 5 to sometimes 15 seconds delay. If I bind the same control and indicator directly to the OPC item through the data socket the delay in response is almost unnoticeable at around 1 sec. I have increased the update/logging dead bands of the shared variables which seemed to help but only by a second or so.
Im wondering what the limitations of using an OPC shared variable engine is and if this is expected or have I gone wrong somewhere. All the variables are configured as non buffered and to have single writers.
A few changes have been suggested;
- Upgrading the PC. The current hardware is AMD Phenom 2 3.21GHz processor, 4GB of ram running windows XP.
- Using Modbus over ethernet instead of OPC.
This is the first major use of the DSC module and using the shared variable engine as an OPC client so any information or insight to help with this would be much appreciated.

Hi Kallen,
The Shared Variable Engine can become bogged down when there are more than 100 shared variables. This may be what you are experiencing. We can check buffering for the variables and disable it, and that should improve performance slightly. As it is, using datasockets may be the best method for over 100 shared variables. I apologize for the inconvenience.
Here are some KnowledgeBase articles that can be of use with regards to this issue:
How Does Buffering Work for Shared Variables?
http://digital.ni.com/public.nsf/allkb/5A2EB0E0BC56219C8625730C00232C09?OpenDocument
Why Is Accessing IO Variables Through The Shared Variable Interface So Slow?
http://digital.ni.com/public.nsf/allkb/F18AEE4BE7C9496B86257614000C43DF?OpenDocument
Matt S.
Industrial Communications Product Support Engineer
National Instruments

Shared variable engine network published source issue

Hello,
I am attempting to use the shared variable engine to share some simple stings over a network between a Windows 7 computer and a Windows XP computer.
I got through the shared variable example just fine and can share variables between VIs on a single computer. When I open the shared variable engine, it shows the client and server variables that are shared on the local computer. I then create a new process, and attempt to define a new variable, and the Shared Variable Property screen comes up. I attempt to "Bind to Source" and click browse, and see the computer name I am attempting to connect to. However, when I click it, it stalls and I cannot expand the computer to find the variable I am trying to bind to. What am I missing?
Thanks, Arron

Arron,
This document may be useful in helping to setup your network shared variables. Take a look at this and see if you have followed all the outlined steps in setting up a network shared variable.
http://zone.ni.com/devzone/cda/tut/p/id/4679
Let me know how this works for you.
-Nick-
Nick C | Staff LabVIEW Platform Product Support Engineer | National Instruments

Shared Variable Engine Error Handling

I have a HMI system that connects through shared variables to an OPC Server. I have encountered problems with Variable Engine, and a problem with tagger which I don't know anything about. I checked OPC Server to see ifit's installed properly and the items status is good, and the server's connected. I tried to restart the shared variable engine service but it doesn't reply. When I monitor variables there's no connection. I used Alarm&Event query.vi in my application and then encountering tagger error, server connection failed. How could I handle these errors?
I appreciate any help.

I've created Bindings to OPC items I want to read/write through an OPC Client instance, bound front panel objects to these shared variables, deployed the entire library and run the VI.
All the connections were true (green PSP-LED. through the Monitor Variables all the variables and OPC items of client instance had good quality and right value.
All the variables were configured to log data and alarms.
Configuring the library for a data base through it's DSCsettings:database, I used Historical VIs (Read trace,… ) to retrieve data from citadel and they worked properly. I used Alarm & Event Query.vi to retrieve alarms from citadel, the VI encountered this Error:
        "Some part of tagger encountered a problem and should be closed"
After that the entire connections failed (PSP-LEDs goes red) and the I/O Engine couldn't be restarted and shows this Error:
             "Could not stop the National Instruments Variable Engine Service on local computer.
              Error 1053: the service did not respond to the start or control request in a timely fashion."
And the variable monitor dosen't show any library and variables.

Error with the Shared Variable Engine

Hi,
I have a problem with the Shared Variable Engine,
A .doc File is attached to this message, decribing the problem with pictures.
I will be glad if anyone can help me.
Sincerely yours
Amitai Abramson
Attachments:
Question.doc ‏819 KB

Hi Amitai,
Good afternoon and I hope your well.
A member of the team from NI Israel contacted me regarding this post.
I want to provide you with extra details on how to resolve your issue - i.e. Repair (Or Re-install) the Shared Variable Engine.
If you use the MsiBlast Tool it will populate a list of all MSI NI Installers. One of these will be NI Variable Engine. On the right-hand side you can the click 'Repair'. I would also Repair the engine support for the versions of LabVIEW you have installed. Please see attachments for MsiBlast and a screenshoot of the MSIBlast screen.
If this doesn't work I would recommend re-installing LabVIEW using the following guide, which I posted on this forum. (second post by me).
Please let me know how you get on,
Kind Regards,
James.
Message Edited by Hillman on 12-03-2008 12:19 PM
Message Edited by Hillman on 12-03-2008 12:19 PM
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!
Attachments:
Repair Shared Variable Engine.JPG ‏97 KB
msiBlast.zip ‏110 KB

Shared variable engine with pro-face touchscreen windows 2000 professional

hello,
who has some experience with the shared variable engine from LabView 8.5 and a touchpanel from Pro-Face?
We try to deploy shared variables from the touchpanel but it doesn't work. Additionally the windows service ni shared variable engine dosn't start and we can't start it manually .
The touchpanel is a PS3701A from Pro-Face with Windows professional 2000 for embedded, Pro-Face told us that we have the full service of Windows 2000 professional on a regular PC.
Many thanks in advance
derN

Hi Andrew,
Thanks for the feedback! Your feedback will help us to improve LabVIEW for our customers. This bug has been reported to R&D (#45493) and they are currently investigating this issue. For now, the best workaround appears to be using a different OS, as this seems to only occur in Windows 2000. Thanks for the feedback!

What causes the Shared Variable Engine to Crash?

All,
Some background info:
I am using the SVE and DSC so that I can log my data to Citadel using Data Sets. I converted a previous DSC 7.1 project that used the tag engine over. That app ran for over 18 months. Need to upgrade app and add features at my customer requests so we migrated to LV 8.0.1.
I have an app that crashes the Shared Variable Engine (SVE). I created a test app with a single SV and then created a control and bound it to the SV and it works every time until I launch the larger app. The main app only has 33 SV that are set when I receive TCP data from PXI RT system (not using SV on RT since the logged data is only a fraction of the total data streamed and I don't want to take apart the RT data and send the SV separately). I have bound front panels controls to the SV's. When I run, I get server connection has been closed. I verified that the SVE was running with the test app before launching the main app.
I deploy the shared variables in the application and have verified they are deployed by the Monitor Variables utility ... but it always shows "No Value" for the data fields. I have set logging to enabled for data only, set Value Deaband (%) to 0 and Value resolution to 0, Update Deadband is Disabled as is Alarming, Scaling, Initial Value and Description. Security is set to default. All of the variables are set to Double, Network-Published, Single Writer with Buffering and Bind to Source disabled.
I have verified that the SV deploy without error by clicking Deploy from the project. Autodeploy All is off but I get the same results with it On (checked).
I undeploy and kill the process when I close the application.
I have tried only using 1 or 2 of the SV in the main app but get the same results. Every once in a blue moon it will work after rebooting the PC (but not everytime). Once it dies I have tried running NI examples as well as the test app and they fail until I reboot.
The error code indicates that the SVE engine has crashed. I have changed the service settings on Windows to relaunch on 1st, 2nd and all times after but nothing restarts the SVE. After it crashes it is impossible to exit LabVIEW without it hanging or reboot the PC without pressing the hard On/Off switch.
Once it dies there is nothing that I can do to get it back alive without rebooting the PC (a real problem for a control and monitoring system).
Any ideas would be greatly appreciated
Thanks.
Randy

Randy
Sorry for the delay, I've been researching your issue and juggling a few other issues. :-) One thing we can check is the Windows Event Log which will give us some more details as to WHY the Shared Variable engine seems to be blowing up on us (Conttrol Panel -> Administrative Tools -> Event Viewer). Any details in there along the lines of Variable Engine or Tagger crashing will help us narrow down what's going on.
There's always a possibility of files not getting upgraded correctly; however there aren't many shared components between LV 7.1 and LV 8.0. The Shared Variable engine is entirely new and the installations of LabVIEW themselves don't share many files outside of the example finder and a few other small common components (things located in the appropriately named Shared folder) I keep both on my machine (in addition to 5.1, 6.1, 7.0, and 8.2) without any hiccups.
The SVE crashing I have seen in the past (and from internal bug reports) has been from buggered installs, so uninstalling and reinstalling DSC may be a good course of action. One good test to do in the middle is to see if the engine still crashes with DSC uninstalled.
Hope this helps.
--Paul Mandeltort
Automotive and Industrial Communications Product Marketing

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.

Executable won't re-connect to shared variable engine when it breifly goes offline

Hi,
I have shared variables that are hosted on a field-point controller. I read these variables from executables that run on a PC. When the shared variable engine on the field point controller goes offline and then comes back online (for instance, if I cycle the power to the controller), the executables on the PC don't automatically reconnect. I need to restart the executables in order for them to re-connect and read the shared variables.
Any ideas on how to have the executables automatically re-connect? I don't want to have to restart the execuables when the power cycles on the controller,
Thanks, Derek.

Hi Derek,
It is my understanding that the variables should reconnect, even after your FieldPoint has been power cycled. I found a few articles that could be helpful; read through these and let me know if you are still having issues.
http://digital.ni.com/public.nsf/allkb/7BA64956A475405F862570ED007B2A88?OpenDocument
http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6?OpenDocument
http://digital.ni.com/public.nsf/allkb/AA97FF29D0B3C748862572F600055B22?OpenDocument
Cheers,
Marti C
Applications Engineer
National Instruments
NI Medical

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

How many clients subscribed to shared variable engine

Similar Messages

Maybe you are looking for