Shared Variables - Properties

Hello,
I have a couple of questions about properties of Shared Variables (SV). They can be configured either by using the dialog box (right-click on SV -> Properties), or programmatically via the "SharedVariableIO" property node. Have a look at the NI-Examples to see how SV can be created programmatically by using the DSC module.
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
Regards,
Dietrich

dietrich wrote:
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
You can't. The single-process shared variable is an old style LabVIEW global placed under the shared variable abstraction. There is currently no way to create those on the fly. Time-triggered also cannot be created programmatically. I confess I don't know enough about them to know the reason why.
dietrich wrote:
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
Network.On Scan = read/write hardware? - this allows you to programmatically control when you are reading from or writing to configured hardware.
Network.ConnectionType = connect to hardware even when no one is viewing me? - this has 2 choices, UpFront & OnDemand, UpFront means that the variable will be connected to hardware even when no one is connected to the variable. This is useful when you want to reserve hardware or when logging is enabled. OnDemand means that you disconnect from hardware whenever no one is reading the variable.
dietrich wrote:
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
I would advise against using any of these. National Instruments can change, or remove, those underlying files at any time as a result of modifications to the MVE. That could cause issues for any code using those sub-VIs.
Regards,
Robert

Similar Messages

In the shared variable properties box, when enabling aliasing, what is the difference between binding to a project variable vs. to a psp url

In the shared variable properties box, specifically with regard to a the target being an rt target, when enabling aliasing, what is the difference between binding to a project variable vs. to a psp url?

The difference is in the type of variable you are binding it to. A project variable is a variable that lives within the specific project in which it was created. A PSP URL is an address using the Publish-Subscribe Protocol (PSP). You can learn more about PSP URLs here: http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/using_datasocket_technology/#Specifyin...
PSP URLs will enable it to communicate between different machines and also between projects which may or may not be open. The project variable will exist within the project.
Julian R.
Applications Engineer
National Instruments

Where can I find the "Shared Variable Properties" VI to be used in my program for configuring SV remotely?

