Shared Variable event handling--spurious events

This is more of a nuisance than anything:
Using the DSC module to register for shared variable events, the event structure always fires once for each variable registered for. For example, if I register for the shared variables "Var1" and "Var2", upon entering the event structure [in a loop], I'll immediately see two events [one for Var1 and one for Var2] even if the values for Var1 and Var2 haven't changed.
I originally figured that it's intentional--it appears to be impossible to use SV events without this "feature"--except it doesn't happen in "highlight execution" mode, which I find puzzling.
Why does this exist, and is there some magic way to disable it? Or is it a bug? Anybody who has ever used SV events undoubtedly has some way of dealing with this. Right now I just burn off the first N events, where N is the number of shared variables I'm registered for. But that's extra diagram junk and it really shouldn't be necessary.
Solved!
Go to Solution.

Kyle:
Here's a sample project with two SVs and an event handler VI. SV1 has an initial value but SV2 doesn't.The array displayed in the front panel should be empty after running--the SV's are not written to anywhere. I get two entires--one from each event--when I run the VI.
I noticed some new behavior when I put this together. In this example I use the timeout condition to terminate the loop. There is a timeout value around 110ms that defines the cutoff for this behavior--but the value is not consistent. With timeout values ~110 and below, I get no spurious events. But I DO get them for any timeout value of above that. So perhaps this issue is invisible to anybody who is generating events faster than ~10Hz. This may explain why I've been having inconsistent behavior when using the execution trace.
[edit: reposted as archive]
Attachments:
SVtestProj.zip ‏16 KB

Similar Messages

Variant in Variant of a shared variable

Hello,
I am trying to read some Tags in a Siemens S7-1200 PLC over NI OPC server. I can read them in NI-DSM (Distributed System Manager). However, I can not read or write them in Labview. I generated a shared variable event loop which will run when a variable changes. I get always Variant in Variant as Value which is not correct as I want to convert it to a data type. (See attached image)
How can I correct it?

It is quite common for a function/property/method to return a value as a variant if the data type is unknown at runtime (e.g. getting a control value for a generic control).
Is your shared variable a variant? If so - the event data converts that to a variant (even though it is already a variant) because you might have registered for events for different shared variables that might be of different data types so it returns as a variant so you can convert it to the correct type (based on the 'data type' event data item).

Distributed application: Networked Shared Variables, Named Services (Raw TCP/IP) or Other?

Happy New Year NI forums!
I am working on a project involving mobile interacting robots. In the future it is likely the application's components may need to run on different PCs (Targets). Note: at this point in time all the components are seperate but all running on the localhost machine. Thinking towards the future I want to pick the 'best' architecture to allow all these components (VIs performing various functions) in multiple locations. For example, several VIs on the Robots, VIs on serveral PCs.
I am currently aware of using Server/Client TCP/IP using named services. My mock up works well, but is it time efficient (my time coding) I wonder.. ?
Whereas I am aware of networked shared variables which handle connections and all the parsing for the underlying tcp/ip communication. But will this be difficult the manage? I am unsure if I can associate shared variables with a VI similar to named services. I suppose I could pro grammatically create the variable upon initialization of the server component - and the client could just search the list of avaiaible variables to connect too. Downside this would require DSC module.
As you can see, I am rather unsure. Any advice would be great!
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!

Hi Jason,
Thanks for your reply. I hope your enjoying NI UK as much as I did.. fun times!
I have seen the link you posted a few times before. But today, I took a better look at it.
My issue is I need several multi-client severs, i.e. many servers which allow multiple clients to connect to them.
Now the STM does have an example of this - STM mutli-client Example - Server.vi (used with the STM mutli-client.vi)
However, when a make copies of these code (to have my second server) - it refuses to run. As in , it just stops itself.
I DID change the port number, on the lister aspect of the server code. But I Am unsure what else I would need to change to get this setup to work?
One thought I had was, the FIFOs all having the same name - this probably isn't a good idea between servers.
Any suggestions would be grateful!
*please could you provide me email support
Kind Regards,
James Hillman
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

