# OPC-UA Server aktualisierungszeit



## RogerSchw85 (9 Juni 2018)

Hallo zusammen

Ich habe hier eine Anwendung in der alle 100ms die Daten aus der SPS gelesen werden und via OPC-UA an die Visualisierung weitergeben werden müssen. Wir brauchen normalerweise die dataFeed OPC Suite von Softing aber ich weis nicht ob die so schnell ist. Hat da schon jemand Erfahrung damit? Die Steuerung ist eine 1515er von Siemens.

Das ganze Netzwerk ist im Schaltschrank, geht also nicht über ein Firmen Netz.

Danke schonmal


----------



## Blockmove (9 Juni 2018)

100ms kann der datafeed schon.
Allerdings spielt die Anzahl und Struktur der Daten auch eine erhebliche Rolle.
Daher lässt sich deine Frage nicht pauschal beantworten.

Gruß
Blockmove


----------



## RogerSchw85 (9 Juni 2018)

Ich habe nun einige Tests gemacht und war bei 800ms... Ich denke ich muss die OPC Verbindung auf die zweite Netzwerkarte, unabhängig vom Profinet, anschliessen...

Was meinst du mit Struktur? Die Anzahl ist mir bewusst.


----------



## Blockmove (9 Juni 2018)

RogerSchw85 schrieb:


> Was meinst du mit Struktur? Die Anzahl ist mir bewusst.



datafeed kann Leseaufträge, wenn die Daten beieinander liegen zusammenfassen.
2. Netzwerkkarte? Du meinst einen CP auf der 1500er?
Das bringt auf jedenfall was.


----------



## Thomas_v2.1 (9 Juni 2018)

Blockmove schrieb:


> datafeed kann Leseaufträge, wenn die Daten beieinander liegen zusammenfassen.


Wann liegen die Daten bei einer 1500 im optimierten Bereich denn beieinander?


----------



## Blockmove (9 Juni 2018)

Thomas_v2.1 schrieb:


> Wann liegen die Daten bei einer 1500 im optimierten Bereich denn beieinander?



Wo steht, dass der Softing datafeed auf einen optimierten DB zugreift?
Wenn ich mich nicht ganz täusche, dann kann dass der datafeed noch gar nicht solange.

Ansonsten hast du natürlich recht.

Gruß
Blockmove


----------



## RogerSchw85 (9 Juni 2018)

Blockmove schrieb:


> datafeed kann Leseaufträge, wenn die Daten beieinander liegen zusammenfassen.
> 2. Netzwerkkarte? Du meinst einen CP auf der 1500er?
> Das bringt auf jedenfall was.



Die 1515er hat zwe getrennte Karten, aber wahrscheindlich nur eine CPU... 

Ja ist alles Optimiert...

Aber eine CP wäre eine gute Idee, würde auch die CPU der Steuerung entlasten


----------



## Thomas_v2.1 (9 Juni 2018)

Wie viele Variablen hast du denn bei deinem Versuch mit den 800ms gelesen?


----------



## inray (9 Juni 2018)

Hallo,

also die 1500er soll ja ziemlich fix sein, was die Datenkommunikation angeht. Laut SPS Magazin (Artikel) 10.000 Bytes in 10ms. Von daher sollte die Anforderung leicht zu schaffen sein. Unser Erfahrung nach (wir nutzen und vertreiben den KepWare OPC Server) ist es aber von vielen verschiedenen Parametern abhängig. 
Bzgl. der Symbolischen/optimierten Adressierung wäre ich auch noch skeptisch. Vielleicht ist es eine gute Idee, für diese Daten einen nicht optimierten DB anzulegen, so dass man sich ausrechnen kann anhand der Größe des DB und der PDU Größe, wie lange der Transfer eigentlich dauern dürfte. 
Alle weiteren Daten, die per OPC von der SPS abgerufen werden, verlangsamen dies natürlich, da der OPC Server im Normalfall nur eine Verbindung zur SPS hat. Im KepWare kann man auch einfach eine weitere Verbindung anlegen, die solch kritische Daten explizit abruft. Dadurch stresst man natürlich aber auch die CPU.
Nach unseren Erkenntnissen sind aber der CP, die PDU Größe und die Menge der Daten die abgerufen werden und deren Streuung auf der S7 (kompakt liegen Daten können besser zusammengefasst abgerufen werden), die entscheiden Faktoren für den Datendurchsatz. Netzwerkanbindung und Leistungsfähigkeit des OPC Servers sind meist in halbwegs aktuellen Umgebungen der SPS überlegen.
Schlussendlich muss aber auch sagen, OPC ist keine deterministische SPS-Kommunikation. Wenn das 100ms Raster für diese Daten garantiert werden soll, sollte man über einen FIFO Inder SPS nachdenken und einen Handshake zum Abholen der Daten definieren. Sonst wird man immer mal mehr und mal weniger als 100ms haben. Der OPC UA Server läuft ja auf nem Windows Systemen und da kann's ja auch mal haken


