TIA Redundante Open User Communication

[vollmi]

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?

 

[de vliegende hollander]

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.

 

[vollmi]

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?

 

[vollmi]

Okay ich bin verwirrt. scheinbar scheint das mit der SystemID zu gehen, Wozu gibts denn überhaupt die RedundanzLibrary?

 

[ducati]

Okay ich bin verwirrt. scheinbar scheint das mit der SystemID zu gehen, Wozu gibts denn überhaupt die RedundanzLibrary?

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...

 

[vollmi]

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.

 

[de vliegende hollander]

Habt ihr Ausfälle getestet?

Ja, die redundanz is geprüft.

ich habe die Anlage noch im Prüfstand

 

[de vliegende hollander]

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.

Und laden ohne stop

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und laden ohne stop

Das ging ja in Klassik NetPro auch.

 

[de vliegende hollander]

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.

 

[de vliegende hollander]

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.

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nicht verunsichern lassen, das funktioniert auch bei nicht R/H Steuerungen untereinander.

Hast du diese Verbindung zufällig in Betrieb?

Ich programmiere mir die Verbindungen heute und läd sie am Montag auf das H-System.
Mal schauen ob das Verhalten verbessert.

Ich kann noch immer die Verbindung zum absturzen bringen so das die nicht wieder neu aufbaut.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Bearbeitung;

Wäre IO Controller ein Altermative?
mann kann eine Einzelne CPU (Nicht-H) 2 IO Controller zuweisen. Mehrfachzuweisung.
Einmal die Primary und einmal die backUp CPU.

 

[vollmi]

Hast du diese Verbindung zufällig in Betrieb?

Ja aber erst in einem Testrack. Allerdings zeigt sich bei mir, dass die Verbindung stehen bleibt, wenn eine CPU ausfällt (Spannungsfrei). Allerdings stoppt die Verbindung wenn ich das Ethernetkabel aus der Primärcpu ziehe. ich denke die HWID "Local1~PROFINET-Schnittstelle_2~HsystemIPRef_1" sich immer auf die Primary bezieht.

Ansonsten ist die Verbindung stabil Natürlich mit Angsttimer etc.

Wäre IO Controller ein Altermative?
mann kann eine Einzelne CPU (Nicht-H) 2 IO Controller zuweisen. Mehrfachzuweisung.
Einmal die Primary und einmal die backUp CPU.

Ich bin halt nicht so ein Fan der IO Controller verbindung. Ich mag das Gehampel mit den IOs nicht, genausowenig wie CPU Stop bei Grössenänderung.

 

[de vliegende hollander]

Ansonsten ist die Verbindung stabil Natürlich mit Angsttimer etc.

Ich projektiere sie gerade.
Ich traue den andere, mit die Systemadresse, nicht 100%

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich projektiere sie gerade.
Ich traue den andere, mit die Systemadresse, nicht 100%

Ich bin gerade am überlegen ob ich irgendwie rausfinden kann ob die "Local1~PROFINET-Schnittstelle_2~HsystemIPRef_1" gerade verfügbar ist. ohne dass ich da Testtelegramme durchsenden muss.
Dann könnte ich die Verbindung abbauen und mit "Local2~PROFINET-Schnittstelle_2~HsystemIPRef_1" wieder aufbauen.

 

[de vliegende hollander]

Ich bin schon längst froh wenn die Verbindung einwandfrei steht und zuverlässig läuft.

Ich habe im Moment die 4 Verbindungen zu meine einzelne SPS'n mit die LCommRed_ISOonTCP laufen.
Online sieht das echt wild aus, wenn die verbindungen aufgebaut und abgebaut werden.

Verbindung ist arsch langsam aber funktioniert .
Was hatst du für Zeiteinstellung am Testverbindung ich hab die imm auf standart 500mS?

 

[vollmi]

Ich habe im Moment die 4 Verbindungen zu meine einzelne SPS'n mit die LCommRed_ISOonTCP laufen.
Online sieht das echt wild aus, wenn die verbindungen aufgebaut und abgebaut werden.

Ah dann verwendest du doch den Redundanzbaustein?
Weil du geschrieben hast du nutzt den TRCV_C und das funktioniert über die Systemadresse.

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.

Ja dann werde ich das auch mit dem LCommRed machen. Mich stört etwas dass der LComRed geschützt ist, ich wüsste gerne wie die das machen?

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ah dann verwendest du doch den Redundanzbaustein?
Weil du geschrieben hast du nutzt den TRCV_C und das funktioniert über die Systemadresse.

Ja, ich hatte die auch benutzt.
Aber die zur SPS Kommunikation mit OUC war nicht stabil.

Als HMI Verbindung funktioniert es einwandfrei.

 

[vollmi]

Ja, ich hatte die auch benutzt.
Aber die zur SPS Kommunikation mit OUC war nicht stabil.

Ich mach es jetzt mal versuchsweise anders. ich nutze je möglichen Pfad einen TRECV_C zum verbindungsaufbau und lasse die Verbindung dann stehen. das würde z.B. zwischen zwei H, 4 stehende Verbindungen bedeuten. durch eine Sende ich die Daten die ich brauche. Durch die anderen sende ich ein prüfbyte somit habe ich zu jeder Zeit den Zustand der anderen Wege auch. Und die 1500 können ja mehr als genug Verbindungen. Da sehe ich den ganzen Klapperatismus von wegen eine Verbindung aufbauen und erst auf einen Ersatz wechseln wenn die nicht mehr geht und zu hoffen dass die anderen alle funktionieren nicht so prickelnd. Das ist Hoffnung als Taktik.

 

[de vliegende hollander]

Das hört sich gut an.
Dies kann ich testweise auch paralell zur jetzige Verbindung testen.