TIA 2 Wege OPC-UA Kommunikation

[ruh_di]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat jemand bereits Erfahrungen mit einer 2-Wege OPC-UA Kommunikation gesammelt?

Kurz etwas Hintergrundinfo:
Wir Kommunizieren zwischen einer 1516F und einer HMI (eigene Windows Desktop Applikation) über OPC-UA und müssen sehr viele Daten austauschen.
Bisher machen wir das indem wir ganzen Datenbausteine zyklisch aus der SPS auslesen. Da die Anzahl der Daten über immer größer wird und die Kommunikation generell nach dem Umstieg von einer Soft auf eine Hard-SPS deutlich langsamer geworden ist, wollen wir den Datenaustausch nun anders gestalten.
Man kann ja bei OPC-UA sogenannte Monitored Items anlegen, die selbstständig bei Datenänderung ein Ereignis senden, was aber nur bei einzelnen Datenelementen praktikabel ist.

Unser Gedanke war nun auf der SPS neben dem vorhandenen OPC-UA Server noch einen OPC-UA Client zu installieren und somit eine 2-Wege Kommunikation zu erstellen. Ich habe aber etwas Bedenken, wie gut in diesem Fall der Bedindungsaufbau und die Statbilität für die beiden Kommunikatiponskanäle ist. Möglicherweise könnte auch mit Netzwerk routingprobleme auftreten.

Deshalb würde es mich mal interessieren, ob schon jemand mit dieser Art der Kommunikation Erfahrungen gesammelt hat?
Für eine Rückmeldung wäre ich sehr Dankbar.

 

[maxder2te]

Kannst du erklären, was genau du damit bezwecken willst und welche Vorteile du dir erhofftst?
Was ist das Problem am den Monitored Items?

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wir hatten auch mit dem OPC-UA Server der SPS gespielt, jedoch war diese viel zu langsam wenn es sich um viele Daten handelt. Wir lesen bei manchen SPS 20000-30000 Variablen aus.

Ich glaube mit den MonitoredItems gab es auch irgendeine Begrenzung.

Wir nutzen AGLink, welches das S7Plus Protokoll nativ unterstützt, und viel schneller ist also OPCUA auf der S7 (zumindest war es das als wir den OPC Server getestet haben)

 

[ruh_di]

Aktuell lesen wir mit unserem Hauptprozess zyklisch 2 DB's aus. Das dauert je DB mit ca. 1100 Bytes < 100 ms. Es gibt aber auch noch weitere Unterprozesse, die ebenfalls Daten aus der SPS lesen. In Summe kommen wir da nun an Grenzen.
Mein Gedanke war deshalb, bestimmte Daten nicht ständig abzufragen. Statt dessen soll die SPS die geänderten Daten selbstständig senden.
Mit MonitoredItems geht das offensichtlich nicht. Man kann keine duzende oder hunderte von Datenelemente überwachen.
Deshalb kam der Gedanke auf, in der SPS noch einen OPC-UA Client zu installieren, der über einen 2. Kommunikationskanal die Änderungen zur HMI überträgt.
Ich hoffte hier jemand zu finden, der dies schon mal praktiziert hat.

 

[maxder2te]

Aktuell lesen wir mit unserem Hauptprozess zyklisch 2 DB's aus. Das dauert je DB mit ca. 1100 Bytes < 100 ms. Es gibt aber auch noch weitere Unterprozesse, die ebenfalls Daten aus der SPS lesen. In Summe kommen wir da nun an Grenzen.
Mein Gedanke war deshalb, bestimmte Daten nicht ständig abzufragen. Statt dessen soll die SPS die geänderten Daten selbstständig senden.
Mit MonitoredItems geht das offensichtlich nicht. Man kann keine duzende oder hunderte von Datenelemente überwachen.
Deshalb kam der Gedanke auf, in der SPS noch einen OPC-UA Client zu installieren, der über einen 2. Kommunikationskanal die Änderungen zur HMI überträgt.
Ich hoffte hier jemand zu finden, der dies schon mal praktiziert hat.

Das Problem verstehe ich jetzt aber nicht.

Die Systemgrenzen des OPC-Servers sind hier verzeichnet:

SIOS

support.industry.siemens.com

Der Rest ist eine Strategie-Geschichte:

WIE lest ihr aktuell die 1100 Bytes aus der SPS? Es macht einen Unterschied ob das HMI-System die 1100 Byte Daten blockweise liest und selber zerlegt, oder ob du da auf 8800 einzelne Bits zugreifst - letzteres ist natürlich Unsinn. Da wird weder OPC noch irgendein anderer Kommunikationstreiber was verbessern.

Vom Grundprinzip her macht der Onboard-OPC Server nichts anderes, als alle Variablen, auf die eine Subscription läuft, zyklisch aus dem Echtzeit-Teil der PLC zu pollen, das heißt, je mehr Subscriptions da laufen umso mehr wird der Echtzeitprozess belastet. Aber auch hier wird ein grpßer Unterschied sein, ob du Subscriptions auf große Datenblöcke machst, oder auf viele kleine Einzelvariablen.
Bei einer 1516 ist die minimale Abtastzeit des Servers auf 100 ms limitiert, Änderungen werden maximal alle 200 ms versendet. Wenn die Aktualisierungszeit von 100 ms dein Problem ist, dann fällt Onboard OPC jedenfalls weg - egal wie du das drehst.

Wenn ich mir deine Anforderungen so ansehe schlage ich dir eine recht einfache Strategie vor:
2 DBs lassen sich als Datentypen definieren und somit am OPC-Server als Complex-Data Strukturvariablen verwenden. Du erzeugst Subscriptions auf genau diese 2 Variablen, bei jeder Änderung bekommst du das ganze Paket hochgeschickt. Das Ganze kann man natürlich auch feiner granulieren (ist das ein deutsches Wort?) mit mehreren Datentypen pro DB und mehr Variablen.
Es ist klar, dass das nur geht, wenn dein HMI-System das Thema Complex-Data unterstützt.