----------



## RogerSchw85 (9 Juni 2018)

Thomas_v2.1 schrieb:


> Wie viele Variablen hast du denn bei deinem Versuch mit den 800ms gelesen?



Das kann ich jetz nicht mehr sagen, ich werde das morgen zusammen rechnen. Was ich aber sagen kann ist bei 30bool war ich bereits bei 400ms.

An dieser Steuerung sind etwa 60 Profinet Teilnehmer projektiert, aber erst 10 verbunden. Ich denke wirklich mein Problem ist das Netzwerk.


----------



## Thomas_v2.1 (9 Juni 2018)

Wenn auf optimierte Bereiche zugegriffen wird, dann bietet die SPS aber sog. Subscriptions an, sodass automatisch Variablen ohne weitere Anfrage automatisch von der SPS versendet werden.
Das gab es bei der S7-300/400 in beschränkter Weise auch schon, aber soweit ich weiß wird das bei nicht-optimiertem Zugriff auf eine S7-1500 nicht mehr unterstützt.

Der WinCC Treiber kann bei einer sehr alten S7-1200 mit FW2 die ich hier habe, z.B. 200 16Bit-Integer-Variablen (optimiert) problemlos im 100ms Zyklus abfragen.
Wenn die 1500er das nicht schafft, dann muss diese wirklich sehr ausgelastet sein. Aber ob dann ein extra CP hilft?


----------



## inray (9 Juni 2018)

30 Bool Werte sind ja, wenn sie gut zusammengelegt sind, gerade 4 Bytes. Das sollte dann ja in 10ms locker machbar sein.
Profinet und TCP/IP Netzwerk gemischt ist natürlich eine "üble" Mischung, die man immer öfter vorfindet. Da hat TCP/IP natürlich das Nachsehen und welche Abfrage-Zeiten man dann beim OPC Server hat, ist Glückssache. Netzwerktrennung ist hier wohl wirklich angesagt.


----------



## RogerSchw85 (10 Juni 2018)

Thomas_v2.1 schrieb:


> Wenn auf optimierte Bereiche zugegriffen wird, dann bietet die SPS aber sog. Subscriptions an, sodass automatisch Variablen ohne weitere Anfrage automatisch von der SPS versendet werden.
> Das gab es bei der S7-300/400 in beschränkter Weise auch schon, aber soweit ich weiß wird das bei nicht-optimiertem Zugriff auf eine S7-1500 nicht mehr unterstützt.
> 
> Der WinCC Treiber kann bei einer sehr alten S7-1200 mit FW2 die ich hier habe, z.B. 200 16Bit-Integer-Variablen (optimiert) problemlos im 100ms Zyklus abfragen.
> Wenn die 1500er das nicht schafft, dann muss diese wirklich sehr ausgelastet sein. Aber ob dann ein extra CP hilft?



Die Subscriptions gibt es aber nur wenn der OPC US Server auf der 1500er läuft oder? Damit hatten wir Schwierigkeiten weil danach die Zykluszeit der SPS extrem schwankte, zwischen 5 - 45ms... Und wenn ich eine CP habe, entlaste ich doch das Netzwerk, da ich einen zweiten Strank direkt an den OPC Server ziehen kann.



> 30 Bool Werte sind ja, wenn sie gut zusammengelegt sind, gerade 4 Bytes. Das sollte dann ja in 10ms locker machbar sein.
> Profinet und TCP/IP Netzwerk gemischt ist natürlich eine "üble" Mischung, die man immer öfter vorfindet. Da hat TCP/IP natürlich das Nachsehen und welche Abfrage-Zeiten man dann beim OPC Server hat, ist Glückssache. Netzwerktrennung ist hier wohl wirklich angesagt.



Ich denke das eben auch... Vor allem ist der PC auf dem der OPC Server läuft überhaupt nicht ausgelastet... Der hat 1% CPU Auslastung und auf dem Netzwerk Nichtmal 1%...


----------



## Thomas_v2.1 (10 Juni 2018)

RogerSchw85 schrieb:


> Die Subscriptions gibt es aber nur wenn der OPC US Server auf der 1500er läuft oder? Damit hatten wir Schwierigkeiten weil danach die Zykluszeit der SPS extrem schwankte, zwischen 5 - 45ms... Und wenn ich eine CP habe, entlaste ich doch das Netzwerk, da ich einen zweiten Strank direkt an den OPC Server ziehen kann.



