Indicator bound to shared variable

Does anyone use indicators that are bound to shared variables? How is it working out for you? I inherited an app that has a gazillion SV's and want to simplify a few things. Thanks in advance.
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

They've worked out great for me. I have quite a few indicators of various types to display telemetry in the UI to the user during a test. The shared variables are all written in a particular background thread. I don't use a "gazillion", though, perhaps no more than 40. I'm able to read, process and write the shared variables (and see indicator updates) at a 60 msec rate under Windows XP on a PXI controller.
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

Similar Messages

Blink while alarm on using shared variables with remote panel

I am creating an application where I have front panel indicators data bound to shared variables. I also set it up to have them blink when the alarm is on. I am using the DSC module.
This works great under the development environment. But when I connect using the remote panel, I can no longer see the blinking indicator if there is an alarm. I can see the blinking indicator on the machine that is running the program, but no on any of the remote panels (I have no problems connecting to the remote panel and controlling the program).
I have the remote panel set as embedded, since I want the user to be able to change some settings over the network.
I am sure I am missing something simple, any ideas??
thanks
Kenny

I have been using IE6 and Firefox, and I have found that the blinking does show up, if you refresh the page. And then if the alarm stops and the blinking stops, you will not notice it until you refresh again.
Kenny

Problem Sharing Variables between 2 machines

I am having problems trying to create a project that would share variables between multiple computers. I am using Labview 8.2.1 (I am new to 8.2.1 and Shared Variable).
here is what i did:
1. I created the project with Client and Server VI's and a library containing shared variables, which both of them call
2. I placed this project onto 2 computers (XP on a local workgroup, no firewall, see each other).
3. On one of the computers I bound all shared variables to their counterparts on the other computer
The system is "almost working"
The problems are:
- I initially used wrong type variables for few items. I then modified the variables in both VI's and Shared Variable libraries and repeated the Steps 1-3 above.
But the sysrtem has some sort of a buffer somwhere, because it keeps bringing the old types of shared variables back (when I monitor them using Shared Variable Monitor).
- When I do binding to source, the system shows wrong variable types (for example DBL instead of U8).
- It takes almost a second to write and read shared variable (my network is quite fast)
I saw that the Labview Example with Server and multiple Clients uses 2 sets of shared variable and they bind - separate sets (different names) fro client and server within the same project. Do I have to do this or is this done just to simplify bindinga nd future distribution?
Is there a buffer/setup/file that I need to clear to get rid of "old" shared variable assignements? (I tried undeploy/deploy - does not help...)
Thank you very much,
Gleb.

Hi Gleb,
It sounds like the shared variable is not getting completely undeployed from the shared variable engine. I would recommend opening the shared variable manager and undeploying the library from there just to see that it is no longer in the engine. Then, redeploy the library and rebind your variables to the host library that you have deployed.
It is not necessary to have different sets of variables for client and host. The important part of the variable is what it is bound to, not necessarily what it is named. So just undeploy your variable, double check the settings of the host variable, then redeploy using the variable manager and rebind your client variables.
I hope this helps,
Brian Coalson
Software Engineer
National Instruments

Bound control doesn't always update shared variable (LV 8.2 + DSC)

It seems that it is possible for a bound shared variable to NOT always get updated with the latest UI control value that it is bound to.
If you run the vi in the attached project, and (fairly quickly) toggle the 'Keyswitch Control' between the 'Off' and 'Start' positions, you should be able to reproduce the effect shown in the attached pdf. Sometimes the bound shared variable (Keyswitch_Control) gets stuck in the 'On' position when the control reads 'Off' or 'Start.' It does not catch up after a little while either; it seems truly "stuck."
Unless I am missing something here, this looks like a bug.
I haven't played around with any other control types yet to test further. I also don't know if this is limited to 'control -> SV' binding or if it also affects 'SV -> indicator' bindings (I hope not!).
Any ideas!?!?!?
Attachments:
DataBindTest.zip ‏21 KB
DataBindTest.pdf ‏40 KB

