TCON erkennen ob Verbindung besteht

Alpini

Level-1
Beiträge
21
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Forengemeinde,

ich habe mich als blutiger SPS-Neuling herangewagt mittels TCP/offener Kommunikation (TCON, TSEND, TRECV) eine Verbindung von einer S7-CPU315-2 PN/DP zu einem selbst geschriebenen Windows-Programm aufzubauen. Dabei ist der PC die passive Gegenstelle (TCP-Listener). Die Verbindung wird auf Port 6001 erfolgreich aufgebaut und ich kann Daten auf beiden Seiten empfangen und auch senden.

Was ich bisher mir erhöhten Anstrengungen nicht herausfinden konnte ist, an was die SPS erkennen kann, ob eine TCP-Verbindung zum PC auch wirklich besteht. Egal ob ich den Listener am PC gestartet habe und die Steuerung sich dahin verbunden hat oder ob der Listener ausgeschalten ist, am TCON Baustein ändert sich kein Status oder anderes Bit was mir sagen könnte, ob der PC erreichbar ist. Hat hier jemand eine gute Idee?

Bisher habe ich mir erst einmal so beholfen, dass in dem Moment, in dem sich die Steuerung zum PC verbindet, vom PC ein Datenpaket an die Steuerung gesendet wird, welches die Steuerung veranlasst einen "PCistVerbunden"-Merker zu setzen. Wird der Listener am PC beendet, schickt der wiederum ein anderes Paket an die Steuerung woraufhin die Steuerung den gleichen Merker resettet. Dieses System funktioniert ab nur so lange, wie die Verbindung "im Guten" abgebaut wird. Wird das Ethernet Kabel gezogen oder der Listenerprozess stürzt ab, merkt die Steuerung scheinbar nichts davon. Eine weitere Alternative, die mir einfällt, wäre noch in regelmäßigen Abständen mit einem Timer von der Steuerung eine Art Watchdog Paket an den PC zu senden und auf eine Antwort innerhalb bestimmter Zeit zu warten, aber da scheue ich schon etwas den Aufwand. Das muss auch einfacher gehen, schließlich merkt mein Listener-Prozess am PC auch sofort, wenn die Steuerung nicht da ist.

Ich hoffe mal es gibt hier noch eine Hand voll Leute, die die offene Kommunikation nicht scheuen :)

VG, Stefan
 
Was ich bisher mir erhöhten Anstrengungen nicht herausfinden konnte ist, an was die SPS erkennen kann, ob eine TCP-Verbindung zum PC auch wirklich besteht. Egal ob ich den Listener am PC gestartet habe und die Steuerung sich dahin verbunden hat oder ob der Listener ausgeschalten ist, am TCON Baustein ändert sich kein Status oder anderes Bit was mir sagen könnte, ob der PC erreichbar ist. Hat hier jemand eine gute Idee?

Ich hab zwar mit der offenen Kommunikation noch nicht gearbeitet, aber ich hab mir grad mal die Beschreibung von Siemens und die Step 7 hilfe zu den Bausteinen angeschaut. TCON müsste die am Ausgang "DONE" anzeigen ob die Verbindung aufgebaut wurde. Die Sende- und Empfangs- FB´s sollten dies auch melden bzw. Meldung geben wenn das Senden oder Empfangen(bei einem Verbindungsfehler) nicht geklappt hat.

Wenn du allerdings nicht regelmässig sendest bzw. empfängst wird die SPS einen Verbindungsfehler auch nicht erkennen. Das einfachste wäre es da wohl, wenn du in regelmässigen Abständen ein Paket zum PC schickst und auf dessen Antwort wartest. Damit bekommst du mit ersten mit ob deine Verbindung noch steht und zweitens ob der PC noch korrekt läuft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich weiß nicht ob es noch jemanden interessiert, doch vielleicht stößt einmal jemand auf das gleiche Problem. Ich habe mittlerweile selbst eine recht zuverlässige Lösung gefunden, um im SPS-Programm zu erkennen, ob noch eine aktive TCP-Verbindung zum anderen Verbindungsendpunkt besteht:

Auch wenn man ihn nicht benötigen sollte, wenn der Empfangsbaustein TRCV permanent aufgerufen wird, kann man an diesem am Anschluss "Status" sehr schön erkennen, ob wirklich eine Verbindung besteht. Zieht man das Netzwerkkabel aus der Steuerung oder beendet den TCP-Clientauf PC-Seite, ändert sich der Status-Wert sofort auf den (Fehler-) Wert 80C4: "Temporärer Kommunikationsfehler" und Error wird true. Im verbundenen Zustand hat Status einen 7000er Wert. Das funktioniert innerhalb von Sekundenbruchteilen, ohne dass erst irgend welche Timeouts abgewartet werden müssen. Ich verwende eine CPU317-2 PN/DP welche als passiver TCP-Verbindungsteilnehmer konfiguriert ist (Listener) und auf PC-Seite die .net TCPClient-Klasse.

VG vom Alpini
 
TRCV Status und Abbruch der Verbindung

