TIA OPC UA Kommunikation begrenzt

[Draeger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin

Ich arbeite im Moment an meiner Bachelorarbeit und beschäftige mich aktuell mit der OPC UA Kommunikation zwischen zwei S7-1515F.
Ich habe eine funktionierende Kommunikation aufgebaut und kann sowohl Variablen lesen als auch schreiben.
Jedoch habe ich jetzt das Problem, dass es eine Begrenzung auf 25 Zugriffe pro Minute zu geben scheint. Sobald ich innerhalb einer Minute 25 Zugriffe erreiche, erhalte ich beim Verbindungsaufbau die Fehlermeldung 8081 BadTCPNotEnoughResources.
Wenn ich 24 Anfrage starte und eine Minute warte, kann ich ohne Probleme weitere 24 Anfragen starten.

Hat irgendjemand eine Idee woran das liegen könnte? Klingt stark nach einer Einstellung.
Vielleicht bin ich aber auch einfach nur zu blöd

Vielen Dank schon mal im Voraus!

 

[blackpeat]

Was für eine Lizenz hast du eingestellt?

Vielleicht ist deine zu klein. Unter Runtime Lizenzen in den Einstellungen der CPU

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

das hat mit der lizenz nichts zu tun. du überforderst einfach nur den opc-server.

 

[Ing_Lupo]

Hallo

Wäre interessant zu wissen wieviel Bytes angefordert
werden.

 

[volker]

wie tauscht du die daten aus? über schreib-/leselisten (hab ich noch nicht getestet) oder über methoden?

zu den methoden kann ich sagen...
die meiste zeit nimmt der connect in anspruch. (mit authenthisierung dauert das um einiges länger (siehe link zum siemens-forum im link2))
hält man die verbindung aufrecht und ruft auch nicht wieder die handle-listen etc ab geht der methodenaufruf recht schnell.
ich hatte das mit ca 500 byte daten getestet.
ich stell morgen mal einen scrennshot rein wo man sehen kann welcher teil der kommunikation wieviel zeit verbraucht hat.


weitere links
https://www.sps-forum.de/simatic/97342-opc-ua-client-mit-server-verbinden.html?highlight=methoden
1500er als OPC UA Client. ERROR 8018

zusätzlich kommt noch hinzu, dass dir der ständige aufruf gar nichts bringt.
die max aktualisierungszeit des opc-servers bei einer 1518 ist 50ms. bei einer 1512 500ms. bei der 1515 wird das also bei 100 oder 200 ms liegen.
bei den methoden ist das, soweit ich weiss, anders. da ist der mechanismus ein anderer.

 

[Draeger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Abgerufen wird ein Array aus 37 Worten.
Die Daten werden über Schreibe- und Leselisten ausgetauscht. Mit Methoden habe ich noch keine Erfahrung.
Ist es denn möglich, die Verbindung einmal aufzubauen und während der Laufzeit aufrecht zu erhalten? Wenn ja, kann mir jemand ein Beispiel geben? Ich habe dabei Probleme gehabt, in beide Richtungen Daten schreiben/lesen. Kann aber auch irgendwo ein dämlicher Fehler drin gewesen sein.

 

[blackpeat]

Hast du mal getestet ob das auch mit UAExpert oder so auftritt oder nur mit deinem Client?

Weil wir haben, zwar bei einer S1507SF, an die 800-1000 Subscriptions und es gibt keine Probleme und auch bei kleinen CPU's sollten die paar kein Problem sein.

 

[Hans]

Abgerufen wird ein Array aus 37 Worten.
Die Daten werden über Schreibe- und Leselisten ausgetauscht. Mit Methoden habe ich noch keine Erfahrung.
Ist es denn möglich, die Verbindung einmal aufzubauen und während der Laufzeit aufrecht zu erhalten? Wenn ja, kann mir jemand ein Beispiel geben? Ich habe dabei Probleme gehabt, in beide Richtungen Daten schreiben/lesen. Kann aber auch irgendwo ein dämlicher Fehler drin gewesen sein.

Die Verbindung solltest du auf jeden Fall aufrecht erhalten, da es sonst du dem von dir genannten Fehler kommt. Eine erneute Verbindung bzw ein Abbau der Verbindung ist nicht nötig (es sei denn dein Prozess erfordert es, oder es kommt zu einem Fehler).
In SIOS findest du einen fertigen Baustein:
https://support.industry.siemens.com/cs/de/de/view/109762770

 

[Hans]

Zuviel Werbung?
-> Hier kostenlos registrieren

zusätzlich kommt noch hinzu, dass dir der ständige aufruf gar nichts bringt.
die max aktualisierungszeit des opc-servers bei einer 1518 ist 50ms. bei einer 1512 500ms. bei der 1515 wird das also bei 100 oder 200 ms liegen.
bei den methoden ist das, soweit ich weiss, anders. da ist der mechanismus ein anderer.

Die Sampling Zeit hat nichts mit Lese und Schreibzugriffen zu tun. Die finden nur bei Subscriptions anwendung.

 

[volker]

so hier mal die screenshots mit den ausführungszeiten.
übertragen werden 50 wstring der länge 10. also ca 1200 byte.
cpu: 2 x 1516f

 

[Ralle]

@Volker
Darf ich mal fragen, warum man zwischen 2 1500-er SPS Daten per OPC-UA austauscht?
Bringt das Vorteile, gegenüber PUT/GET oder SEND/RECEIVE?
Braucht man eine gesonderte Bibliothek?

 

[Draeger]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Volker
Vielen Dank erstmal für die Hilfe!
Kannst du mir zufällig mal ein Beispiel hier posten, wie ich eine Verbindung aufbaue und aufrecht erhalte?
Ich hab aktuell Probleme mich bei SIOS einzuloggen, irgendwas scheint da nicht zu stimmen.

 

[Blockmove]

@Volker
Darf ich mal fragen, warum man zwischen 2 1500-er SPS Daten per OPC-UA austauscht?
Bringt das Vorteile, gegenüber PUT/GET oder SEND/RECEIVE?
Braucht man eine gesonderte Bibliothek?

OPC UA entwickelt sich zum Standard Protokoll für Datenübertragung im Industrieumfeld.
Vorteile gibt es viele:
Plattformübergreifend
Sicher
Kein Ärger mit Adressen, Bytefolge
...

Für den Server brauchst du keine Bausteine.
Für Client und Methoden sind Bausteine erforderlich.

Für die reine S7-Kommunikation kannst du auch Put/Get nehmen.
Es schadet aber nicht sich mit OPC UA zu beschäftigen.

Gruß
Blockmove

 

[vollmi]

Dazu kommt noch. Da immer mehr Anlagen auch im WWW hängen und das immer einen Angriffspunkt bietet.
OPC bietet halt die möglichkeit Verbindungen zu verschlüsseln und die Endpunkte zu zertifzieren, was Angriffsfläche verkleinert.

PUT/Get gehört aber definitiv nicht mehr in aktuelle Anlagen.

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Volker
Darf ich mal fragen, warum man zwischen 2 1500-er SPS Daten per OPC-UA austauscht?
Bringt das Vorteile, gegenüber PUT/GET oder SEND/RECEIVE?
Braucht man eine gesonderte Bibliothek?

Das war nur zum testen. Normal soll die 1500er mit einem PCo von MES/SAP kommunizieren.
Kriegt die IT aber leider nicht hin. Problem ist, so wie es aussieht, das der PCo-Server mit dem Hostnamen anstatt mit einer IP-Adresse läuft. Das kann die CPU nicht. Das kann mann auch mit einer entsprechenden konfiguration mit dem UA-Ansi-Server-Demo verifizieren.
Jetz bleiben wir bei der herkömmlichen Methode, dass der PCo eine Variable auf Wertänderung prüft.
Die entsprechenden Bausteine findet man unter Kommunikation. Wobei die Client-Methode erst ab 15.1 verfügbar ist (mit FW2.6).

Für eine Kopplung von 2 Steuerungen nehm ich auch lieber put/get oder send/rcv

 

[Hans]

Das war nur zum testen. Normal soll die 1500er mit einem PCo von MES/SAP kommunizieren.
Kriegt die IT aber leider nicht hin. Problem ist, so wie es aussieht, das der PCo-Server mit dem Hostnamen anstatt mit einer IP-Adresse läuft. Das kann die CPU nicht.

Dafür bräuchtest du noch einen DNS Server im Netz, welcher den Namen zur IP auflöst. Diesen dann in der Hardware Konfiguration der PLC angeben.

 

[volker]

Einen DNS-Server haben wir natürlich im Firmennetz.
Aber wo kann ich bei der CPU einen DNS-Server auswählen?

Oder meinst du den Router?
Dort habe ich die Adresse des Firmenswitches (VLan) eingetragen

 

[Hans]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der Hardwarekonfiguration der CPU gibt es einen Reiter "DNS Server".
An dem Connect Baustein musst du dann allerdings auch die ServerEndpointUrl mit dem Namen wählen also "opc.tcp://MyServer:4840". Über den Client Schnittstellen Wizzard kannst du nur IPs eintragen, d.h. du musst das Ganze dann im Anwenderprogramm überschreiben, bzw. eine andere Variable nutzen.

 

[Blockmove]

Dazu kommt noch. Da immer mehr Anlagen auch im WWW hängen und das immer einen Angriffspunkt bietet.
OPC bietet halt die möglichkeit Verbindungen zu verschlüsseln und die Endpunkte zu zertifzieren, was Angriffsfläche verkleinert.

PUT/Get gehört aber definitiv nicht mehr in aktuelle Anlagen.

Naja Put/Get bzw. AG-Send/Receive wird uns noch lange erhalten bleiben. Trotz aller Nachteile und Sicherheitmängel.
Bei OPC UA fehlt noch Geschwindigkeit und auch eine bessere Integration in TIA. Aber das ist nur noch eine Frage der Zeit

 

[vollmi]

Naja Put/Get bzw. AG-Send/Receive wird uns noch lange erhalten bleiben. Trotz aller Nachteile und Sicherheitmängel.
Bei OPC UA fehlt noch Geschwindigkeit und auch eine bessere Integration in TIA. Aber das ist nur noch eine Frage der Zeit

Ich denke gegen AG_Send/Recv spricht nicht viel. Aber absichtlich auf einer 1500er die Sicherheit aufzuheben nur damit man wieder mit PUT/GET auf der Steuerung rumzufahren, sehe ich nicht ein. Das waren immer die zeitaufwändigsten Fehlersuchen die ich gehabt habe. Wenn fremde Steuerungen bei mir was geschrieben haben wo sie nix zu schreiben haben. Und heute wo man viele Steuerungen in dasselbe Physikalische Netz wenn auch in VLANS aufgeteilt bringt, da muss nur mal ein VLAN nicht richtig trennen und ne andere Steuerung n Tipfehler drin haben und schon hat man schräge querkommunikation die man kaum erkennt.