TIA Redundante Open User Communication

vollmi

Level-3
Beiträge
5.457
Reaktionspunkte
1.420
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen

Ist ja sicher immer wieder ein Thema dass man eine Kommunikationsverbindung über redundante Pfade realisieren will. Siemens hat da auch einen schönen Baustein gebaut der grundsätzlich funktioniert.
https://support.industry.siemens.com/cs/document/109763719/redundant-open-user-communication?dti=0&lc=en-CH
Nicht verunsichern lassen, das funktioniert auch bei nicht R/H Steuerungen untereinander.
Was bei diesem Aufbau allerdings nicht so schön ist, ist das Verhalten bei einer funktionierenden Verbindung.
Mal zum Ablauf
  1. Der Baustein auf der passiven Seite baut je nach Konfiguration 2 bis 4 wartende Verbindungen auf.
  2. Der Baustein auf der aktiven Seite versucht auf eine der konfigurierten Verbindungen eine aktive Verbindung aufzubauen
  3. Sobald eine Verbindung steht, baut die passive Seite die nicht genutzten Verbindungen ab und baut eine zusätzliche Prüfverbindung auf.
  4. jetzt sind zwei aktive Verbindungen zwischen den Steuerungen aufgebaut, eine worüber die Nutzdaten übertragen werden, eine worüber die Prüfdaten ausgetauscht werden
Wenn die Prüfung nicht erfolgreich ist, beginnt das Ganze wieder bei 1.

Wenn ich jetzt aber alle Wege immer geprüft haben will. Bleibt mir eigentlich nichts übrig als für jeden Weg eine Verbindung aufzubauen und stehen zu lassen.
Das heisst z.B. bei einer Kommunikation zwischen zwei H Steuerungen. 4 Stehende Verbindungen über die Daten ausgetauscht werden.
Nämlich
  • aktivX1Kopf1 zu passivX1Kopf1
  • aktivX1Kopf1 zu passivX1Kopf2
  • aktivX1Kopf2 zu passivX1Kopf1
  • aktivX1Kopf2 zu passivX1Kopf2
Dabei hätten ja beide H und R Steuerungen ja eine SystemIP Adresse über die sie ansprechbar sind. Aber TCON muss immer auch die lokale Hardwareadresse haben und die gibts nicht als Systemadresse.
Jetzt frage ich mich, gibt es eine Kommunikationsart die nicht explizit die Hardwareadressen nutzt sondern welche die Kommuikation nur über die SystemIP aufbaut und somit selbständig den Weg zum Partner nutzt?
 
Jetzt frage ich mich, gibt es eine Kommunikationsart die nicht explizit die Hardwareadressen nutzt sondern welche die Kommuikation nur über die SystemIP aufbaut und somit selbständig den Weg zum Partner nutzt?
Ich benutze die Systemadresse des 1500-H.
Zur OUC Kommunizierung verwende ich TSEND_ und TRCV_C

Über den Werkzeugkastensymbol kann du die Verbindung konfigurieren.
DB mit verbindungsparameter wird automatisch am Baustein (TSEND_ / TRCV_C) angebunden
Auf die Gegenstelle wird im Systemdaten ein baustein generiert mit Verbindungsdaten die du dann für die gegenstelle benutzt.

Die verbindung Funktioniert auf die Stelle und redundant.
Bloß kommt er mir ein bischen instabil vor. Ich habe zur not die CPU#s stoppen müssen. Auch das H-System.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich benutze die Systemadresse des 1500-H.
Zur OUC Kommunizierung verwende ich TSEND_ und TRCV_C

Über den Werkzeugkastensymbol kann du die Verbindung konfigurieren.
DB mit verbindungsparameter wird automatisch am Baustein (TSEND_ / TRCV_C) angebunden
Auf die Gegenstelle wird im Systemdaten ein baustein generiert mit Verbindungsdaten die du dann für die gegenstelle benutzt.

Die verbindung Funktioniert auf die Stelle und redundant.
Bloß kommt er mir ein bischen instabil vor. Ich habe zur not die CPU#s stoppen müssen. Auch das H-System.
Das ist interessant. IMHO ist es doch so dass die SystemHardwareID
Local1~PROFINET-Schnittstelle_2~HsystemIPRef_1
die der Konfigurator nimmt, verschwindet wenn die CPU Local1 spannungslos ist und dann die Kommunikation nicht mehr funktioniert. denn es gibt ja noch die System HardwareID
Local2~PROFINET-Schnittstelle_2~HsystemIPRef_1 für die zweite CPU

Habt ihr Ausfälle getestet?
 
Okay ich bin verwirrt. scheinbar scheint das mit der SystemID zu gehen, Wozu gibts denn überhaupt die RedundanzLibrary?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sei doch froh😉
Vielleicht kommt das noch aus der Zeit, als es die System-IP-Adresse noch nicht gab. Oder zur Kommunikation von 1500H mit 400H...🤷‍♂️
Natürlich bin ich froh. Wollte nur sicher sein dass ich das verstehe. 400H wäre eine Möglichkeit. Wäre es bei der 1500H möglich, hätte ich da wie bei der 400H einfach zwei S7 Verbindungen gezogen, bzw. H Untereinander mit S7-faulttollerant verbunden.
Aber nun ist halt OUC das Mass der Dinge. Hat dafür den Vorteil dass man nur an einem Ort Verbindungen projektiert und diese dynamisch sind.
 
Das ging ja in Klassik NetPro auch.
Ich ziele eher auf wenn du ne einfache 1500er hast. Dann musst du nicht stoppen.
Bei Classic habe ich kein Projekt mit OUC Verbindung gemacht.
Ja, bei 400-H konnte mann schon immer ohne stop laden.

Aber nun ist halt OUC das Mass der Dinge. Hat dafür den Vorteil dass man nur an einem Ort Verbindungen projektiert und diese dynamisch sind.
Überigens bei Anbindung HMI auf einwandfreie Function.
 
Bloß kommt er mir ein bischen instabil vor. Ich habe zur not die CPU#s stoppen müssen. Auch das H-System.
Ich glaube zu wissen wo der Scheiß herkommt.
Also heute ausprobiert bei eine der Kommunikationen.
Ich habe das h System und 4 einzelne 1500 SPS womit ich kommuniziere.

Die 4 einzelne SPS sind identische Projekten wo auch der Kommunikationbaustein kopiert ist.
Bloß mit andere Einstellungen im Hintergrund.
Aber irgendwie nehmt er die Einstellungen von SPS "A" mit in SPS B, C und D.

Also den komplette Verbindungen löschen und jede einzelne separat wieder neu Anlegen.
Statt die Einstellung an zu passen.
 
Zurück
Oben