Für Daten, welche du nur auf Anforderung liest, sind Subscriptions gar nicht notwendig.
Was du dir von einem OPC-Client auf der SPS erhoffst ist mir nach wie vor rätselhaft.
Als Alternative kannst du auf einen kommerziellen OPC-Server wie z.B. https://www.deltalogic.de/produkte/software/accon-opc-server-ua oder Bibliotheken wie AGLink setzen.

 

[ruh_di]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir lesen die DB's natürlich blockweise. Sie beinhalten ja hunderte von Einzelelemente.
Wenn ich die einzeln lesen würde, bräuchte man ja mehrere Sekunden für einen DB.
Die 100ms sind kein Problem. Wir lesen aber mindestens 2 DB's, kontextabhängig auch mehr. Wünschenswert ist, dass das HMI die Änderungen 2-3 mal pro Sekunde visualisiert.

Ich muss zugeben, noch nie versucht zu haben ein Monitored Item auf einen ganzen DB zu setzen. Ich frage mich aber, ob das überhaupt Sinn macht, denn ein Wert der hundert Einzelelemente wird sich wohl immer ändern und somit erhalte ich nach jedem Zylus eine Änderungsnachricht mit dem kpl. DB Inhalt.

Ziel war es, dass das HMI der SPS mitteilt, in welchem Kontext es sich aktuell befindet und die Steuerung eben nur die relevanten Daten als Änderungsnachricht sendet.

 

[ThomasLevering]

Wenn es unbedingt Read sein soll, dann geht es mit Registered Items schneller. (Interner OPC Server)
Und dann einen einzigen UDT

 

[winnman]

Oder doch auf mehrere DB aufteilen, dann wird ja wohl nicht in allen gleichzeitig eine Änderung stattfinden, dann nur die DB übertragen(lassen) bei denen sich was geändert hat.

Was ich aus der Fernwirktechnik kenne:
Da werden Analogsignale erst übertragen
1) wenn sich entweder innerhalb kurzer Zeit eine größere Änderung ergibt
oder
2) wenn sich x kleine Änderungen aufsummiert haben
oder
3) bei einer Generalabfrage wird immer der aktuelle Wert übertragen
für 1 und 2 gilt: die jeweiligen Faktoren lassen sich pro Variable anpassen.

Ob so was für euch interessant ist müsstet ihr prüfen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ziel war es, dass das HMI der SPS mitteilt, in welchem Kontext es sich aktuell befindet und die Steuerung eben nur die relevanten Daten als Änderungsnachricht sendet.

Wäre es da nicht sinnvoller, dass die HMI nur die Items liest, die es gerade braucht.
Also ähnlich, wie es Siemens bei seinen Panels handhabt

 

[ruh_di]

Danke für die Rückinfos.
Offensichtlich hat noch niemand solch eine bidirectionale Verbindung im Einsatz. Wir werden deshalb wohl auch diesen Ansatz nicht weiter verfolgen.
Der Gedanke war einfach ein Datenverkehr in beide Richtungen um so auf Datenänderungen reagieren zu können ohne immer sämtliche DB's zu lesen und auf Veränderungen zu untersuchen.

 

[Michitronik]

Hi @ruh_di . Ich sehen das einzige Szenario, wo jeweils eine Client<->Server Verbindung in beiden Richtungen projektiert wird bei Method Calls. Da kann dann jeder der beiden Teilnehmer einen Method Call beim anderen absetzen. Zum Beispiel der eine Triggert eine Auftrag mit diversen Parametern und der andere Teilnehmer quittiert dies, wenn der Auftrag fertig ist (Method Call muss innerhalb einer kurzen Zeit abgeschlossen sein, weil es sonst zum Fehler kommt). Idealerweise mit einem Handle, damit man mehrfach Auftrage zuweisen kann.

Was eine Projektierung von Client und Server auf beiden Seiten bringen kann, außer mehr Aufwand beim Engineering, kann ich dir nicht sagen. Es werden Listen erstellt, welche Variablen ausgetauscht werden müssen/sollen. Da macht es wenig sinn, diese auf beiden Seiten zu erstellen und auch noch zu pflegen.
Bei großen Daten Mengen sollte man eh auf andere Kommunikationen ausweichen. Das ist mMn OPC UA nicht optimal.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Systemgrenzen des OPC-Servers sind hier verzeichnet

Für Interessierte, das PDF wurde für die neue Firmwareversion ( V3.1/1500ér ) angepasst:
Siemens FAQ: Welche Systemgrenzen enthält der OPC UA Server bei der S7-1500 und der S7-1200?

Beschreibung:
Das im Beitrag enthaltene PDF-Dokument zeigt Ihnen die Systemgrenzen, die der OPC UA Server der S7-1500 und S-1200 bei den letzten aktuellen Firmware-Versionen aufweist.

 

[Heinileini]

Das Ganze kann man natürlich auch feiner granulieren (ist das ein deutsches Wort?) mit mehreren Datentypen pro DB und mehr Variablen.

Nein, ich denke, es wird bei uns durchaus noch als "Fremdwort" empfunden, Aber denglisch ist es auch nicht. Es leitet sich aus dem Lateinischen ab. Es wäre aber nicht abwegig, sondern nur "umwegig", wenn es auf dem Umweg über das Englische zu uns gekommen sein sollte. Denn das englische Wort grain kommt letztendlich auch aus derselben lateinischen Quelle.