How to read shared variables inside event structure ?

Hi,
I have a problem that my shared variables do not update inside event structure. The program(s) I am trying to get working is seen in the attached screenshot. It works as follows:
0. I start the vi that is unsquared.
1. I write a string to a shared variable using vi in red square. I make sure that its updated using write-wait-read.
2. I run the other vi (blue square), this changes the boolean shared variable.
The unsquared vi has been running the whole time, it has event structure bind to boolean shared variable change (the one in blue vi). After I have runned the blue vi, the unsquared vi should change the indicator values to match the ones in red vi. However I have to start the blue vi multiple times to get it to change, sometimes even 6 times.
Also, when I change the value in red vi to a third value and start blue vi multiple times, the unsquared vi shows all the variables. I.e. I put "cat" to red then start red, put "mouse" to red then start red,... and then start clicking blue... Unsqured shows cat, mouse,..., dog (dog is the default).
How can I force the shared variable to update inside event sructure. I want the current value of the variable, not some historical values.
Attachments:
Screenshot-5.png ‏108 KB

Found the buffering... disabling it solved the problem... thanks.
FYI, there is another solution that I just found out... attached. Adding timeout to the event structure and the variable read outside the event structure... This makes the shared variable strings (one that is read outside and the otherone that is read inside) different.
Could someone explain why the variables are in different state even if they are used in the same place and looped with 10ms intervals?
Juha
Attachments:
Screenshot-6.png ‏110 KB

Is it possible to generate a user event when shared variable value change on RT target?

Hi,
    I wonder if it is possible to generate a user event when a network published shared variable value change?
    Thanks a lot!
    Regards,
    Tom

Tom,
I understand not wanting to waster resources on polling but I am not aware that LabVIEW can automatically generate an event on a SV change.
Maybe a better solution...
You could implement lower level TCP communication (i.e. have a look at STM - simple messaging protocol) for passing data betweeen RT and PC (instead of using a SV). You could send a generic command (boolean trigger maybe?) from your RT system when the value of whatever it is the SV is storing has changed. You can avoid polling on the non-RT system this way.
Dan

Does OPC UA Shared Variable Server support Alarm&Event and historical access?

OPC UA Shared Variable Server is a sample code and resides at https://decibel.ni.com/content/docs/DOC-25602
It seems to support DSC <-> OPC-UA tag synchronization.
But does it support alarm&event and historical access?
I tried to open it with LabVIEW 2012, but lots of VIs were missing in the code, and I am not familiar with DSC and OPC-UA.

Hi iCat,
From your post on the example itself, a colleague of mine responded with: "This uses the OPC UA server included in DSC 2011 SP1 which does not include direct support for Alarms and Events. However you could use this idea to synchronize to shared variables on a Windows host which could have those abilities enabled."
So it looks like it doesn't directly do this.
Matt S.
Industrial Communications Product Support Engineer
National Instruments

Why shared variable generates events when I write constant value?

Hello all,
I'm using LV 8.5 with DSC packet.
I modified "DSC Events Demo".vi and made a test. I noticed that only variable which work okay is double typed. Why this code generate events all the time when I write constant values to shared variables? Double is okay, but string and boolean types not work okay. Is there any other people how have noticed same symption?
Attachments:
modified_dsc_event_demo1.zip ‏391 KB

You may get an initial event on startup which is normal. Also make sure that you have not enabled timestamp change events.

DSC - Event triggering for Single Process Shared Variables

Hello,
I understand how to set up a Value Change Notification for Network Published Shared Variables so that an event will trigger when that particular Shared Variable changes. However, I can't figure out how to do the same for Single Process Shared Variables. Is this even possible? Can someone shine a light on this, please?
Thanks in advance.
- James Pham
Solved!
Go to Solution.