I was using the "configure Alarms" and "configure Logging" VIs to design two user interfaces to make use of these VIs when I came across a problem. In both VIs you can enable logging of alarms. So which one is valid? Which one has priority? Then I looked at the "Shared Variable Properties" built into the project explorer. Now I realize that I am spending all of this time redesigning this properties dialog (which also has two options of enabling logging of alarms (on the Alarms tab to the far right side as well as on the Logging tab). So now my question is, how do I access this "Shared Variable Properties" dialog through my program (Note: this would be on a different machine than where the shared variables are set up. The point is to configure shared variables remotely).
Thanks
Matt

Here is a VI I re-created and posted for all. I'm not sure why NI doesn't provide their VI to the developer. The only thing I can't figure out is that when reading in the "Ack Type" into a variable, it generates an error. It will work if you go into "project explorer" and right click on the library with the shared variable and "deploy" but eventually stops working. I have tried using the "undeploy library" and "deploy library" to see if this would be a work around but had no success.
Just pipe the path of the shared variable into the vi.
Mattk
Attachments:
Shared Variable Properties.vi ‏95 KB

Can't open/access Shared Variable Properties Dalog Box

I've just upgraded to LV 8.6 from 8.5. Now I can't open up the Shared Variable Properties Dialog Box. In the Project Explorer, I expand the shared variable library, select the shared variable, right-click on it to get the pop-up menu, select Properties, nothing happens. The same is true when I right-click on the shared variable library or My Computer and select New>>Variable.
On another computer that I upgraded to LV 8.6, I can do the same things and get the dialog box, albeit it looks different in 8.6 than it did in 8.5.
There were no errors reported in upgrading these computers. Any ideas as to what is wrong?

I've tried re-installing LV 8.6 from the DVDs sent to me. I get the following errors:
Error 1335. the cabinet file 'mib.cab' required for this installation is corrupt and cannot be used. This could indicate a network error , an error reading from the CD-ROM, or a problem with this package. - I responded with 'ignore'
The NI Assistant Framework LabVIEW Code Generator 8.5 installaion has failed with the following error.
Internal Error 2350.
Continue? - I responded with 'yes'
LabView installs but I still can't get access to the dialog box.

Shared Variable Properties and DSC

Is there a way to assign engineering units to a shared variable as a
configuration parameter? This should be on the "Scaling" page of
the shared variable properties. It seems this is a logical and
convenient place to track units. Assigning units programmatically
using the Scaling:Units property is awkward (to say the least).
On similar lines, why aren't shared variable properties automatically
saved to the DSC historical database? Every trace should have a
set of information that exposes ALL the shared variable properties that
created it. Take something like engineering units for
example: then you would know what kind of historical trace you
are looking at! This seems so basic I can't imagine why it was
missed.
Unless I missed something -- please enlighten me.
Regards,
David Moerman
TruView Technology Integration Ltd.

Hello David,
You are correct in that the units property is not exposed on the
Scaling page of hte Shared Variable properties dialog, and it sounds
like you are already well aware of the existing method to access this
property through the property node interface. As you have also
discovered, the Citadel database that we use with DSC does not have a
built-in provision for storing metadata about the shared variable from
which a trace originates. You can emulate this with, for example, an
array of strings which is also logged to the database, with each string
containing the metadata for a particular trace.
Since it seems like having these features would benefit you, I
encourage you to let our DSC development group know your needs by
filling out product feedback, accessible on our site at
http://www.ni.com/contact . This will send a feature request
directly to the appropriate R & D group, who reads and evaluates
every suggestion made. This is your most direct way to let us know
what features would best meet your needs.
Cheers,
Matt Pollock
National Instruments

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!

Weird delay reading shared variables

Hello,
I'm working on a project were I'm monitoring some prodution lines. I'm using DSC module's OPC server to connect to PLCs on the production line and I've created bound variables on my labview project of the PLC's tags.
On my project I have one main VI were I show information about the production lines and were I can access several subVIs were I show other information about those lines. Then I have a VI that is running in background were I'm reading about 50 shared variables from the PLC and where I'm registering some data in a MySQL database, datalogging data on the Citadel database and registering alarms.
The problem I'm having is that on the VI that runs in background I noticed a delay reading the variables that are reading containers weights from the production line. It seems that all the other shared variables don't suffer any delay, only the weight variables start having some delay when the values are increasing. It also seems like that, when I'm only running that VI alone, without running the main VI, there isn't any kind of delay. I'm reading the shared variables as shared variable nodes.
Can anybody help me understand what's happening and how can I fix this delay? The VI that runs in background is time critical and a weird delay like that messes up my data.
Solved!
Go to Solution.

Hi Mateus23,
The shared variable has various buffering capabilites, including integration with the Real-Time FIFO feature in LabVIEW Real-Time.
I guess that the buffering settings are causing the unexpected behavior.
Check these resources:
Buffered Network-Published Shared Variables (whitepaper)
Shared Variables Properties Dialog
- Network Page
- Real-Time FIFO Page
~~

Shared variable does not work in executable

In editor mode, the shared variables update fine. When I build the executable, the shared variables no longer work.
See attachment.
Attachments:
TestCitadel.vi ‏30 KB

I found this note in the LV2010 help, I wonder if this could be related to your problem...
Note You can use scaling only for network-published
shared variables, I/O variables, or I/O aliases. When the shared
variable you want to scale is a network-published shared variable, it
must have a data source. Configure a network-published shared variable
to have a data source by placing a checkmark in the Enable Aliasing checkbox on the Variable page of the Shared Variable Properties dialog box.

Shared Variable communication (network publiched )

Hi all ,
The whole day I have been banging my head with Shared variable communication between RT Host and host computer :
I essentially attempted to pass an array from the RT host to the Host computer .For this purpose I used a Network published shared variable of type Array U64 . I utilized this link to help me understand usign shared variable communication
http://www.ni.com/white-paper/4679/en ..
I also enabled RT FIFO .Now in the mentioned link this the information given about using single element FIFO or Multi element FIFO
'' By enabling the real-time FIFO, you can select between two slightly different types of FIFO-enabled variables: the single-element and the multielement buffer. One distinction between these two types of buffers is that the single-element FIFO does not report warnings on overflow or underflow conditions. A second distinction is the value that LabVIEW returns when multiple readers read an empty buffer. Multiple readers of the single-element FIFO receive the same value, and the single-element FIFO returns the same value until a writer writes to that variable again. Multiple readers of an empty multielement FIFO each get the last value that they read from the buffer or the default value for the data type of the variable if they have not read from the variable before.''
I had read the above content a 100 times but still I am not able to get a clear picture of the difference and when to use which option .So I decided to throw away the text and attempted to try somethign out for myself .
I had a loop in the RT host that writes different 3 element arrays into the ''network published shared variable '' . Now when I use the multi element option with '' number of arrays as - 2 '' I am able to read the arrays seperates one by one in the host computer ( as we can read a general queue).
Now when I used the single element option for the RT FIFO with un editable 1 array option ,only the last written array into the ''network published shared variable '' gets read in the host computer .
This sounds absolutely silly as if this is the case then what is the purpose of setting the ''buffer''.For testing purposes I had set the buffer as 5 arrays .
In fact I have only one writer ( writing in loop in the RT Host ) and one reader ( again reading in loop in the Host computer ).So I am not even sure if I require The RT FIFO option for the network published shared variable .
I apologise for the long message but I have reached the limits of running in circles waiting to bang somewhere
I know I am doing a silly mistake somewher or I am probably missing a simple obvious trick but dont know what it is ..
I request for some clarity .. In fact I had posted a little while earlier today as well .... link - http://forums.ni.com/t5/LabVIEW/RT-Host-to-Host-computer-communication/td-p/2348130 )
any help would be appreciated
Cheers
me
Solved!
Go to Solution.

Hi,
I think the difference between both types is clearer in the LabVIEW help :
Enabling the Real-Time FIFO
You can enable the real-time FIFO of a shared variable from the Real-Time FIFO page of the Shared Variable Properties dialog box. Place a checkmark in the Enable Real-Time FIFO checkbox to deterministically share data using single element or multi-element FIFOs.
Single Element FIFO
A single-element FIFO shares the most recent data value. The shared variable overwrites the data value when it receives a new data value. Use this option when you need only the most recent value. Configure the size of the array elements or the size of the waveform for the FIFO buffer if you select an array or waveform data type.
Multi-Element FIFO
A multi-element FIFO buffers the values shared by the shared variable. You can configure the size and the elements of the FIFO buffer to match the settings from the Use Buffering section of the Variable page, or you can configure a custom size for the FIFO and the FIFO elements.
Note For both single-element and multi-element FIFOs, if the variable contains array or waveform data, you must configure the size of the FIFO elements equal to the size of the data you want to share. If both the network buffer and the RT FIFO are enabled, the network buffer must be at least as large as one FIFO element. Sharing data smaller or larger than the length you specify causes a memory allocation that affects determinism.
Note Waveforms contain variable-size variant elements that are not compatible with the Real-Time FIFO. Therefore, if you enable the Real-Time FIFO on a shared variable that contains waveform data, the variant element of the waveform data does not transfer.
http://zone.ni.com/reference/en-XX/help/370622K-01/lvrtconcepts/rt_projectvariable/#Single_Element_F...
'Hope it helps
Aurelie

Shared variables not working on PC

Can anyone tell from the attached screen shot, why my one shared variable is not working with the labview application I'm running on my PC. I set the variable to 48 (I thought), and yet in the NI Distributed System Manager the value doesn't changed.
Solved!
Go to Solution.
Attachments:
shared_var_not_working.JPG ‏255 KB

Its not likely to be a deadband problem if you haven't touched the settings. I would check it out just in case though. In the project window, right click on the shared variable>>properties and select Update Deadband. See attached image. If it's not this, I shall have to think some more about what else could cause this.
As for ensuring it works when setting it from DSM...from your screenshot you appear to have a VI that writes to the SV. Change the code ore create a new VI so that it reads the SV and then double check that if you change the value in DSM, the VI also reads back the updated value. It may be that the number changes in DSM but does not update the SV in the VI - this would indicate a problem with the shared variable engine or the deployed variable library...Reboot PC and retry... if the problem persists let me know or attach the SV library!
Regards,
Dave
Senior Software Engineer
www.Adansor.com
Attachments:
SV_deadband.PNG ‏8 KB

How can I change my Shared Variable from "I/O Variable" to "Network Published"

Hello,
I have an application that is using a series of NI wireless sensor nodes. I am trying to programmatically access shared variables. Right now the only method I have found to access the data from the shared variables is datasocket read. I am on labview 8.6.1 so I don't have as many shared variable options as newer versions of labview. I do think there is a way to access properties for the shared variables, but I'm not sure about how to change the nodes channel properties to "Network-Published". Do i need to remove the node from the project and bring it back in with the new settings? When i have done this in the past i have run into naming conflicts. I would appreciate any ligtht that can be shed on this issue that will help me create a vi that operates quicker.

Any Shared Variable that has “I/O Variable” for its Variable Type (see screenshot of the Shared Variable Properties below) refers to any channel of data (such as Analog Input or Output or Digital Input or Output) directly from a module channel. In other words, this is how you directly get the raw reading straight from (or to!) a specific module channel.
You cannot edit the Variable Type to Network Published. You can check “Enable Network Publishing” as above, which allows this Variable to be accessed from a VI on a Host VI. You could also create a separate Network-Published Shared Variable which you can wire directly to the I/O Variable on the Target VI if you wish.
Best,
Ryan C.
Applications Engineer
National Instruments

Network Shared Variable Description

Hi,
I've created alot of Network Shared Variables through Project Explorer...and i have also added a description for each one in the shared variable properties screen
Could someone please tell me how i can get access to the description through LabVIEW?
Many thanks
Mike

Hi attached is a sample of code in which i am viewing a value and also its description.
Ideally id just like to have the channel name once and the description and value be taken off that, rather than if i ever change it , then have to change the input to the description and also the variable displaying the value. Hope that makes sense
Regards
Mike
Attachments:
opctest3Kep for forum.vi ‏19 KB

Enable shared variable buffer

Dear all,
I'm writing on a program to create shared variables programmatically. I use the examples available in labview and DSC 8.0 as reference. I'm able to create and set the different properties such as scaling, alarms, inital value etc for the shared variable(s). However, when i wire a boolean "true" to " enable buffering", it doesnt seems to work. I checked the shared variable created in the shared variable engine, the variable is created but the buffering cant be enabled programmatically. Can anyone guide me what's the fault? thanks.

Hi,
The VI worked without any problem though I had to change the shared variable name. One thing to note about changing the properties of shared variables programmatically using the shared variable I/O is that it only affects the deployed shared variables and not the actual library file. In essence, these changes are not saved in the library. So the shared variable properties window will not reflect the current status of the "Network.UseBuffering" option. To verify that the "use buffering" is enabled, place another "Network.UseBuffering" property node on the block diagram and read the current state from it.
Attached is a modified version of the VI with the current status of the "Network.UseBuffering" property for the deployed shared variable.
Tunde
Message Edited by Tunde A on 03-05-2007 12:34 PM
Attachments:
Modified_buffering_error.vi ‏10 KB

Dsc shared variable property are saved to library?

Hi,
I would like to be sure to know if the shared variable properties like "alarm level" and "description" are saved to the library directly?
If not, where? database?
Also can we not add table to the dsc ms sql express database? (the one for alarms and events)
Thanks
Patrick
Message Edited by paubine on 09-04-2009 08:23 AM

The properties of the shared variables like alarm and description do get saved to the library. As for your second questions about a table in ms sql, can you tell me more about this? Are you using the LabVIEW DSC VIs to do this, if so provide a screen shot or your code or a good description. Tell me exactly what is going wrong, what behavior you expect and what you are seeing.
Thanks,
Anna K.
National Instruments

Why string arrays not allow in shared variables?

I'm changing a program to replace some global variables with shared variables. The need for an executable is the reason the globals are being replaced with SV's. At least one of the variables is a 2 diminsion array of strings. Under the 'data type' drop down list on the shared variable properties there is no option for an array of strings among the 28 posibilities. Any way this can be accomplished? I'm using version 8.0
thanks, Mike

Nick, I am attempting your solution. I upgraded to 8.5, created a custom control as a 2 diminsional array and made it a shared variable. it works fine in uncompiled mode but when the programs are made executables the array info is not passed. Now I have to say I find the whole compile process with Labview pretty confusing so I'm guessing I'm doing something wrong in that procedure or I am simply misunderstanding this whole data passing concept on some fundemental level. . I have attempted several different compile property setting under the "Source Files" page. Both the write and read programs are in one project along with the custom control and the shared variable. I compile two applications using the write and read vi's as startup files and have included the custom control and the shared variable in the "always included" area. I've tried including the last two files or not including them in the compile and it makes no difference. Setting the variable as 'single process or 'network published' makes no difference either.
Attachments:
controlrw.lvproj ‏9 KB

Shared Variables - Properties

Similar Messages

Maybe you are looking for