# OPC UA - Geschwindigkeit bei großen Datenaufkommen optimieren



## MFreiberger

Moin Experten,

wir setzen vereinzelt bei Fördertechnikanlagen eine OPC UA - Kommunikation ein.
Dabei müssen wir feststellen, dass die Geschwindigkeit nicht unbedingt unseren Erwartungen entspricht. Es ist so, dass die Kommunikation temporär abreißt/stark verlangsamt ist (mehrere Sekunden warten).

Als Server setzen wir S7-1515F-2 PN (V2.8.3) ein.

Jetzt überlegen wir, wo die "BottleNecks" in der Kommunikation zu suchen sind. Wir versuchen schon durch Array-Abfragen, registred read/write, subscriptions, etc. die Anlage zu optimieren.

Gibt es von Euch Erkenntnisse aus der Praxis, was hilft?

VG

MFreiberger


----------



## DeltaMikeAir

MFreiberger schrieb:


> Moin Experten,
> 
> wir setzen vereinzelt bei Fördertechnikanlagen eine OPC UA - Kommunikation ein.
> Dabei müssen wir feststellen, dass die Geschwindigkeit nicht unbedingt unseren Erwartungen entspricht. Es ist so, dass die Kommunikation temporär abreißt/stark verlangsamt ist (mehrere Sekunden warten).
> 
> Als Server setzen wir S7-1515F-2 PN (V2.8.3) ein.
> 
> Jetzt überlegen wir, wo die "BottleNecks" in der Kommunikation zu suchen sind. Wir versuchen schon durch Array-Abfragen, registred read/write, subscriptions, etc. die Anlage zu optimieren.
> 
> Gibt es von Euch Erkenntnisse aus der Praxis, was hilft?
> 
> VG
> 
> MFreiberger


Evtl bringt ja schon ein FW-Update auf V2.9 oder größer Vorteile für dich. Gerade im V2.9 Update hat sich sehr viel im Bereich OPC UA getan:


> Die Performance beim Schreiben von strukturierten Variablen und gleichzeitigem Beobachten über den OPC UA Server wurde verbessert.



Hier mal die OPC UA Verbesserungen der V2.9:


> *Neue Funktionen mit Firmware V2.9 für S7-1500 und ET 200 CPUs (ohne R/H CPUs):*
> 
> 
> OPC UA Alarms & Conditions:
> Über die Funktion OPC UA Alarms und Conditions ist es möglich Meldungen inklusive ihrer Begleitwerte an OPC UA Clients zu übermitteln Dabei können quittierungspflichtige Alarme vom OPC UA Client quittiert werden.
> Diese Funktion wird im TIA Portal über die Einstellungen in den Eigenschaften der CPU aktiviert.
> Bei der Modellierung der OPC UA Server Interfaces für S7-1500 und ET 200 CPUs können nun auch Objekte und Ordner angelegt bzw. per Drag&Drop als OPC UA-Element hinzugefügt werden.
> Im OPC UA Server Interface können Spezifikationen als Referenz importiert werden, auf deren Basis ein Mapping von Datentypen eines OPC UA Referenz-Namensraum zu einem FB oder UDT erfolgen kann. Mit jeder neuen Instanz werden automatisch die neuen Knoten im vorher definierten OPC UA Server Interface angelegt.
> Das Handling der CPU als OPC UA Client wird vereinfacht. Mit TIA Portal V17 sind anstelle von 12 Bausteinen nur noch drei Bausteine notwendig: Read, Write und Methodenaufruf.
> Die S7-1500 und ET 200 CPUs unterstützen die Hantierung von OPC UA-Zertifikaten über GDS (Global Discovery Service).  Für das Zertifikatsupdate kann jetzt entweder das TIA Portal oder ein separater GDS-Server genutzt werden. Die Inbetriebnahme kann durchgeführt werden, ohne dass ein Zertifikat schon auf der CPU vorhanden sein muss.
> Die vor allem bei Companion Spezifikationen verwendeten Datentypen "LocalizedText" und "ByteString" werden nun auch durch den OPC UA Server der S7-1500 und ET 200 CPUs unterstützt.
> Abrundung der DNS (Domain Name System) Funktionalität bei OPC UA / OUC und im Webserver
> Die Rückmeldungen des OPC UA Servers mit dem „Application Name“ können nun via DNS erfolgen.
> Der NTP-Client der CPU kann über DNS die für ihn relevanten NTP-Server ansprechen. Dadurch sind z.B. die Adressierung bzw. das Ansprechen eines Pools von NTP-Servern möglich.
> Der Webserver ist durchgängig über DNS-Adressierung erreichbar.
> Bei der Zertifikatshantierung wird DNS berücksichtigt.