Hello WHAVEman,
I was able to replicate what you were observing. It seems that there is a bug in the front panel binding code. I would be filing a Corrective Action Report to let R&D know about this. Thanks for pointing it out.
Just on the side note, if you are looking to build an application based on the application architecture as in your posted code, then I would recommend that you refer to the attached VI for a much more efficient way of doing this.
Regards,
Chetan K
Application Engineering
National Instruments
Attachments:
Connect Shared Varibles.vi ‏29 KB
DataBind UI_modified.vi ‏12 KB

Problems reading from bound shared variable

I have a shared variable that is bound to another shared variable. When I go to read it's value in a VI by wiring the variable to the "value" property of a digital numeric object it displays zero. When i look at the two shared variable in the variable manager they show the correct values. Does anyone have a clue what's going on?

Welcome to the forums!
Let's narrow down the possibilities here. Try wiring the shared
variable directly to a front panel indicator rather than using a
property node. Second, the shared variable object includes an
error out terminal - this is where the variable engine can report any
errors in obtaining a value from the bound item. Wire the error
out to an error handler VI and re-run - you may find that the Shared
Variable Engine is reporting an error, which would be most helpful in
determining the problem.
If you could let me know the results of the above suggestions, I'll be glad to help further!
Cheers,
Matt Pollock
National Instruments

Creating shared variables bound to I/O Aliases

Hello,
I'm running LabVIEW 2012. When I right-click on an .lvlib in the project explorer, there's a "Create Bound Variables" option. It's really convenient, as it automatically binds many variables to generic network-published shared variables simultaneously.
However, it doesn't seem to support network-published I/O Aliases -- those libraries just don't show up in the dialog. I know that the I/O Aliases themselves work fine, because I was able to bind them manually, and then read them from my PC.
Is there a way to automate the binding process for I/O Aliases?
Thanks

Hi Joey,
It's mainly for maintainability.
I/O Variables are grouped physically by chassis and module, not by purpose. My current project is a plant controller, using 3 CompactRIO chassis (linked by EtherCAT) and 20 C-series modules. The I/O ports for a logical part of the plant can be split across different modules (and even different chassis sometimes) -- thus physical grouping is suboptimal.
Here is our simplified system architecture:
We need variables hosted on the PC server for DSC logging, but also need variables hosted on the cRIO for robustness (e.g. in case connection with the PC server is lost).
We have 2 primary reasons to create I/O Alias libraries, instead of binding directly to I/O Variables:
It lets us group the variables more logically, which in turn lets us simplify our code for programmatic variable access. It's an abstraction layer between the hardware and the code. The logical groupings also help our developers better visualize the system.
The client has not finalized their specifications, and the I/O port mappings might change. If we use I/O Aliases, we can just change the I/O Variable that the I/O Alias points to, and that's it. However, if we bind directly to I/O Variables, changing the hardware mapping will require us to change (i) the controller code, (ii) the I/O Variable that the PC variable points to, and (iii) (technically optional, but needed for readability) the I/O Variable name
Anyway, since it is possible to (manually) create bindings to I/O Aliases, I'm surprised to hear it's expected behavior that we would not see the Aliases in Project items when we use the Create Bound Variables function

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

Error Reading a Shared Variable Array

Hi,
I am having a problem reading an array of 20 unsigned integers from an Allen Bradley ControlLogix PLC with Labview.
I have set up a shared variable for this purpose. I have set the Data Type of the shared variable to ArrayOf Unit16. The Variable Type is Network-Published, and I have check the Bind To Source checkbox. I think my problem is in the shared variable path. I have tried the following with no success:
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults[0]
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\Faults[]
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults\
MyComputer\ControlLogixTags.lvlib\RsLinx\ProjectX\Online\Faults
I have created a simple vi for testing. I have wired the shared variable to an indicator which is an array of UInt16 items. When I run the vi, I get an error which says "Error 91 occurred at Variant to Data in Text.vi. Possbile Reason: The data type of the variant is not compatible with the data type of the input."
Does anyone have a suggestion as to what I am doing wrong?
Thanks in advance for your help,
Phil