Wir arbeiten auch seit 1 Jahr mit TCON auf der CP319F, und verwenden auch den Status beim Receivebaustein TRCV mit Fehlernummer 0x80C4 bei einem Verbindungsabbruch (Kabel ausstecken).

Leider haben wir manchmal ein Problem beim Wiederienstecken des Kabel gehabt. Der Disconnectbaustein TDISCON meldet nie wieder den Status 0 zurück beim Versuch des Verbindungsabbaues in der SPS. Dann hängt sich der S7 Treiber einfach auf. Da hilft nur mehr ein/und ausschalten.

Was Kommunikation angeht ist Siemens mit den T-Bausteinen auf der CP319 nicht unbedingt Industriestandard. Daher arbeiten wir jetzt wieder mit den CP343-Lean und den alten Bausteinen. Dort funktioniert alles zuverlässig.
 
+

Ein Heartbeat in beide Richtungen checkt nicht nur die Hardware, sondern auch noch den Zustand des Servers und des Clients.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Krauser: gut zu wissen, einen CP343-1 hätte ich nämlich noch rumliegen. Ich musste übrigens auch noch feststellen, dass die TCP Kommunikation unserer CPU 315-2 PN/DP mit Firmware 2.6.0 anders konfiguriert werden muss als bei unserer CPU 317-2 PN/DP mit Firmware 2.3.2. Letztere lässt sich nur im TCP-Kompatibilitätsmodus betreiben (einstellung im UDT65-DB), habe das aber nur zufällig herausgefunden, gelesen habe ich das noch nirgends (fand ich nicht so toll). Bei der Konfiguration als aktiver Verbindungsendpunkt verhalten sich diese zwei CPUs auch völlig unterschiedlich wenn man mit TCON versucht eine Verbindung zu einer Gegenstelle aufzubauen, die noch nicht verfügbar ist. Die CPU 315 sendet sehr moderat ca. aller 2 s TCP SYNC Pakete in Richtung Gegenstelle - das ist so ok (RX/TX LED blinkt ab und zu). Die ältere CPU 317 überflutet bei der gleichen Aktion das Netzwerk mit TCP-Sync Paketen (ca. 30 pro Sekunde) - irgendwie sehr unsinnig dieses Verhalten (RX/TX LED leuchtet durchgängig).

@arcis: ja, die Idee hatte ich aus der Not heraus ja ganz am Anfang schon und es dürfte die Methode sein, die am zuverlässigsten alle Ausfallarten erkennt. Ich konnte mich nur noch nicht so richtig damit abfinden, da das TCP-Protokoll ja eigenständig TCP-Keepalive Pakete sendet.
 
Ich hab zwar mit der offenen Kommunikation noch nicht gearbeitet, aber ich hab mir grad mal die Beschreibung von Siemens und die Step 7 hilfe zu den Bausteinen angeschaut. TCON müsste die am Ausgang "DONE" anzeigen ob die Verbindung aufgebaut wurde. Die Sende- und Empfangs- FB´s sollten dies auch melden bzw. Meldung geben wenn das Senden oder Empfangen(bei einem Verbindungsfehler) nicht geklappt hat.

Wenn du allerdings nicht regelmässig sendest bzw. empfängst wird die SPS einen Verbindungsfehler auch nicht erkennen. Das einfachste wäre es da wohl, wenn du in regelmässigen Abständen ein Paket zum PC schickst und auf dessen Antwort wartest. Damit bekommst du mit ersten mit ob deine Verbindung noch steht und zweitens ob der PC noch korrekt läuft.

Das Senden eines zyklischen Watchdog Signals ist eine gute Methode um die Verbindung zu kontrolieren. So kann man z.B. auch nach einem definierten Timeout des Watchdog Signals die Verbindung mit TDISCON kontrolliert beenden und anschliessend (nach einer kurzen Unterbrechung) den Verbindungsaufbau neu initiieren. Das kann recht hilfreich sein um den Blockstatus und eventuell definierte Watchdog Monitoring Bits zu ueberwachen.
 
Wir haben ein zyklisches Heartbeat-Signal

Danke für den Hinweis, aber wir haben alle 10 Sekunden ein zykllisches Heartbeat Protokoll zwischen Linux-Server mit RFC1006 und unserern SPSen laufen.

Die Info mit dem "DONE" ist richtig, aber unser Problem war ein anderes. Wir hatten eine Kommunikation aufgebaut und das DONE ware gesetzt. Dann haben wir im Status vom TRCV erkannt, dass die Verbindung abgebrochen wurde (Kabel ab oder Server bootet).

Dann wollten wir das TDISCON anstossen, aber diese Aktion wurde vom Trieber ignoriert, wir erhielten nie den Status 0 vom TDISCON zurueck. Und wenn das passiert, dann ist die Verbindung gestorben, auch wenn du das Kabel wieder angesteckt wurde und das Connect aufgerufen wird.

Siemens hat jetzt aber laufend die Firmware in der CP319F geändert. Vielleicht wurde dieser Fehler mittlerweile behoben. Ich werde das im Juni testen und Bescheid geben, ob dieser Bug behoben wurde.
 
Zurück
Oben