TIA Abbruch TCP Datenverbindung erkennen

[Zombie]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben eine Anlage modernisiert, bei welcher wir die alte S5 gegen eine neue 1516 getauscht haben. Die Kommunikation mit den anderen Systemen funktionierte früher über eine doppelt serielle Datenschnittstelle über welche Telegramme mit 60Byte Länge übertragen wurden. Zur Kopplung der neuen Anlage benutzen wir Seriell/Ethernet Koppler der Fa. WuT.
Es gibt kein Livebit oder Lebenstelegramm, sondern die Kommunikation erfolgt spontan.

Wie kann ich nun sicher erkennen, dass die Verbindung zum Koppler Ethernetseitig abgebrochen ist.

Hintergrund ist, einzelne Anlagenteile haben eine relativ wacklige Energieversorgung (ist einfach so) und steigen einfach mal so aus, kommen dann aber nach wenigen Sekunden wieder. Normalerweise bleibt das ohne folgen, die TCP Verbindung baut sich wieder auf. Aber hin und wieder klappt das nicht. Wie kann ich diese Fälle erkennen und dann z.B. eine Fehlermeldung ausgeben? Oder TCon erneut aufrufen?

Bisher frage ich den Status des TRcv Bausteins ab, ob dieser den Status 70XX verlässt und bisher gab es damit keine Probleme. Bei dieser Anlage zeigt sich aber dass dieser Weg wohl seine Grenzen hat, denn es wird keine Fehlermeldung angezeigt, der Kunde besteht aber drauf, dass er die Verbindung über einen manuellen Aufruf von TDIscon/ TCon neustarten musste.

Danke

 

[Thomas_v2.1]

Welche Seite baut denn die Verbindung auf?
Ansonsten könnte man wenn auch etwas holzhammermäßig die Verbindung z.B. nach 5 oder 10 Sekunden Inaktivität trennen und dann neu aufbauen. Ohne etwas zu senden/empfangen weißt du nicht ob der Socket noch gültig ist.

 

[Zombie]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die SPS ist der aktive Partner, das hab ich vergessen.

 

[Thomas_v2.1]

Wenn du normalerweise nur Daten empfängst ist das schwierig. Wenn du zumindest irgendwelche Statuswerte schicken kannst welche das Gerät ignoriert (oder Steuercodes), dann würde zumindest nach Ablauf der Timeouts der Socket als ungültig erkannt und du kannst ihn daraufhin neu aufbauen.

Evtl. kannst du auch auf UDP wechseln, denn da hast du das Problem mit hängenden Verbindungen nicht. Du musst dafür aber unter Umständen ein paar andere Dinge beachten, wie dein Gerät muss damit klarkommen können, dass auch mal ein Telegramm verloren geht und es dann selber wiederholen können, oder es muss neu angefordert werden können.

 

[Zombie]

Telegrammwiederholungen hab ich bereits drin, die Teilnehmer quittieren auch jedes Telegramm. Auf UDP zu wechseln wäre also möglich. Aber muss ich dafür nicht trotzdem ne Verbindung aufbauen? Es findet bei UDP doch nur keine Paketkontrolle statt?

Ich habe eine Verbindung die ist nur zum Empfangen und eine die ist zum Senden. Doppelt Seriell, weil einmal zum Senden, einmal zum Empfangen, deshalb 2 Koppler pro Teilnehmer.

Die Koppler scheinen hierbei jedoch das Problem zu sein. Die schließen all paar Sekunden die Verbindung und bauen sie neu auf. Ich hab noch nicht rausgefunden wie ich das einstellen kann dass die die Verbindung offen halten.

 

[Bl000b3r]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schonmal mit T_DIAG beschäftigt ? Müsste genau das sein, was du suchst

 

[Zombie]

Schonmal mit T_DIAG beschäftigt ? Müsste genau das sein, was du suchst

Kenne ich noch nicht, sieht aber oberflächlich erstmal genau danach aus

 

[Thomas_v2.1]

Telegrammwiederholungen hab ich bereits drin, die Teilnehmer quittieren auch jedes Telegramm. Auf UDP zu wechseln wäre also möglich. Aber muss ich dafür nicht trotzdem ne Verbindung aufbauen? Es findet bei UDP doch nur keine Paketkontrolle statt?