Phil,
In order to determine that you can correctly communicate with your OPC server, I would suggest creating a shared variable bound to a single tag. It sounds as if you already have an RSLinx I/O Server in your project library. Now you can create a new shared variable and use the browse option to browse the items of your I/O server. Be sure to select a tag that has a known value such that you can verify successful communication.
Also, does your VI utilize a dynamic data conversion? The error code mentioned (error 91) is normally associated with this data type. Our next step will be to look at this VI once we can establish successful communication. I hope this was useful for you. Please let me know if I can be of further assistance.
Mike
National Instruments
Applications Engineer

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 Crashing LabVIEW

This is just one of those projects that has a brick wall at every turn so far. Two computers running LV2009. Computer A hosts Data Write Shared Variable. Computer B hosts Data Read Shared Variable. Data Read is bound to Data Write. Everything was working fine, and then late yesterday afternoon, I don't think I had changed anything on the shared variable, I start up my VI on Computer B, and LV crashes. The VI starts to run until the first execution of Data Read, and then poof, everything open in LV dissapears. The problem is one hundred percent repeatable since then.
Here is what I know:
1. An error indicator hooked to Data Read shows -1950679034 (Shared Variable has no value) for about a second before the crash. Everything stops executing as soon as the warning appears.
2. The Data Write is single writer, but it is also occasionally read in the VI that it is written in. It is not being read when the crash happens. I can however perform the read on Computer A without incident.
3. Not sure if this is related, but if I open the VI on Computer B, and then open the project, I am not able to drag Data Read from the project onto the block diagram. I also cannot perfrom any operations on the Shared Variable (like right click, ignore timestamp). I have to close the VI and reopen it from the project. Thinking back, this problem may have started when I opened the VI without opening the project.
I am torn between abandoning Shared Variables and trying to figure this out. I would definetely prefer to use the Shared Variable, especially because I need some buffering. I'm guessing I can buffer things some other way. Not sure if I can remotely access a queue, or ... ?
Solved!
Go to Solution.

I looked at STM, but I think the Data Socket VI's may be a better fit for me. It seems like Data Socket and shared variables are sort of intertwined, but I'm hoping DS doesn't suck as much as the SV seems to so far.
I think NIC means network interface card? Anyway, I don't really know how many I have. The Data Writer is on a PXI8108 with Windows, the reader is an old crappy Dell that I inherited with the desk.
I'm also not sure about the logos.ini file you referred to.
My intention is to transmit an array of double waveform that is about 15 - 20 channels acquired at 100 - 1000 Hz. I think the Data Socket looks like the simplest way to do this, and I could live with 100 Hz if speed is a problem, but I sort of don't think it will be. I'll try tomorrow unless somebody has a better suggestion.
By the way, I saw in another post a similar problem with Shared Variables that is supposedly fixed with the new patch for 2009, but I'm not sure I trust SV's because this will, for about thirty seconds of its lifetime, be one of the most critcal applications I've written, so I want confidence that it will work for those thirty seconds.

Reading shared variables

hi ,
im having problems reading a shared variable value from a vi ,
i created a project library , periodic i/o server deployed it. created the shared variables i needed . bound them , created my new vi draged the shared variable i wanted to read , just a time value , set it to a indicator , then ran the two vi s the triangle has apeared on both the main vi and the hmi vi ,and is green , no conflicts arose , but the hmi vi isnt displaying the data ,
both vi s are on the same computer , have i missed somthing ,?

Hi Vadajooz,
Good Morning and I hope your well today.
I was wondering how you got on with your application and if you still require support?
If so, I would be interested to know what version of LabVIEW you are using?
I would make two simple VIs, one to write to the variable and one to read from the variable.
1. Create the bound variable.
2. Deploy the library, make sure it appears in the Distributed System Manager (DSM - LabVIEW 8.6+) or Variable Manager (LabVIEW 8.5 - ).
3. Run the writer VI, for example, just have a switch (true/false) and when you change the switch state does the status update in the DSM or Variable Manager?
4. If so, then run the reader VI, is the status matching the writer and there DSM/Variable Manager.
*DSM/Variable Manager can be found by going to tools>>... in the VI toolbar.
If you are still having problems,
A. There is a known issue with bound variables in LabVIEW 8.6 - so I can inform you on this if you are using it.
B. I would confirm that the variable is deployed - to do this right-click the library and select Deploy All.
C. Make sure you write to the variable before reading from it.
D. Add error cluster indicators and note any errors you see.
E. Please attach your simple (test) project - so we can confirm its correct.
I hope this helps,
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

