OPC Shared variables supported types

HI,
What are the supported types for shared variables when using DSTP protocol (OPC server) ?
Only Double, Boolean, U8 and strings seem to be supported.
Can I have some specifications about this ?
Thank you,

Hi,
I can create shared variables of any types but only Double, Boolean, U8 and strings will be seen by OPC clients.
Kerv

Similar Messages

LVE / OPC / Shared Variable / LV 8.0 & 8.2

I try to communicate with an OPC Client having problems...
There are two ways to do that:
First way:
Simply create a shared variable in my project file which I can use per drag & drop after deploying it. The shared variable uses the Labview Variable Engine (LVE) and the NI-PS-Protocol. If I have read it correctly, these shared variables can also be OPC items. And yes, it works but limited.
Second way:
Each control / indicator has a data binding tab under properties. There I can select data socket and pass manually the OPC protocoll reference (e.g. opc://localhost/National Instruments.Variable Engine/\\.\test\SGL Array) which is not very comfortable but it works unlimited.
Is problem is that the second way works fine for Labview 8.0 and 8.2 but the first way works in a curios manner on Labview 8.0.
That means: In labview 8.0 I can use the shared variables as OPC items without problems but only for non-array data types. Each array type (SGL,DBL, Waveform,...) does not work. We used the shared variables as simple OPC items a long time and now intented to add an array realizing that it does not work. Than someone told us to install DSC Modul wich adds the OPC functionallity to LabView, seeming to solve the problem.
The remaining fact is that LabView 8.2 has no need for the addionally OPC functionally of the DSC Modul. Way 1 and 2 works without problems in 8.2.
Ok, we have an unlimited license of using LabView in all versions and with all toolkits. But we want to use LabView 8.0, because our vis are programmed there and we do not to intend and vesion upgrade.
If there is no solution here, we can use way to, but I am really interested, why shared variable arrays are not supporting OPC compatibility while non-array data types do.
THX for an answer, best regards from Berlin

Please refer to that thread http://forums.ni.com/ni/board/message?board.id=170&message.id=76313&view=by_date_ascending&page=1 for further information.

Dsc opc shared variables yields Server Failure

I've been struggling with the transition from DSC 7.1 to 8+ ever since the release of version 8. I use the Allen Bradley OPC server supplied with the DSC module (Industrial Automation OPC Servers v 5.1) to communicate with a PLC 5/30 via Ethernet, or at least I did when I was using 7.1.
Prior to today I always failed to get the shared variables that were bound to addresses in the OPC server to deploy, usually getting an error number that started with -19. However today I finally got it to deploy by keeping the I/O server and the shared variables in separate libraries within my project. Now that they deploy I find that I am unable to monitor them. I keep getting a Server Failure. I have browsed the forums here heavily, and the documentation all relates to remote OPC, which is not what I'm doing here (OPC client and server are on the same machine). I tried changing the login account for the Variable Engine service anyway, but that doesn't help, so I put it back.
I have had some luck simply binding my front panel objects to the OPC server addresses using Datasockets, so it appears that my OPC server is working. However, Datasockets is not a viable option for me because there are times when my project needs to write to a large number of addresses in the PLC sequentially, which never works over datasockets (in my experience).
We have continued to work in version 7.1 because of the challenges of moving to 8+, but since we can no longer purchase DSC runtime licenses for version 7.1 in order to deploy, it seems that we MUST move forward to 8+ or abandon LabVIEW altogether (which is certainly an option).
For clarification, I am now working with version 8.2 (but I've been fighting with it since 8.0 without much success). If anybody out there can think of a critical step that I might have missed that might cause this, or if there is a known solution, I could really use (and would greatly appreciate) the help. Thanks!

Nobody out there seems to have any answers for this, so I kept pounding on it (and pulling my hair out). In the end I finally succeeded in getting one of my old 7.1 DSC projects to run on 8.2. Here's what I did:
1. I begin with a fresh installation of Windows. I tested it with both 2000 and XP Pro. Vista RC1 will absolutely NOT work!
2. Install LabVIEW 8.2, DSC 8.2, and just the OPC server that I need from the IA OPC CD (in my case the Allen Bradley server)
3. Open the IA OPC server editor, and create a new file with an object in it for my PLC (PLC 5/30, Ethernet in my case)
4. Save, set it as the startup file
5. Run LabVIEW, create an empty project
6. Add an IO server
7. Launch Multi Variable Editor, load project file created in step 6, and bind one variable to PLC address
8. Save all. Uncheck auto deploy for the library, and deploy all.
9. Launch variable monitor, browse to new variable, double click to monitor.
10. This will ALWAYS fail with "server failure". Don't worry, just exit completely out of LabVIEW.
11. Stop the Variable Engine service.
12. Run OPC server editor again, and load up the lpd file from your old project. Modify if needed, save, and set as startup
13. Start the Variable Engine service again.
14. Launch LabVIEW
15. Create a new empty project (I created mine in the same directory as my old 7.1 project resided)
16. Add an IO server, and uncheck auto deploy for its library
17. Save all
18. Run Tools->DSC->Migrate->import scf
19. Convert your old SCF file
20. Add the new library to your project (it will be named LabVIEW)
21. Uncheck auto deploy for the "LabVIEW" library you just added
22. Right click on the "LabVIEW" library and do deploy all
23. Save, and open the variable monitor
24. Browse to a tag in the LabVIEW library, and double click
25. This time it will actually monitor the variable, with a status of "Good"
26. Now you can add your main front panel VI to your project, open it and run it
27. Version 8.2 will select the proper legacy tag read/write VI's, whereas 8.0 does not. The writes however do not work. Replace them with shared variable writes. The reads work fine.
28. The empty project that you created in step 5 is a throw away. It will never work anyway.
29. So far the only variables that I can get to work at all are the ones that I import from an scf file, which is a pain, but if I must create all my tags in 7.1 and import them into 8.2 I will (for now). I may try exporting to Excel and copying variables that work in order to get functional new variables, since binding them in the editor does not work.
I hope this helps anybody else out there struggling with moving to 8+ DSC. I saw a few posts with similar issues, but without ANY answers at all. It's a convoluted solution that doesn't make a lot of sense, but for me it is repeatable.

Shared variable data type: Can I choose an array of a custom typedef, without making the array itself a typedef?

Hi all,
I'd like to pass an array of a cluster across my network. My cluster is typedef'ed, but I'd like to avoid polluting my project with another redundant typedef.
Is it possible to use the shared variable's "From Custom Control..." option with an array, without saving the array as a new .ctl file?
Solved!
Go to Solution.

Ah, I didn't realize you were using shared variables. I thought you were just considering it as another option along with TCP/IP or UDP or something like that. In this case, you would have to create a second custom control. This control would be an array with teh typedef cluster in it. No need to make this new control itself a typedef though. Sorry, I know you were hoping for a different answer. I doubt one file will really "clutter" your project though
CLA, LabVIEW Versions 2010-2013

Shared Variables should support LVOOP as a data type

Almost all LabVIEW data types can currently be sent through a shared variable without any hassle. The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable. This causes a problem for anyone who wishes to send objects across a network. They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication. The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

There has been some debate (both within NI and with customers) about whether or not the flattening/unflattening solution is actually desirable. After all, if NI made the shared variable support classes, to do the writing to the variable, the object would be flattened to a string and then unflattened when the variable is read. In other words, having the shared variable support classes does not actually remove any work that the program has to do, so having the shared variable do this behind the scenes is just syntactic sugar. The negatives crop up with the issues that Phillip raised -- suddenly the shared varible is reporting a number of errors that it did not support previously, whereas by separating the (un)flattening into a separate node, it is easier to tell where an error is arising -- was it a failure to read a shared variable or was it a failure to unflatten the data therein? By keeping the shared variable ignorant of such complex data types, it is easier to swap out the communication mechanism used -- shared variables might get support for LV classes, but TCP/IP prims might not, or whatever other communication protocol comes along in the future (i.e., the network stream primitives that are brand new in LabVIEW 2010 -- effectively queues that are usable over the network).
Users may choose to create a custom string format for objects, one that can be unflattened by any system that uses the shared variable -- including CVI and MeasStudio. Having shared variables support classes directly does not get in the way of this, but consideration of exactly what private fields actually need to be exposed in that very global global variable might be encouraged if users are consciously aware of the serialization taking place.
I'm not pro or con this feature at this point... this post is merely to document debate I've heard about any intermachine communications protocol handling LV classes directly.

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

Data Logging a programmatically created shared variable of cluster or array datatype into citadel DB

Hi,
Is there a way to log a programmatically created shared variable of cluster or array datatype into citadel DB?
I have attempted to programmatically create a shared variable of type 'double' and was able to successfully log the same into Citadel DB. In the attachment, Please refer to the attached project SV_TC.lvproj and specifically to SV_W.vi for the code that i have used (W.png file shows the dB in MAX and shared variable in NI Distributed System Manager)
However when i tried the same approach to create a shared variable 'array of double', i noticed that traces are not getting created and hence data logging isn't happening into the Citadel DB. I was however able to write and read the shared variable array without issues. The same is true with cluster datatype also. Please refer to SN_NW.vi for the code that i have used - only difference from SV_W.vi is that i have tried to create a shared variable of type 'array of double'
One observation is that if i create an 'array of double' or cluster in a shared variable library using the project explorer and deploy, i could see that these being logged into Citadel DB.
Hence i want to understand what could be done to achieve the same programmatically? Could you please advice?
Regards,
Sridhar
Attachments:
SV_TC.zip ‏3925 KB

Why is the transaction happening over remote?
Because we need the information to be on our database immediately when they submit it.
I don't know anything about streams or replication.....
The web database is run by the company that hosts our web site. We use PL/SQL to show the pages and output the html. It fetches the data the customer is requesting from our database, but I'm struggling to get the best way to insert into our database from there.

Shared Variable

Hello all:
I developer a VI with OPC Shared Variable . It run good in my developer PC.
Then package it into setup programme， intall it to another new PC.
Run vi.exe. When deploying shared variable, i got an error.
my_opc.lvlib\\127.0.0.1\my_opc deployment failed(error: -1967362042, os and network serviceshex ox 8abc7006)
Attachments:
11223.JPG ‏33 KB

Hi,
This url may help you:
http://digital.ni.com/public.nsf/allkb/1F45A4298B976F4A86257168006EA0C3
Then, when you use SV communication, you have to check :
- the network settings of the PC,
- the runtime Labview or a development Labview installed on all PC.
I hope that it has solved the problem.
Best regards.
R. Kaszubiak

Can not read shared variable on cRIO, error -1950678968 nitaglv

Hardware setup:
Laptop
Laptop connected via USB to a frammer garber.
Laptop IP: 192.168.0.2
NI vision calculating a diameter and setting a network varaible
cRIO
cRIO connected to the laptop
cRIO IP: 192.168.0.1
Project has the shared variable in the cRIO library
NI vision writes to the variable on the cRIO. I can see the variable properly updating in system manager on the cRIO. I can also run a VI in my computer that shows the variable properly updating. But...... When I read the variable with a VI running on the cRIO, I get the folowing error and the variable never updates:
Error -1950678968 occurred at Shared Variable in Main.vi
Possible reason(s):
LabVIEW: Failed to load nitaglv, which is required for Network-Published Shared Variables.
This error or warning occurred while reading the following Shared Variable:
\\NI-cRIO-OASIS\cRIOVariableLib\BubbleDiameterFromVision
\\192.168.0.1\cRIOVariableLib\BubbleDiameterFromVision
(I do not get any errors at deloyment)
So everything (NI Vision, a VI deployed on the laptop, NI Distributed System Manager) can see the variable on the cRIO being updated by the NI Vision.... Except for a VI running on the cRIO.
I have verified that I have Network Variable Engine and Variable Client Support for RT installed on the cRIO. I have tried reinstalling all s/w on the cRIO. Tried rebooting all. And talked in a nice, positive, reassuring voice to the chassis.

Hi!
I just had the same issue with my cRIO 9073 using NI RIO 3.6.0.
The problem is not caused by a corrupted project, but the improper installation of the OS on the target. There is nothing you can do using the SW installation wizard in MAX, as it does not matter if you intall a full RIO SW, minimal or custom.
You have to install the full install or a custom one with Shared Variable support. Then you have to FTP to the cRIO, and manually edit the "ni-rt.ini" file located in the root of the controller.
Make sure you have a line in the "[MODULE VERSIONS]" section which shows the version of the nitaglv.out file. (The problem is caused because this dll is not loaded when you try to access a SV) Mine looks like nitaglv.out=6.3
Then you have to insert "nitaglv.out;" without quotes to the [LVRT] section's StartupDLLs key's value. I did it after the taggerrt.out name. So my key entry now looks like this:
[LVRT]
StartupDLLs=nisysapirpc.out;NiViSrvr.out;NiRioRpc.out;taggerrt.out;nitaglv.out;sysstatepublisher.out;
memoryChecking=False
LABVIEWRTDir=/c/ni-rt/system
PATH=/c/ni-rt/system/;/c/ni-rt/;
CDIntervalTicks=55
WebServer.Enabled=FALSE
RTTarget.VIPath=/c/ni-rt/startup
RTTarget.IPAccess=+*
RTEnetRcvMode=2
RTCPULoadMonitoringEnabled=True
RTTarget.ApplicationPath=/c/ni-rt/startup/startup.rtexe
server.tcp.access="+*"
RTTarget.LaunchAppAtBoot=True
RTTarget.EnableFileSharing=True
server.tcp.serviceName="Main Application Instance/VI Server"
After you are done with the editing, you have to save the file, and overwrite the original one. You have to reboot the controller for the modification to take effect.
After this you will be able to host your variables on the cRIO and also read/write them from the application running on that same target.
I hope this will help for you too.
Regards,
Peter

Shared Variable does not update when typedef is changed

I have a shared variable of type custom control (typedef made up of a cluster). When I chang the typedef, e.g. the name or type of one of the fields in the cluster, and then save it, the shared variable does not update to reflect this change. That is, if I place the shared variable on my block diagram and do a "UNBUNDLE BY NAME" on the output, I see the old fields. I have to go back to the properties of the shared variable, change its data type, apply it, then go back and change it back to my custom control.
Anyone else seen this behaviour? Anyone know how to get the shared variable to update without going through this procedure?
Bill
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

I guess I should have included this information:
LabVIEW 8.2.1 using Project Explorer.
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

Labview 8.2 can't write shared variable

Hi!
I developed LV 8.2 program using shared variable (network published) variant type. After extension of variable the vi charased after writing value in shared variable. If i changed shared variable from network published to single proces type the vi working OK.
Attachments:
problem.jpg ‏23 KB

Hello,
I have created a network published shared variable of type variant, and successfully written to and read from it. Can you also post a snipet of your code which reproduces the problem?
General things to try in case include:
1. undeploy and redeploy the shared variable.
2. repair your LabVIEW installation - this will repair the variable engine, and I know of at least one case where this helped after it was corrupted.
I hope this helps!
Best Regards,
JLS
Best,
JLS
Sixclear

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

Error connecting to shared variable OPC item

I have a DSC application that has a bunch of shared variables. Some of those variables are bound to an OPC server(Eurotherm). When I place controls or indicators in a VI and bind them to the shared variable, some of them get the "green light" and some of them get the "red light". If I hover over the red light, there is a message about an error connecting to the shared variable. However, all the values update and appear to be working correctly. Why would I get this error?

Hi Brian,
Which version of the DSC Module is this? Is the OPC Server that you are trying to connect to on your local machine or on a remote machine?
Have you tried deleting the front panel object and redragging it from the project explorer? What type of value is this (boolean, double, etc?)
What are you referring to when you mean an "identical instrument" - are you connection to two different OPC I/O servers in your projects?
Would you be able to post a screenshot of this error please?
Best regards,
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

Opc server into shared variable

Hello,
I am writing a program to read hundreds of OPC signal from a server. The server is a localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server?
this is an example for my opc address
opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
Thanks
Solved!
Go to Solution.

fmpfmpf wrote:
Hello,
I am writing a program to read hundreds of OPC signal from a server. The server is a localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server?
this is an example for my opc address
opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
Thanks
LV-DSC (Data Logging and Supervisory Control) aloows you to "bind" the NSV to an OPC server.
As long as the server os OPC compliant it should work and has ben the case for me.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

OPC Shared variables supported types

Similar Messages

Maybe you are looking for