VRspace4,
Hello! It is not possible to enable alarming for Single Process Shared Variables. A workaround to setup a Value Change Notification would be to create a network shared variable that reads from your Single Process Variable, but at that point in time it might be worth just replacing your variable with a networked shared variable.
Ben Sisney
FlexRIO V&V 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.

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!

Serializing read/write operations of network-published shared variables

Hi all,
I'm developing a distributed application (PC + CompactRIO), and using shared variables (SVs) for inter-device communication. Here's my journey so far:
Intended procedure
PC parses file
PC writes processed file data (custom cluster, large) into the 1st SV
PC writes a "grab data" signal/command (enum) into the 2nd SV
cRIO polls the 2nd SV
cRIO sees the command, then reacts by reading the 1st SV
Steps #2 and #3 were sequenced, using error wires.
Unexpected results
Even after the command is transmitted and the cRIO sees it, the cRIO could not read the data (which I wrote BEFORE the command) -- LabVIEW reported that the buffer was empty.
The operation succeeded when I placed a wait (5 seconds) between steps #2 and #3.
Questions
What am I doing wrong, and how do I achieve my desired outcome?
Is SV I/O asynchronous by design?
Is it possible to use event-driven programming to handle SV access? (i.e. does LabVIEW signal when the new SV value has propagated across the network?)

BillMe wrote:
Why do you have to "notify" the other end that data is available? The subscriber can simply sit in a loop doing a timed read just as if using a queue or notifier IPC. If it doesn't time out, you got new data. If it does time out, do some other processing if needed and then loop back for another timed read.
My sytem architecture is command-driven -- the cRIO listens for instructions from the PC interface (sent as an enum via one SV), and performs tasks (motor control) in response. One of the commands (the one described in this thread) happens to be "download a new motion profile from the PC, by reading the other SV". Given that the cRIO is already polling the command channel, I felt that there's no need to also poll the data channel (especially since the "download" command is issued very infrequenty). Plus, I thought that polling two channels would increase the chances of race conditions or illegal state transitions, particularly if the app is developed over a long term.
I am also new to LabVIEW, so my current programming style will heavily reflect my C++/Qt background while I get a feel for LabVIEW's strengths and weaknesses -- Qt is a heavily event-driven framework (even for networking!), where polling often means you're doing something wrong.
Still, thank you for pointing out that I can use timeouts to determine if new data has arrived -- my subscriber current writes a null command back into the SV when it has consumed the command, but you showed me that I don't have to.

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.

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 clock is consistently inconsistent

From the annals of the weird:
I noticed a while back that the DSM displays a different time than my system clock when I manually change a NSV value. I didn't think much of this, but then I noticed that it is not just wrong but inconsistently wrong. Here's the time difference, in seconds, between the system clock and the SVE timestamp for a dozen NSV value changes [the SVE clock always lags behind]:
35, 14, 1, 18, 29, 2, 21, 24, 14, 17, 29, 20
I checked these numbers in two different ways: (1) with the "Time stamp" event property node with NSV events using the DSC module and (2) manually changing values with the DSM and comparing to the displayed Windows time.
What's the deal? The timestamp is completely useless to me with a seemingly random offset from the system time; it's by far the best way to deal with this little bit of unfortunate SV event handling behavior. Filtering event timestamps against system time is fairly standard procedure and I can't see it being useful with this going on.
This should be trivial to reproduce--does anybody else see this? If so, is there an explaination--or better, a fix?
[I should note that I have seen this but I'm running Intel core 2 duo, not an AMD multicore. I'm using LV and DSC 2010 SP1]

You may have to set up the Time Synchronization Services on the computer with the DSM running.
In LabVIEW Help, look for Shared Variable Engine Page (Options Dialog Box)
In DSM Help, look for Shared Variable Engine Time Server Configuration Box
I don't know if both are necessary but I made all the computers on my system point at the same time server. The time server is configured as an Authoritative Time Server under Windows. It is in turn slaved to our DSN server which follows a Public NTP server.
JohnCS

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)

Shared Variable event handling--spurious events

Similar Messages

Maybe you are looking for