Nein, die gibt es auch im normalen Protokoll, wobei ich nicht weiß ob der Softing OPC-Server davon überhaupt Gebrauch macht.
Vielleicht braucht der OPC Server ja auch so lange bis er dir die Daten auf der Client-Seite zur Verfügung stellt?


----------



## RogerSchw85 (10 Juni 2018)

Aber dann wäre die Zeit immer gleich. Und nicht bei 30bool 400ms und bei einweing mehr gleich 800ms. Das wäre ja in der Praxis absolut nicht tauglich. OPC-UA wurde zumDaten sammeln entwickelt, also muss das doch handle bar sein...


----------



## Jochen Kühner (10 Juni 2018)

Also der OpcUa Server auf der S7 ist arschelahm, wir hatten unsere Fördertechnik Visu damit probiert. Zu langsam!

Der Zugriff über das neue Protokoll (keine Ahnung welcher Opc Server das schon kann, Aglink kann es), ist viel schneller als über das alte S7 Protokoll. Und absolut oder nicht ist da egal.


----------



## RogerSchw85 (10 Juni 2018)

Der dataFeed benutzt tatsächlich die neue Schnittstelle. Das heisst für mich noch mehr das ich probleme mit den Netzwerk habe.

Wie gesagt den OPC auf der Steuerung halten wir auch für untauglich da zu lahm...


----------



## Thomas_v2.1 (10 Juni 2018)

Jochen Kühner schrieb:


> Der Zugriff über das neue Protokoll (keine Ahnung welcher Opc Server das schon kann, Aglink kann es), ist viel schneller als über das alte S7 Protokoll. Und absolut oder nicht ist da egal.


Wobei das schon verwunderlich ist, denn das neue ist wesentlich aufwändiger zu verarbeiten. Selbst wann man das Bytedrehen mit einbezieht (je nach dem wie Siemens das intern wirklich ablegt ist das wirklich notwendig), ist da von den Ausführungsbefehlen sicher ~Faktor 5 und mehr beim neuen Protokoll.
Zusätzlich gibt es einen größeren Overhead. Ich habe das mal grob überschlagen, wenn es ganz ungünstig ist bei 200 16 Bit Integer im alten Protokoll die ich alle einzeln lese (so denn sie in eine PDU passen) lese, dann habe ich ca. 32% echte Nutzdaten. Im neuen Protokoll sind es bei den Subscriptions nur ~21%, wobei es da wegen der VLQ noch schlechter (16 Bit Integer benötigt 3 Bytes) oder auch etwas besser (16 Bit Integer benötigt nur 1 Byte) sein kann, aber niemals besser als das alte Protokoll. Fraglich ob AGlink diese Funktion der Subscriptions überhaupt nutzt, die waren ja etwas hintendran.


----------



## Rainer Hönle (11 Juni 2018)

Thomas_v2.1 schrieb:


> Fraglich ob AGlink diese Funktion der Subscriptions überhaupt nutzt, die waren ja etwas hintendran.


ACCON-AGLink unterstützt (derzeit) die Subscriptions nicht sondern nur das normale Lesen (Request, Response). Versteh allerdings nicht, was Du mit "die waren ja etwas hintendran" meinst. ACCON-AGLink hat als erste Bibliothek überhaupt das neue Protokoll mit Zugriff auf die "optimierten Bausteine" und den symbolischen Zugriff unterstützt. Da waren wir somit eher vornedran ;-).


----------



## RogerSchw85 (11 Juni 2018)

war quatsch respektive ein Programmierfehler


----------



## RogerSchw85 (11 Juni 2018)

Sooooooo jetzt aber, nach langen Diskussionen mit Softing:

Die neue S7-2 Kommunikation ist extrem "langsam", da sie einen extrem Overhead hat und immer alles übertragen wird. Bei mir war das 400ms pro Zyklus.

Die alte Kommunikation ist bei mir nun doppelt so schnell, also bei 200ms für die gleiche Datenmenge.

Nun habe ich zwei Verbindungen auf die Steuerung erstellt, eine alte und eine neue. Die neue brauche ich für nicht Zyklus relevante Daten. Da ich aber die Variablen in meine Visualisierung direkt einbinden kann, erspart mir das einen Haufen arbeit.

Die alte Kommunikation, dort muss ich jedes mal einen Variablen Export machen, brauche ich überall wo es Zeitkritisch ist. Mal schauen wo ich hinkomme


----------



## Thomas_v2.1 (11 Juni 2018)

Du könntest ja mal ein Wireshark Log erstellen und hier anhängen (oder meinetwegen auch per PN / Email), evtl. kann ich dir sagen was da nicht ganz so rund läuft.


----------



## RogerSchw85 (11 Juni 2018)

Das werde ich machen. 

Jedoch hat Softing bestätigt das mehr nicht möglich ist.


----------