Und die Fehlerbehebungen in V2.9:


> Die Performance beim Schreiben von strukturierten Variablen und gleichzeitigem Beobachten über den OPC UA Server wurde verbessert.
> Der OPC UA Server zeigte falsche Informationen im ServerProfileArray an.
> Das Profil "StandardUA" ist nicht mehr Teil des Profil Arrays. Es wurde in "EmbeddedUA2017" geändert. Außerdem sind die Profile "Methods" und "ComplexTypes2017" hinzugekommen.
> OPC UA: ArrayDimension von Variablen mit ValueRank 0 wurde nicht als -1 (null) zurückgegeben. Dies führte zu Problemen im PLC UA Client.
> In Zukunft wird die ArrayDimensions nur noch für ValueRank-Werte 0, -1, -2, -3 ausgelesen. So kann das Problem nicht mehr auftreten
> Wenn ein OPC UA Client einen CancelRequest auf einen Publish Request gesendet hat, gab der OPC UA Server ein falsches RequestHandle auf die Response mit einem Service Fault zurück.



Quelle:
Firmware-Update S7-1500 CPUs incl. Displays und ET 200 CPUs (ET 200SP, ET 200pro


----------



## MFreiberger

Moin DMA,

ja, das ist auf jeden Fall zu berücksichtigen.
Vielen Dank für die Links.

VG

MFreiberger


----------



## Ing_Lupo

Hallo

wieviele Variablen werden denn übertragen ?


----------



## MFreiberger

Moin Ing_Lupo,

das können schon ein paar Tausend elementare Datentypen sein.

Es geht mir aber auch nicht um das Überschreiten der Grenzen der Server, sondern um allgemeine Optimierungsszenarien. Das es zu Problemen kommt, wenn die Servergrenzen überschritten werden, ist klar uns sollte natürlich vermieden werden.

VG


----------



## codemonkey

Bin zugegeben eh kein Fan von OPC-UA. Aber rein aus Interesse, wie viele CPUs habt ihr da im Netz und welcher Client greift die Daten ab?


----------



## JesperMP

Und wie viele Daten, wie oft ?


----------



## Ing_Lupo

Hallo

ich nutze für OPC UA immer noch gerne eine zusätzliche Hardware um die Kom.leistung der CPU zu erhalten.

Meist das Gateway von INSEVIS. Das ist die HW einer S7 CPU-T mit Linux-OS.  Da kann man auch die Vorverarbeitung integrieren.


----------



## MFreiberger

codemonkey schrieb:


> Bin zugegeben eh kein Fan von OPC-UA. Aber rein aus Interesse, wie viele CPUs habt ihr da im Netz und welcher Client greift die Daten ab?


Moin codemonkey,

wir halten es für irrelevant, ob OPC UA die beste Kommunikationsart ist. Aber wir gehen davon aus, dass sich OPC UA als QuasiStandard druchsetzen wird (und es in vielen Bereichen ja schon getan hat). Deswegen setzen wir OPC UA ein und optimieren unsere Software dahingehend.

Derzeit haben wir einen Client (genauen Typen muss ich von unserem Partner nochmal erfragen) und sechs S7-1515F-2 PN als Server.

VG

MFreiberger


----------



## MFreiberger

Ing_Lupo schrieb:


> Hallo
> 
> ich nutze für OPC UA immer noch gerne eine zusätzliche Hardware um die Kom.leistung der CPU zu erhalten.
> 
> Meist das Gateway von INSEVIS. Das ist die HW einer S7 CPU-T mit Linux-OS.  Da kann man auch die Vorverarbeitung integrieren.


Moin Ing_Lupo,

wie sind dann die Steuerungen angebunden? Mit S7-Verbindungen?

VG

Mario


----------



## Ing_Lupo

Hallo

S7 Verbindungen  (RFC1006)  oder auch ModbusTCP


----------



## codemonkey

MFreiberger schrieb:


> Moin codemonkey,
> 
> wir halten es für irrelevant, ob OPC UA die beste Kommunikationsart ist. Aber wir gehen davon aus, dass sich OPC UA als QuasiStandard druchsetzen wird (und es in vielen Bereichen ja schon getan hat). Deswegen setzen wir OPC UA ein und optimieren unsere Software dahingehend.
> 
> Derzeit haben wir einen Client (genauen Typen muss ich von unserem Partner nochmal erfragen) und sechs S7-1515F-2 PN als Server.
> 
> VG
> 
> MFreiberger


Bin nun echt überrascht, dass die Anlage mit nur zwei Kommunikationspartnern bereits an die Grenzen stößt. Dachte die Grundidee hinter OPC-UA wäre ja, dass es jetzt nicht mehr blind Polling betreibt, sondern ereignisgesteuert die Daten verschickt.
Kann es sein das ihre einer riesigen Koppel-DB mit allen Daten habt und der dann immer komplett übertragen wird?


----------



## MFreiberger

Moin codemonkey,

der Löwenanteil der Daten steckt tatsächlich ein einem einzigen Array. Aber meistens ist das kein Problem.
Die Kommunikation wird eher temporär überbelastet. Ich vermute, dass der Client in ungünstigen Konstellationen zu viele Anfragen an den Server sendet.


----------



## JesperMP

Aber wie viele Daten und wie oft ? Ist ja nicht egal ob 100 bytes oder 10k bytes, 100 ms oder 10 sek.






						SIOS
					






					support.industry.siemens.com


----------



## MFreiberger

JesperMP schrieb:


> Aber wie viele Daten und wie oft ? Ist ja nicht egal ob 100 bytes oder 10k bytes, 100 ms oder 10 sek.
> 
> 
> 
> 
> 
> 
> SIOS
> 
> 
> 
> 
> 
> 
> 
> support.industry.siemens.com
> 
> 
> 
> 
> Anhang anzeigen 59315


Moin Jesper,

ja, Du hast Recht. Das ist nicht egal. Aber: an die aktuellen Werte komme ich derzeit nicht dran.
Mir geht es zunächst einmal allgemein um alle möglichen Methoden, die Performance zu optimieren, die Kommunikationslast zu reduzieren und damit eine stabilere Verbindung bzw. Datenübertragung zu schaffen.

VG

Mario


----------



## Blockmove

@MFreiberger 

Wir haben auch unser MES-System per OPC UA angebunden.
Mit 1515F haben wir auch Performanceprobleme.
Lösung ... Auch wenn's schmerzt ... Umstieg auf 1516F.

Stabilitätsprobleme haben wir eigentlich mit Tia 16 und Firmware 2.9 keine.


----------



## MFreiberger

Blockmove schrieb:


> @MFreiberger
> 
> Wir haben auch unser MES-System per OPC UA angebunden.
> Mit 1515F haben wir auch Performanceprobleme.
> Lösung ... Auch wenn's schmerzt ... Umstieg auf 1516F.
> 
> Stabilitätsprobleme haben wir eigentlich mit Tia 16 und Firmware 2.9 keine.


Moin Blockmove,

vielen Dank für die Info. Das war sehr hilfreich.
Ich denke bei den RBGs haben wir mit den 1515er keine Probleme. Aber die Fördertechnik hat ein bisschen mehr Datendurchsatz 

VG

Mario


----------



## Blockmove

MFreiberger schrieb:


> Moin Blockmove,
> 
> vielen Dank für die Info. Das war sehr hilfreich.
> Ich denke bei den RBGs haben wir mit den 1515er keine Probleme. Aber die Fördertechnik hat ein bisschen mehr Datendurchsatz
> 
> VG
> 
> Mario


Wir haben nur MES an OPC UA.
Die Kommunikation der Anlagen untereinander erfolgt nach wie vor über S7-Verbindungen.


----------



## ducati

kennst Du die schon:






						SIOS
					






					support.industry.siemens.com
				









						SIOS
					






					support.industry.siemens.com


----------



## ducati

> In TIA Portal haben Sie die Möglichkeit den OPC UA-Server einer SIMATIC S7-1500 zu entlasten und dessen Performance zu optimieren.
> 
> *Serverkonfiguration in TIA Portal*
> Beschränken Sie in der Hardwarekonfiguration einer SIMATIC S7-1500 in TIA Portal die maximale Anzahl an erlaubten Sessions und die maximale Anzahl an registrierten Knoten. Jede Session und jeder registrierte Knoten bindet Hardware-Ressourcen.
> Beschränken Sie außerdem für Subscriptions das kleinste Abtastintervall und das kleinste Sendeintervall auf sinnvolle Werte, um die maximale Auslastung des OPC UA-Servers zu begrenzen.
> Sie finden diese Einstellungsmöglichkeiten in der Gerätekonfiguration Ihrer CPU unter "OPC UA > Server > Einstellungen".
> *Nicht benötigte Kommunikationsfunktionen deaktivieren*
> Um die Kommunikationslast einer CPU zu senken und damit mehr Raum für die OPC UA-Kommunikation zu schaffen, deaktivieren oder löschen Sie nicht benötigte Kommunikationsfunktionen: Webserver, OUC-Kommunikation (T-Blöcke), HMI- oder S7-Verbindungen, etc
> *Variablen und Datenbausteine für OPC UA deaktivieren*
> Deaktivieren Sie die OPC UA-Sichtbarkeit von Variablen, die Sie für OPC UA nicht benötigen, über die Bausteinschnittstelle des TIA Portal. Deaktivieren Sie hierzu das Kontrollkästchen "Erreichbar aus HMI/OPC UA" für die nicht benötigten Variablen der Bausteinschnittstelle Ihrer Funktions- und Datenbausteine.
> Alternativ haben Sie die Möglichkeit die Sichtbarkeit von kompletten Datenbausteinen/Instanzdatenbausteinen für OPC UA zu deaktivieren. Navigieren Sie hierzu zu den Eigenschaften der Bausteine und dann zu "Attribute" und deaktivieren Sie das Kontrollkästchen "DB erreichbar aus OPC UA".
> Diese Einstellungen wirken sich hauptsächlich auf die Hochlaufperformance und den Arbeitsspeicherbedarf aus.
> *Benutzung von individuellen OPC UA-Serverschnittstellen*
> Ähnlich der Deaktivierung von Variablen und Datenbausteinen, kann die Verwendung von individuellen OPC UA-Serverschnittstellen die Hochlaufperformance und den Arbeitsspeicherbedarf senken. Hierbei haben Sie die Möglichkeit die sogenannte "Standard-SIMATIC-Serverschnittstelle" zu deaktivieren und eine eigene Schnittstelle zu erstellen, die beispielsweise ausschließlich benötigte Variablen und Methoden per OPC UA bereit stellt.
> Beachten Sie folgenden Beitrag für weitere Informationen: Siemens OPC UA Modeling Editor (SiOME) zur Umsetzung von OPC UA Companion Spezifikationen
> *Mindestzykluszeit für OBs (nur bei hoher Kommunikationsbelastung)*
> Wenn es Ihre Anwendung erlaubt, empfehlen wir Ihnen die Verwendung der Mindestzykluszeit für zyklische OBs. Stellen Sie die Mindestzykluszeit eines OBs größer ein als die tatsächliche Programmlaufzeit. Dadurch kann durchgängig mehr Zykluszeit für die Kommunikation genutzt werden.
> Sie finden die Einstellungen der Mindestzykluszeit in der Gerätekonfiguration Ihrer SIMATIC S7-1500 CPU unter "Eigenschaften > Zyklus". Aktivieren Sie das Kontrollkästchen "Mindestzykluszeit für zyklische OBs aktivieren" und tragen Sie anschließend in das Feld "Zykluszeit" eine angemessene Mindestzykluszeit ein.
> *OPC UA-Client sinnvoll konfigurieren*
> Den größten Einfluss auf die Kommunikationslast und die Performance des Servers hat jedoch der darauf zugreifende OPC UA-Client. Beachten Sie folgenden Beitrag für weitere Informationen: Wie kann ich einen OPC UA-Client optimal konfigurieren, um effizient und mit der best möglichen Performance mit dem OPC UA-Server einer SIMATIC S7-1500 CPU zu kommunizieren?


----------



## ducati

> Bei unangepassten Konfigurationen eines OPC UA-Clients, können Sie den OPC UA-Server einer SIMATIC S7-1200 oder S7-1500 CPU oder die OPC UA-Kommunikation unnötig belasten oder auch überlasten.
> 
> Wie stark der OPC UA-Server einer SIMATIC S7-1200 / S7-1500 CPU und die OPC UA-Kommunikation belastet werden, hängt maßgeblich vom darauf zugreifenden OPC UA-Client ab. In diesem FAQ geben wir Ihnen nützliche Tipps, um die Belastung des Servers möglichst gering zu halten, damit die Kommunikation zwischen Client und Server problemlos abläuft.
> 
> *Wiederholte Read- und Write-Zugriffe auf den Server (nur bei S7-1500)*
> Bei der Verwendung von häufig wiederkehrenden Read- und Write-Zugriffen auf die gleichen Variablen des Servers, empfehlen wir Ihnen die Implementierung des "Registered Read"- und "Registered Write"-Service. Beim Registrieren von Variablenknoten erstellt der OPC UA-Server ein sogenanntes "Handle", das direkt auf den registrierten Knoten verweist. Bei Lese- oder Schreibaufträgen des Clients auf dieses "Handle" muss der Server die Node-ID nicht mehr auflösen und kann zusätzlich optimiert auf die geforderte Variable zugreifen.*
> 
> Große Datenstrukturen und Arrays in einer Subscription*
> Sie sollten bei einer Subscription nicht grundsätzlich eine ganze Struktur oder ein ganzes Array als "Monitored Item" anlegen, sofern dies nicht durch Ihren Prozess erforderlich ist. Ändert sich nur ein Wert innerhalb einer Struktur oder eines Arrays, wird immer der ganze Datenblock in einem "Publish Response" übertragen. Dadurch erzeugen Sie unnötige Kommunikationslast. *
> 
> Temporär nicht benötigte Subscriptions deaktivieren*
> Deaktivieren Sie temporär nicht benötigte Subscriptions über Ihrem Client. Mit Hilfe des "Publishing Mode" können Sie nicht benötigte Subscriptions vorübergehend deaktivieren und bei Bedarf wieder reaktivieren. Damit entlasten Sie den Server und die Kommunikation temporär. *
> 
> Temporär nicht benötigte Monitored Items einer Subscription deaktivieren*
> Genau wie die Subscription selbst, können Sie auch einzelne Monitored Items innerhalb einer Subscription deaktivieren. Setzen Sie hierfür den "Monitoring Mode" der Items auf "Disabled". Um bei Bedarf die Abfragen auf die Items wieder zu aktivieren, setzen Sie deren "Monitoring Mode" je nach Anwendungsfall wieder auf "Sampling" oder "Reporting". Hiermit entlasten Sie den Server und die Kommunikation temporär.*
> 
> Aufteilung von Monitored Items innerhalb Subscriptions nach unterschiedlichen Sampling-Intervallen*
> Falls Ihr OPC UA-Client Variablen des Servers mit unterschiedlichen Sampling-Intervallen abonnieren soll, empfehlen wir Ihnen die Variablen, sortiert nach den gewünschten Sampling-Intervallen, über verschiedene Subscriptions zu verteilen. Gruppieren Sie beispielsweise Monitored Items mit geringen Sampling-Intervallen (z.B. 500 ms) in einer anderen Subscription, als Monitored Items mit hohen Sampling-Intervallen (z.B. 5000 ms).
> 
> *Konsistente Datenübertragung (nur bei S7-1500)*
> Mit OPC UA-Methoden haben Sie die Möglichkeit, Daten konsistent auf den OPC UA-Server einer SIMATIC S7-1500 CPU zu schreiben oder vom Server zu lesen. Die Zugriffsarten Read, Write und Subscription gewährleisten keine Datenkonsistenz. Hier muss der Anwender die Datenkonsistenz applikativ sicherstellen.*
> 
> Empfehlung zur maximalen Anzahl an Monitored Items von Subscriptions*
> Sie finden Empfehlungen zur maximalen Anzahl an Monitored Items von Subscriptions in den technischen Daten zu jeder CPU im Siemens Industry Online Support, bezogen auf ein Sampling- und Publishingintervall von 1000ms.*
> 
> Überschreitung der gewünschten Sampling-Zeit durch Überlastung des Servers oder zu vielen Monitored Items*
> Bei der Überschreitung der von Ihrem Client geforderten Sampling-Zeit von Monitored Items gibt der OPC UA-Server eine "GoodOverload"-Statusmeldung aus. Dieser Publishing-Response enthält keine aktualisierten Werte, da der Server überlastet ist und die geforderte Sampling-Zeit nicht einhalten kann. Auf diese Meldung können Sie mit Ihrem Client reagieren, indem Sie einige Punkte dieses FAQs befolgen: 109763090.*
> 
> OPC UA-Spezifikation 1.0.4 mit "Type Definitions" (ab Firmware V2.6)*
> Wenn Ihr Prozess vorsieht, komplexe Datentypen wie Strukturen oder UDTs vom OPC UA-Server einer SIMATIC S7-1200 / S7-1500 CPU zu lesen, empfehlen wir Ihnen die Verwendung des neuen Attributs "Type Definition" zum Parsing der übermittelten Daten. In diesem Fall können Sie das "Type Dictionary" der älteren Spezifikation auf der CPU abschalten, um Speicherressourcen freizugeben. Des Weiteren wirkt sich die Abschaltung des "Type Dictionary"  positiv auf die Hochlauf-Performance des OPC UA-Servers der CPU aus. Sie finden die Einstellung zum "Type Dictionary" in der Gerätekonfiguration der CPU unter "OPC UA > Allgemein > Abwärtskompatible Datentyp-Definitionen nach OPC UA-Spezifikation <= V1.03".*
> 
> Analyse der Kommunikationslast und Zykluszeit des OPC UA-Servers der SIMATIC S7-1200 / S7-1500*
> Ein detailliertes Bild der von Ihrem Client verursachten Kommunikationslast und der Zykluszeit des OPC UA-Servers einer SIMATIC S7-1200 / S7-1500 CPU erhalten Sie über den Systemfunktionsbaustein "RT_Info". Die folgenden Betriebsmodi unterstützen Sie hierbei:
> 
> 21: Liefert für den letzten Programmzyklus zurück, welche Anteile der Laufzeit auf die Kommunikation und das Anwenderprogramm entfallen.
> 25: Gibt die kürzeste, längste und die aktuelle Zykluszeit des Anwenderprogramms aus.
> Vergleichen Sie die Ergebnisse von "RT_Info" ohne und mit OPC UA-Kommunikation, um die Unterschiede festzustellen. Weitere Informationen zum SFB finden Sie in der TIA Hilfe ("F1").
> Hintergrund: Die OPC UA-Kommunikation einer S7-1200 / S7-1500 CPU findet innerhalb der Programmzyklen statt und wirkt sich deshalb negativ auf die Zykluszeit des CPU-Programms aus.


----------



## Rainer Hönle

Hast Du eigentlich schon einmal unseren *ACCON-OPC-Server UA* damit getestet?


----------



## ducati

MFreiberger schrieb:


> Es ist so, dass die Kommunikation temporär abreißt/stark verlangsamt ist (mehrere Sekunden warten).
> 
> Jetzt überlegen wir, wo die "BottleNecks" in der Kommunikation zu suchen sind.


Grundsätzlich würd ich aber  auch mal das Netzwerk nicht vergessen. 
Ist da was überlastet? PG oder sonstwas drangesteckt? Doppelte IP? Defekte Rj45? Defekte LWL-Umsetzer? IT-Tools die abundzu reinspucken? 
Alles schon gehabt. Man versteift dich auf irgendwas und dann liegts an was ganz anderem...


----------



## MFreiberger

Moin ducati und die anderen,

vielen Dank für die reichlichen Informationen!

Das muss ich jetzt erst einmal alles analysieren und bewerten.

VG
Mario


----------



## codemonkey

Blockmove schrieb:


> Wir haben auch unser MES-System per OPC UA angebunden.
> Mit 1515F haben wir auch Performanceprobleme.
> Lösung ... Auch wenn's schmerzt ... Umstieg auf 1516F.
> 
> Stabilitätsprobleme haben wir eigentlich mit Tia 16 und Firmware 2.9 keine.


Nur nicht, um in dieselbe Falle zu treten, war die S7-1515F eh schon am Limit, oder waren für die eigentliche Aufgabe noch Reserven vorhanden?


----------



## Blockmove

codemonkey schrieb:


> Nur nicht, um in dieselbe Falle zu treten, war die S7-1515F eh schon am Limit, oder waren für die eigentliche Aufgabe noch Reserven vorhanden?


Die Steuerung war zu etwa 30% mit der "eigentlichen Aufgabe" ausgelastet also genug Reserve.


----------



## ducati

Blockmove schrieb:


> Die Steuerung war zu etwa 30% mit der "eigentlichen Aufgabe" ausgelastet also genug Reserve.


OK....
also mehr als die dreifache Automatisierungsprogrammzeit wird für die Anbindung ans MES mit OPC-UA benötigt??? Da läuft doch aber gewaltig was schief...


----------



## DeltaMikeAir

Guten Morgen Mario,

vielleicht ist folgender Artikel für dich interessant:
Was bedeutet der OPC UA-Statuscode "GoodOverload"?


----------

