TIA TCP Verbindung - CPU aktiver Verbindungsaufbau - funktioniert nicht richtig

[Zonder]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe ein Problem mit einer TCP-Verbindung zwischen einer CPU '1515F-2PN' und einem Drucker von 'Markem Imaje' (Im Programm als 'InkjetPrinter' bezeichnet).
Die Verbindung habe ich in der HW-Konfig projektiert (es wird kein TCON verwendet) und die CPU baut aktiv die Verbindung auf (aktiver Verbindungsaufbau = Hacken ist drin).
Im Programm werden lediglich die Bausteine TSEND und TRCV verwendet.

Das ganze funktioniert eigentlich ohne Probleme, bis ich den Drucker entweder Aus und wieder Einschalte oder bis ich einfach den Netzwerstecker einmal abzieh und wieder drauf stecke.

Normaler Weise müsste die CPU ja die Verbinung zum Gerät wieder aufbauen - doch das tut sie nicht. Erst wenn ich die CPU STOPPE und wieder auf RUN stelle, wird die Verbindung wieder GRÜN.
Durch den CPU STOP wird ja laut Hillfe die Verbindung abgebaut und wieder aufgebaut.

Firmware der CPU ist V2.6, das Programm wurde mit TIA V15.1 erstellt.


Weis Jemand von euch warum die CPU die Verbindung nicht mehr aufbauen kann?
Unter der Diagnose sieht man, das der Verbindungszähler 'Verbindungsaufbauversuche = 167' alle paar Sekunden hochgeht, jedoch wird die Verbindung nicht aufgebaut.
Eigentlich müsste die CPU erstmal die Verbindung abbauen und danach erst wieder aufbauen - so wie wenn ich die CPU auf STOP und anschließend wieder auf RUN stelle.

Dieses Verhalten habe ich nur mit dieser TCP-Verbindung, die anderen Verbindungen funktionieren auch wenn man den Stecker absteckt und wieder draufsteckt.

 

[escride1]

"lokaler TSelector bereits verwendet" sagt Dir nichts?
Verbindung zurückgesetzt? Würde ich versuchen.

 

[Zonder]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was meinst du mit "Verbindung zurückgesetzt? Würde ich versuchen." ?
TDISCON ausführen?

Ich habe die Verbindung ja auch nicht über TCON hergestellt, sondern in der HW-Konfig angelegt. Da müsste die CPU das ja eigentlich selber machen oder nicht?


Auszug aus der TIA Hilfe:

Verbindung bei TCP und ISO‑on‑TCP


Beide Kommunikationspartner rufen die Anweisung "TCON" zum Einrichten und Aufbauen der Kommunikationsverbindung auf. In der Parametrierung hinterlegen Sie, welcher der aktive und welcher der passive Kommunikationsendpunkt ist.


Bei Verbindungsabbruch durch z. B. Leitungsunterbrechung oder durch den remoten Kommunikationspartner versucht der aktive Partner, die eingerichtete Verbindung wieder aufzubauen. Sie müssen "TCON" nicht erneut aufrufen. Dies gilt jedoch nur, wenn "TCON" einmal erfolgreich durchlaufen wurde (DONE = 1).


Mit der Ausführung der Anweisung "TDISCON" oder im Betriebszustand STOP der CPU wird eine bestehende Verbindung abgebrochen und die eingerichtete Verbindung entfernt. Zum erneuten Einrichten und Aufbauen der Verbindung müssen Sie "TCON" erneut ausführen.

Leider finde ich nichts dazu, was man bei einer projektierten (und nicht programmierten) Verbindung machen soll. Man führt ja auch kein TCON aus.


Hab noch was in der Hilfe gefunden:

Programmierte Kommunikationsverbindungen

In bestimmten Anwendungsbereichen ist es vorteilhaft, die Kommunikationsverbindungen nicht über die Projektierung statisch einzurichten. Alternativ besteht daher die Möglichkeit, bestimmte Verbindungstypen über eine spezifische Applikation programmgesteuert und damit bei Bedarf dynamisch einzurichten.

Wahrscheinlich muss man zu diesem Drucker trotzdem die Verbindung nicht statisch anlegen, sondern mit TCON und TDISCON arbeiten.

 

[escride1]

Nein, Du sollst nicht mit TCON arbeiten.

Du nutzt eine Verbindung die immer aktiv ist und sobald Du sie brauchst sendest und empfängst Du. Das ist ja okay. Eigentlich sollte es funktionieren.

Ich aber habe bereits Probleme damit gehabt und seitdem überwache ich immer alle meine aufgebauten Verbindungen sowie das Senden meiner Daten. Wenn diese dann einen Fehler haben nutze ich T_RESET um die Verbindung ab und wieder aufzubauen. Das ist fast das gleiche wie das was die CPU macht wenn sie in STOP geht. Fast immer funktioniert es damit bei mir, nur bei ganz unangenehmen Partnern geht es nicht, dort muss man auf den Timeout warten bis er erkennt das die Verbindung gar nicht mehr da ist. Aber da funktionieren dann auch statische Verbindungen ganz schlecht.

Durch T_RESET wird also die angegebene Verbindung gekappt und wieder aufgebaut, unabhängig davon ob gerade gesendet oder empfangen wird oder nicht. Es hackt also die Verbindung ab, gibt die Ressourcen wieder frei und baut die Verbindung dann wieder auf.

Auszug aus dem Informationssystem:

Beschreibung
Die Anweisung "T_RESET" baut eine bestehende Verbindung ab und wieder auf.
Die lokalen Endpunkte der Verbindung bleiben dabei erhalten. Diese werden automatisch erzeugt:

• Wenn eine Verbindung konfiguriert und in die CPU geladen wurde.
• Wenn eine Verbindung durch das Anwenderprogramm erzeugt wurde, beispielsweise durch den Aufruf der Anweisung "TCON".

Die Anweisung "T_RESET" lässt sich für alle Verbindungsarten (TCP, UDP, ISO-on-TCP,...etc.) durchführen. Hierbei spielt es keine Rolle, ob für die Verbindung die lokale Schnittstelle der CPU oder die Schnittstelle eines CMs/CPs verwendet wurde.
Nach Aufruf der Anweisung "T_RESET" über den Parameter REQ wird die über den Parameter ID angegebene Verbindung abgebaut und ggf. die Puffer zum Senden und Empfangen von Daten geleert. Mit der Unterbrechung der Verbindung werden auch laufende Datenübertragungen unterbrochen. Dabei besteht die Gefahr, dass bei einer laufenden Übertragung Daten verloren gehen können. Danach versucht die als aktiver Verbindungspartner definierte CPU automatisch, die unterbrochene Kommunikationsverbindung wieder herzustellen. Der Aufruf der Anweisung "TCON" zum erneuten Aufbauen der Kommunikationsverbindung ist deshalb nicht notwendig.
Über die Ausgangsparameter DONE, BUSY und STATUS wird der Zustand des Auftrags angezeigt.