## Rainer Hönle (12 Juni 2018)

Das Log würde mich auch interessieren.


----------



## RogerSchw85 (13 Juni 2018)

Hier die Wireshark Datei:

Anhang anzeigen Wireshark.zip


----------



## Thomas_v2.1 (13 Juni 2018)

Was ich da so ganz grob sehe, dass dort insgesamt ca. 900 Variablen aus der SPS abgefragt werden. Darunter auch mehrere Strings mit voller 256 Byte Länge.
Ein gesamter Pollzyklus um diese Variablen alle nacheinander zu lesen benötigt im Durchschnitt ca. 200ms. Wenn man die Datenmenge beachtet, ist das meiner Meinung nach nicht ungewöhnlich langsam.

Vielleicht kannst du deine Variablen auf verschiedene Aktualisierungszyklen aufteilen? Ich weiß nicht ob der OPC-Server da die Anfragen vom Client irgendwie dazu weiterverwendet.
Z.B. die Strings in eine langsamere Gruppe verlegen, diese wirst du vermutlich nicht alle paar Millisekunden benötigen.


----------



## RogerSchw85 (14 Juni 2018)

> Was ich da so ganz grob sehe, dass dort insgesamt ca. 900 Variablen aus der SPS abgefragt werden. Darunter auch mehrere Strings mit voller 256 Byte Länge.
> Ein gesamter Pollzyklus um diese Variablen alle nacheinander zu lesen benötigt im Durchschnitt ca. 200ms. Wenn man die Datenmenge beachtet, ist das meiner Meinung nach nicht ungewöhnlich langsam.



Dazu muss ich sagen, dass das die "neue" S7-2 Verbindung macht. Mit der siehst du sämtliche Variablen auf der Steuerung. Dort ist mir die Aktualisierungszeit egal da dort nur noch "belanglose" Variablen abgefragt werden. Dieser Verbindung ist bei knapp 500ms was ausreichend ist.



> ielleicht kannst du deine Variablen auf verschiedene Aktualisierungszyklen aufteilen? Ich weiß nicht ob der OPC-Server da die Anfragen vom Client irgendwie dazu weiterverwendet.
> Z.B. die Strings in eine langsamere Gruppe verlegen, diese wirst du vermutlich nicht alle paar Millisekunden benötigen.



Genau das habe ich getan und eine zweite, herkömmliche Verbindung vom OPC Server zur SPS aufgebaut, auf einen nicht optimierten Baustein. In dieser sind im Moment 8Bit bei einer Aktualisierungszeit von 200ms. Laut Softing und Siemens wird da nicht mehr gehen, jedoch reicht es mir auch.


----------



## Thomas_v2.1 (14 Juni 2018)

RogerSchw85 schrieb:


> Genau das habe ich getan und eine zweite, herkömmliche Verbindung vom OPC Server zur SPS aufgebaut, auf einen nicht optimierten Baustein. In dieser sind im Moment 8Bit bei einer Aktualisierungszeit von 200ms. Laut Softing und Siemens wird da nicht mehr gehen, jedoch reicht es mir auch.



Also laut deiner Aufzeichnung werden über die herkömmliche Verbindung alle 10ms 16 Bytes im DB51 gelesen.
Oder sind die 200ms Aktualisierung auf OPC-Client-Seite? Aber warum wird dann die SPS im 10ms Zyklus gepollt?

Kommt das mit den 900 Variablen über den neuen Kanal eigentlich hin? Siemens-Anwendungen lesen die Variablen etwas anders als dort in der Anwendung. Mir kommt da eine Sache etwas spanisch vor was die da veranstalten.


----------



## RogerSchw85 (15 Juni 2018)

Ich verstehe das nicht ganz ehrlich gesagt...



> Also laut deiner Aufzeichnung werden über die herkömmliche Verbindung alle 10ms 16 Bytes im DB51 gelesen.



Das ist so konfiguriert das er alle 10ms pollt, ich muss mich jedoch fragen das das sinn macht  Ich habe es jetzt auf 100ms geändert und habe immer noch 200ms Aktualisierungszeit...

Laut Client Hersteller seien sie so schnell wie der OPC-Server ihnen sagt das eine Datei aktualisiert wurde...



> Kommt das mit den 900 Variablen über den neuen Kanal eigentlich hin? Siemens-Anwendungen lesen die Variablen etwas anders als dort in der Anwendung. Mir kommt da eine Sache etwas spanisch vor was die da veranstalten.


Das kommt hin ja. Softing meinte dazu das dieses Protokoll immer alle Variablen liest und deshalb langsamer ist. Bei mir ist es jetzt bei 400ms. Da ich alle DB und Variablen die ich nicht mehr benötige, nicht mehr Sichtbar habe für den OPC Server.


----------

