.NET OPC UA Client Empfehlung

[zeroc8]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, ich bin auf der Suche nach einer .NET Client Komponente (pures.NET, kein .NET/COM Wrapper), ueber die ich von einer WPF Anwendung aus auf einen OPC UA/DA Server zugreifen kann.

Bis jetzt hab' ich XML/DA immer direkt eingebunden, wir moechten aber auf ein performanteres Protokoll umsteigen.

Wichtig waere mir auch, dass ich mich nicht allzusehr mit "Lizenzmanagern" und dergleichen herumschlagen muss, wie z.B. beim OPC Labs Client, wo dann auf jedem Clientrechner die Lizenz gemanaged werden muss.

Welche Produkte koennt ihr da empfehlen?

 

[ZbynekZ]

Hello, I represent OPC Labs. It is not fully correct that on each computer running our product the license must be "managed". Commercial license holders are entitled to receive a document that explains how to set up the license programatically (from the code of the installation program or the application itself), removing the need for any additional user operations. Mit freundlichen gruessen, Zbynek Zahradnik

 

[zeroc8]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, is this document somewhere available for prospective clients?
I need this information before making the decision.

 

[zeroc8]

Ich hab' jetzt das hier gefunden, sieht auf den ersten Blick nicht schlecht aus und kostent nichts.

https://opcuaservicesforwpf.codeplex.com/

 

[ZbynekZ]

Yes, please send this request using a form on our Web site, www.opclabs.com, Company -> Contact Us (http://www.opclabs.com/company/contact/form/3-contact-form). This way I get your email address and can send it to you. Include your company name in case it is not apparent from the email domain. Best regards, ZZ

 

[ZbynekZ]

Zuviel Werbung?
-> Hier kostenlos registrieren

I think that opcuaservicesforwpf include OPC Foundation's .NET UA stack libraries, while missing a license that actually permits doing that (those libraries are only available to OPC Foundation corporate members, as we are). But I may be wrong.

 

[zeroc8]

I don't know. In any case, I'm only investigating it for learning purposes.
For the project itself, I'd rather use an "OPC certified" component anyway, such as yours.

I need to connect 50 WPF clients to one OPC server. I'm not quite sure how to best achieve this.

As far as I understood, there are two possibilities:
1) connect every client to the opcserver.
or
2) Write some service that fetches OPC data over one single TCP connection and distributes messages using a MQTT broker (the message broker is needed anyway for other user interactions that have nothing to do with OPC).

Any recommendations?

 

[pvbrowser]

OPC UA daemon for use with pvbrowser
####################################################################################################

This daemon has become possible by the use of:
http://open62541.org

This OSS project provides a C library for implementing OPC UA client and server software.

Attention: This is an early release of our daemon and not all features might be included.
But it is already usable for browse/read/write basic datatypes.
The question is "what about recursive data?".
Currently "browse" does not recurse, it lists the variables visible on top of the tree.

Thus this version must be extended in the future.

####################################################################################################
HOWTO evaluate this daemon (under linux)

### In terminal 1 start the server: ###
cd pvbaddon/daemons/opcua/server
./pvs

### In terminal 2 you may now "Browse" the server: ###
cd pvbaddon/daemons/opcua/client
./opcua_client opc.tcp://localhost:16664 Browse -longname
####################################################
#./opcua_client opc.tcp://localhost:16664 Browse
#
# Itemlist := NAMESPACE#NODEID#BROWSE NAME#DISPLAY NAME
# Lines starting with # are treated as comment lines
####################################################
0#61#FolderType#FolderType
0#2253#Server#Server
1#95#current time#current time
1#96#cpu temperature#cpu temperature
1#97#status LED#status LED
1#the.answer#the answer#the answer
1#50000#Demo#Demo

./opcua_client opc.tcp://localhost:16664 Browse -longname > opvua.itemlist

### In terminal 2 you may now "Run" the daemon (which will write to the pvbrowser shared memory) ###
cd pvbaddon/daemons/opcua/client
./opcua_client opc.tcp://localhost:16664 Run

### In terminal 3 you may now run an example pvserver ###
cd pvbaddon/daemons/opcua/pvs
./pvs

### You may now run the pvbrowser client ###
pvbrowser pv://localhost

####################################################################################################

Datatype identifier:

Boolean:
SByte:
Byte:
Int16:
UInt16:
Int32:
UInt32:
Int64:
UInt64:
Float:
Double:
String:
Guid:
NodeId:
ExpandedNodeId:
QualifiedName:
LocalizedText:
ExtensionObject:
DataValue:
Variant:
DiagnosticInfo:

Example howto send an Int32 value:
opc.writeStringValue("1#the.answer", "Int32:123");

Parameter 1 is the variable name (see opcua.itemlist which was generated by browse).
Parameter 2 is the Int32 value.

 

[ZbynekZ]

Zuviel Werbung?
-> Hier kostenlos registrieren

The answer depends on more factors - how many tags, how often they change, and the performance of the box running the server. 50 clients may not be too many for a PC based OPC UA server, but probably is too many for a UA server running on a PLC or other embedded device. Assuming that we are talking about a situation where the clients all demand roughly the same data from the server, OPC Foundation is working on an extension to OPC UA called PubSub that would address this problem in a standardized way, with the use of messaging middleware. First demo of it will be on Hannover Fair 2016; not sure how long it will then take to become a stabilized, usable (and reasonably wide accepted) spec.

 

[zeroc8]

Interesting, PubSub is exactly what I'm looking for. However, I'm afraid I cannot wait until the OPC foundation comes up with something.

We are hosting the OpcServer on a Siemens Microbox PC. The old OPC Soap Service was restricted to max. 9 connections. A fact that complicated the client software design quite a bit.
I'll guess I'll need check my MQTT options.

However, what I do not quite understand is, what's the difference between the upcoming PubSub mechanism and the current "subscribe" mechanism.
If, for example 10 connections connect to the same OPC server and subscribe to changes of an item, how is that different from the new PubSub mechanism?

 

[jpfr]

However, what I do not quite understand is, what's the difference between the upcoming PubSub mechanism and the current "subscribe" mechanism.
If, for example 10 connections connect to the same OPC server and subscribe to changes of an item, how is that different from the new PubSub mechanism?

UA PubSub in its current draft form defines how to plug an external message queue into an OPC UA server.

For this, DataSets are defined, who define a mapping of attributes in the UA information model onto Pub/Sub messages. MessageWriters and MessageReaders (de)serialize the messages coming over the external message queue and sync the content with the UA information model.

If you just want to read 10 variables with pub/sub, the existing subscription mechanism should work just as well.