Peculiar behavior of Shared Variable RT FIFO

I'm trying to "leverage" the enhanced TCP/IP and Shared Variable properties of LabView 8.5. My application involves (among other things) doing continuous sampling (16 channels, 1KHz/channel) using 6-year-old PXIs (Pentium III) and streaming data to the host. I developed a small test routine that was more than capable of handling this data rate, even when I had the host put a 20msec wait between attending to the PXI (to simulate other processing on the host). To do this, I enabled the "RT FIFO" property of the Shared Variable (which was an array of 16 I16 integers) and specified a buffer size of 50 (that's 50 arrays). Key to making this work was figuring out the "error codes" associated with the SV RT FIFO, particularly the one that says the FIFO is empty (so don't save the "non-data" that is present).
Flush with success, I started developing a more realistic routine that involves rather more traffic between Host and Remote, including the passing back and forth of "event" data. These include, among other things, "state variables" to enable both host and remote to run state machines that stay "in sync"; in addition, the PXI also acquires digital data (button pushes, etc.) which are other "events" to be sent to the Host and streamed to disk. I developed the dual state-machine model without including the "analog data" machine, just to get the design of the Host/Remote system down and deal with exchanging digital data through other Shared Variables. Along the way, I decided to make these also use an RT FIFO, as I didn't want to "miss" any data. One problem I had noticed when using Shared Variables is the difficulty of telling "is this new?", i.e. is the variable present one that has been already read (and processed) or something that needs processing. I ended up adopting something of a kludge for the events by including an incrementing "event ID" that could be tested to see if it was "new".
Today, I put the two routines together by adding the "generate 16-channels of integer data at 1 KHz and send it to the Host via the Shared Variable" code to my existing Host/Remote state machine. I used exactly the same logic I'd previously employed to monitor the RT FIFO associated with this Shared Variable (basically, the Host reads the SV, then looks at the error code -- a value of -2220 means "Shared Variable FIFO Read Buffer Empty", so the value you just read is an "old" value, so throw it away). Very sad -- my code threw EVERYTHING away! No matter how slowly the Host ran, the indicator always said that the Shared Variable FIFO Read Buffer was empty! This wasn't true -- if I ignored the flag, and saved anyway, I saw reasonable-looking data (I was generating a sinusoid, and I saw numbers going up and down). The trouble was that I read many more points than were actually generated, since I read the same values multiple times!
Looking at the code, the error line coming into the Shared Variable (before it was read) was -2220, and it remained so after it was read. How could this be? One possibility is that my other Shared Variables were mucking up the error line, but I would have thought that the SV Engine handling reading my "analog data" SV would have set the error line appropriately for my variable. On a hunch, I turned of the RT FIFO on the two Event shared variables, and wouldn't you know, this more-or-less fixed it!
But why? What is the point of having a shared variable "attached" to an error line and having it return "Shared Variable FIFO Read Buffer Empty" if it doesn't apply to its own Read Buffer? This seems to me to be a very serious bug that renders this extremely useful feature almost worthless (certainly mega-frustrating). The beauty of the new Shared Variable structure and the new code in Version 8.5 is that it does seem to allow better and faster communication in real-time using TCP/IP, so we can devote the PXI to "real-time" chores (data acquisition, perhaps stimulus generation) and let the PC handle data streaming, displays, controls, etc.
Has anyone been successful in developing a data-streaming application using shared variables between a PXI and and PC, particularly one with multiple real-time streams (such as mine, where I have an analog stream from the PXI at 16 * 1KHz, a digital stream from the PXI at irregular intervalus, but possibly up to 300 Hz, and "control" information going between PC and PXI to keep them in step)? Note that I'm attempting to "modernize" some Version 7 code that (in the absence of a good communication mechanism) is something of a nightmare, with data being kept in PXI memory, written on occasion to the PXI hard drive (!), and then eventually being written up to the PC; in addition, because the data "stayed" on the PXI, we split the signal and ran a second A/D board in the PC just so we could "see" the signal and create a display. How much better to get the PXI to send the data to the PC, which can sock it away and take samples from the data stream to display as they fly by on their way to the hard drive!
But I need to get Shared Variables (or something similar) working more "understandably" first ...
Bob Schor

Bob,
The error lines passed into and out of functions are just just clusters with a status boolean, an error code, and an error string, and are not "attached" to a particular function as you describe in your post. Most functions have an error in input and an error out output, and most functions will simply do nothing except pass through the error cluster if the error in status is True (to verify this for yourself, double click on a function such as a DAQmx Read or Write and look at the block diagram. If there is an error passed in, no read/write occurs). This helps prevent unwanted code from executing when an error does arise in your program. By wiring the error cluster from your other shared variables to your analog data variable, you're essentially telling LabVIEW that these functions are related and that your analog data variable depends requires that the other shared variables are functioning properly. The error wire is a great way to enforce the flow of your program, but you must always consider how it will affect other functions if an error does arise.
Anyways, it's great that you have things more or less working at the moment. Keep us all updated!

Issues with Shared Variables in Systems Running for Extended Periods of Time

I am designing a large SCADA system using LabVIEW DSC and cRIOs. My plan is to use shared variables to communicate the majority of the information across my network (much like "tags" in a normal SCADA system).
I'm wondering if anyone has experienced issues (connection failures, etc...) with shared variables running on systems for months (both real-time and windows based PCs) without the cRIO or PC being restarted/redeploying the variables. What is the stability of the Shared Variable Engine over extended periods of time?
Thank you for the input.
--CLD--
LV 6.1, 8.6.1, 2011 SP1, 2012 SP1

I have a system with 2 cRIO's each with Ethercat extension chassis. Each cRIO hosts ~100 NSV's and is running the scan engine at 40 Hz.
Each cRIO is coupled to a HMI that has front panel control bindings to NSV's hosted on the cRIO as well as a windows hosted mirror library (used for citadel db logging) that is also bound to the cRIO NSV library. The cRIO's have monay months of contiguous run time without reboot and I closely monitor cpu and memory usage and also rt performance metrics and will log faults if there are any such events. I also use NSV's for messaging from the HMI to the cRIO for such things as setting zero offset values and deploying configuration parameters. My overall findings are that the SV engine and the PSP are stable and efficient (especially NSV<->NSV and NSV<->HMI binding)

Problem with dsc shared shared variables and error 1950679023

I'm having trouble using shared variables on my laptop PC (with Windows XP) using Labview 8.2 and DSC. I've set up a simple project with one VI and one shared variable library. In the VI, I have a while loop that writes a number from a front panel control to the shared variable. Another loop running in parallel reads the shared variable and displays to an indicator on the front panel. The VI resides on my PC (no remote targets). This program executes just fine on my desk top PC; however I get the following error codes out of the shared variable nodes when I run the project and VI on my laptop for the write and read, respectively: ni_tagger_lv_Write 180121604 ni_tagger_lv_Read -1950679023 I've tried to manually deploy the shared variable library without success. The NI knowledge base and other entries on this forum suggested that the Windows firewall should be disabled for a quick fix, however, the firewall was already disabled on my lap top. I didn't see any entries regarding the 180121604 error code.
Any suggestions would be appreciated.

The problem has mysteriously gone away. For about the 10th time, I manually deployed the share variable library, and it started to work properly.

Problems with communication across a network using shared variables

I have two programs(projects) running on two different computers connected with a LAN. I am using LabVIEW 8.0, and the DSC-module. The program on one of the computers have measurements that I want to collect and show on the program running on the other computer on the network. I choose the indicator where I want to show the data, select ''Properties'', ''Data binding'', ''Shared Variable Engine (NI-PSP)'', ''Network Items'' and then browse for a Network...but the problem is that in my ''Network Neighborhood'' There is only one computer...and that is the one I am one...not the computer on my Network that I want to communicate with....
Have anyone any suggestions on how to solve this?
Kind regards Mari

Mari,
Check this link regarding trouble shooting network-published shared variables:
http://digital.ni.com/public.nsf/websearch/6E37AC5435E44F9F862570D2005FEF25?OpenDocument
This might be a firewall issue, so I would check that first.
Frode

Indicator bound to shared variable

Similar Messages

Maybe you are looking for