UDP ist verbindungslos. Das Problem in deinem Fall ist das folgende: Es wird eine TCP-Verbindung aufgebaut. Wenn dann dein Gateway spannungsfrei geschaltet wird und zwischen SPS und Gateway noch ein Switch liegt, dann bleibt für die SPS die TCP Verbindung gültig. Ohne vom SPS-Programm aus Daten abschicken zu wollen, kann nicht festgestellt werden, dass die Verbindung überhaupt nicht mehr gültig ist.

Der Unterschied bei UDP ist eben, dass es diesen Verbindungszustand nicht gibt. Deine SPS geht z.B. als UDP Server auf Empfang, und dein Gateway kann in jedem Zustand einfach ein UDP Paket an die SPS schicken, bekommt aber auch nicht mit ob das Paket überhaupt angekommen ist um es ggf. nochmal zu senden (bei TCP z.B. 3 mal bis dann die Verbindung als nicht gültig erkannt wird).

 

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schonmal mit T_DIAG beschäftigt ? Müsste genau das sein, was du suchst

Kenne ich noch nicht, sieht aber oberflächlich erstmal genau danach aus

Kannst du sowohl als aktiver als auch als passiver Verbindungsteilnehmer laufen lassen.



Wir lassen das normalerweise mit einem Taktmerker laufen. Je nach dem wie wichtig die Verbindung ist, respektive wie schnell du wissen musst ob die Verbindung abgebrochen wurde, rufst du ihn öfter oder weniger oft auf.

 

[Thomas_v2.1]

T_DIAG wird hier nicht weiterhelfen, weil das nicht aktiv testet ob die Verbindung funktioniert. Der wirkliche Fehlerzustand der Verbindung kann nur erkannt werden wenn etwas gesendet wird, und das Versenden nach üblicherweise drei Sendeversuchen nach Ablauf der Timeout-Zeiten nicht bestätigt wurde. Die einzige Möglichkeit den Zustand ohne etwas zu senden festzustellen, sind Keep-Alive Telegramme. Da gibt der Standard aber feste Zustände vor, wann es überhaupt erlaubt ist solche Telegramme zu senden. Auf TCP-Ebene dauert darum das Erkennen des Fehlerzustandes auf Protokollebene meistens um die 30 Sekunden. Wer es schneller braucht, der muss es auf Anwendungsebene umsetzen.

 

[Bl000b3r]

T_DIAG wird hier nicht weiterhelfen, weil das nicht aktiv testet ob die Verbindung funktioniert. Der wirkliche Fehlerzustand der Verbindung kann nur erkannt werden wenn etwas gesendet wird, und das Versenden nach üblicherweise drei Sendeversuchen nach Ablauf der Timeout-Zeiten nicht bestätigt wurde. Die einzige Möglichkeit den Zustand ohne etwas zu senden festzustellen, sind Keep-Alive Telegramme. Da gibt der Standard aber feste Zustände vor, wann es überhaupt erlaubt ist solche Telegramme zu senden. Auf TCP-Ebene dauert darum das Erkennen des Fehlerzustandes auf Protokollebene meistens um die 30 Sekunden. Wer es schneller braucht, der muss es auf Anwendungsebene umsetzen.

T_DIAG funktioniert nur komplett wenn es eine in der Hardware projektierte Verbindung ist. Und er muss natürlich regelmäßig angetriggert werden (Sytemtakt etc.).

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

T_DIAG funktioniert nur komplett wenn es eine in der Hardware projektierte Verbindung ist. Und er muss natürlich regelmäßig angetriggert werden (Sytemtakt etc.).

Das dauert aber trotzdem im ungünstigsten Fall wenn nichts anderweitig gesendet wird, bis zum nächsten Keep-Alive Intervall + TCP timeout.
Mal angenommen es ist bei einer projektierten Verbindung ein Keep Alive von 30 Sekunden eingestellt. Das letzte Keep Alive wurde erfolgreich bestätigt, T_DIAG sagt "Verbindung steht". Dann schalte ich den Verbindungspartner spannungsfrei, dann stellt dein T_DIAG für die nächsten 30 Sekunden + TCP timeout immer noch fest "Verbindung steht". Erst wenn die Zeiten abgelaufen steht der Zustand des Verbindungsausfalls fest.

Ob bei TCP Verbindungen aus dem SPS-Programm heraus (Mit den T-Bausteinen) überhaupt und in welchem Intervall Keep Alive Telegramme verschickt werden habe noch nicht finden können. Ich meine aber, dass es mal ein Problem hier im Forum gab was ebenfalls auf 30 Sekunden hindeutete (bei S7-300).