-> Hier kostenlos registrieren
Hallo,
ich hatte bereits mehrmals mit dem "integrierten" OPC UA Server von Siemens CPU`s zu tun. Einmal in Form einer Kommunikation zwischen einer C#/.NET basierten Anwendung welche als OPC Client mit der CP(1512er) kommuniziert hat. Dabei ging es um das Auslesen von diversen Daten, die zum Glück nicht zeitkritisch waren.
Ein weiteres Mal musste ich diverse 1517er als OPC Server implementieren die mit einer LabVIEW Software über das zugehörige OPC UA Toolkite (Client) kommunizierten und "relevante" Prozessparameter im stetigen Austausch waren.
In beiden Fällen habe ich die Nodes "subscribed" und habe diese über "Value Change Events" von Server Seite empfangen.
Zu meiner Enttäuschung gab es in beiden Konstellationen ominöse Performance-Probleme.
Das sah dann in etwa so aus: Die Schnittstelle läuft über kurz- bis mittelfristige Zeiträume relativ stabil. Aber es kommen sporadisch Fälle vor wo das Schreiben einer Node auf einmal 10s und mehr dauerte. Was eine unrealistische Anpassung der Connection Timeout Zeit erforderte. Das war vor allem bei 300+"registrierten" Nodes der Fall. In einem solchen Fall war auch immer eine Meldung im Puffer der CPU zu sehen, welche von "unbekannten Nodes" oder Ähnlichem sprach. Nur dass es keine unbekannten Nodes waren, sondern die CPU einfach mit der Suche nach dieser überfordert war in diesem Moment.
Ich muss jedoch eingestehen, dass ich für die OPC Schnittstelle im TIA Portal immer das Häkchen bei "Simatic Server-Standardschnittstelle" gesetzt hatte und keine explizite OPC Schnittstelle definiert habe. Das definieren einer OPC Client Schnittstelle ist doch sowieso irreführend, da dabei benannte Variablen/Nodes eine Laufnummerierung (z.B. "i=000038") bekommen. Das kann man doch niemandem erzählen...
Nun habe ich ein Projekt welches nochmal deutlich mehr Nodes für die OPC Komm beinhaltet (900+). Die Planung hatte sich wohl darauf verlassen, dass die OPC Funktionalität von SIEMENS als sehr zuverlässig gilt.
Mein derzeitiger Lösungsansatz ist wohl einen "softwarebasierter" OPC Servers (von ACCON/KEPWARE/ProSys) auf einem zusätzlichen Leitrechner zu installieren und die SPS nur noch als Client mit dem OPC Server kommunizieren zu lassen....
Hat jemand Erfahrung mit einer solchen Konstellation ? Kann man damit Stabilität und Performanz verbessern im Vergleich zur oben beschriebenen Konstellation ?
Gibt es jemanden der ähnliche Erfahrungen mit dem integrierten OPC Server gemacht hat, der vielleicht beantworten kann, ob das "definieren" einer OPC Client Schnittstelle (mit der holprigen Laufnummerierung) hier schon mehr Stabilität bringen kann ?
Interessant ist, das Siemens selber hier angibt, dass die CPU`s mit neueren Artikelnummern etwas schneller geworden sind hinsichtlich OPC Komm.
Innovierte CPU Komm.
Hat jemand hiermit positive Erfahrungen gemacht ?
Grüße und Danke!
ich hatte bereits mehrmals mit dem "integrierten" OPC UA Server von Siemens CPU`s zu tun. Einmal in Form einer Kommunikation zwischen einer C#/.NET basierten Anwendung welche als OPC Client mit der CP(1512er) kommuniziert hat. Dabei ging es um das Auslesen von diversen Daten, die zum Glück nicht zeitkritisch waren.
Ein weiteres Mal musste ich diverse 1517er als OPC Server implementieren die mit einer LabVIEW Software über das zugehörige OPC UA Toolkite (Client) kommunizierten und "relevante" Prozessparameter im stetigen Austausch waren.
In beiden Fällen habe ich die Nodes "subscribed" und habe diese über "Value Change Events" von Server Seite empfangen.
Zu meiner Enttäuschung gab es in beiden Konstellationen ominöse Performance-Probleme.
Das sah dann in etwa so aus: Die Schnittstelle läuft über kurz- bis mittelfristige Zeiträume relativ stabil. Aber es kommen sporadisch Fälle vor wo das Schreiben einer Node auf einmal 10s und mehr dauerte. Was eine unrealistische Anpassung der Connection Timeout Zeit erforderte. Das war vor allem bei 300+"registrierten" Nodes der Fall. In einem solchen Fall war auch immer eine Meldung im Puffer der CPU zu sehen, welche von "unbekannten Nodes" oder Ähnlichem sprach. Nur dass es keine unbekannten Nodes waren, sondern die CPU einfach mit der Suche nach dieser überfordert war in diesem Moment.
Ich muss jedoch eingestehen, dass ich für die OPC Schnittstelle im TIA Portal immer das Häkchen bei "Simatic Server-Standardschnittstelle" gesetzt hatte und keine explizite OPC Schnittstelle definiert habe. Das definieren einer OPC Client Schnittstelle ist doch sowieso irreführend, da dabei benannte Variablen/Nodes eine Laufnummerierung (z.B. "i=000038") bekommen. Das kann man doch niemandem erzählen...
Nun habe ich ein Projekt welches nochmal deutlich mehr Nodes für die OPC Komm beinhaltet (900+). Die Planung hatte sich wohl darauf verlassen, dass die OPC Funktionalität von SIEMENS als sehr zuverlässig gilt.
Mein derzeitiger Lösungsansatz ist wohl einen "softwarebasierter" OPC Servers (von ACCON/KEPWARE/ProSys) auf einem zusätzlichen Leitrechner zu installieren und die SPS nur noch als Client mit dem OPC Server kommunizieren zu lassen....
Hat jemand Erfahrung mit einer solchen Konstellation ? Kann man damit Stabilität und Performanz verbessern im Vergleich zur oben beschriebenen Konstellation ?
Gibt es jemanden der ähnliche Erfahrungen mit dem integrierten OPC Server gemacht hat, der vielleicht beantworten kann, ob das "definieren" einer OPC Client Schnittstelle (mit der holprigen Laufnummerierung) hier schon mehr Stabilität bringen kann ?
Interessant ist, das Siemens selber hier angibt, dass die CPU`s mit neueren Artikelnummern etwas schneller geworden sind hinsichtlich OPC Komm.
Innovierte CPU Komm.
Hat jemand hiermit positive Erfahrungen gemacht ?
Grüße und Danke!
Zuletzt bearbeitet:
