OPC-UA Server aktualisierungszeit

[RogerSchw85]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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

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

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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

 

[inray]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

war quatsch respektive ein Programmierfehler