-> Hier kostenlos registrieren
Servus beisammen,
ich schreibe zur Zeit einen Treiberbausten in SCL für ein elektronisches Vorschaltgerät zum Schalten von UV-Lampen. Die S7-400 CPU kommuniziert über industrial Ethernet (CP 443-1) via Modbus/TCP Protokoll mit dem EVG. Der Baustein ist für die Verwendung im OB32 (1s Weckalarm) vorgesehen.
Grundsätzlich gibt es zwei Datentelegramme: 1. Statusabfrage (12 Byte ans EVG, 47 Byte Antwort vom EVG)
2. Command (49 Byte ans EVG, 12 Byte Antwort vom EVG)
Der Datenaustausch ist folgendermaßen geregelt:
1. Die zu sendenden Daten werden durch Abfrage der Ein- und Ausgänge generiert und in ein entsprechend langes Array geschrieben. AG_Send wird mit diesem Array aufgerufen.
2. Im nächsten Bausteinaufruf wird AG_Send nochmals mit den selben Parametern wie in Schritt eins aufgerufen, diesmal allerdings mit ACT = 0 um die Parameter "Done", "Error" und "Status" zu aktualisieren. Tritt ein Fehler auf, werden die Schritte eins und zwei wiederholt.
3. Wurde nach Schritt zwei durch Auswertung von "Done" bzw "Error" ein abgeschlossener Sendevorgang sichergestellt, wird AG_Recv mit einem entsprechend großen Array (durch Programmflags bekannt) aufgerufen. Die Parameter "LEN" und "Error" werden ausgewertet und ggf. wird Schritt drei wiederholt.
Das alles klappt auch so wie es soll und in der Regel braucht das Programm hierfür 4 Bausteinaufrufe. Um das Verhalten bei Verbindungsfehlern zu analysieren, habe ich das Ethernetkabel am EVG ausgesteckt und nach variierender Zeit wieder eingeteckt. In den meisten Fällen nimmt der Baustein die Kommunikation wieder auf, allerdings nicht wenn der Verbindungsausfall - wie ich annehme - unmittelbar während des Rücksendens (EVG an CP) eintritt.
Meine Annahme ist nun folgende:
Durch den abgebrochenen Rücksendevorgang liegen Daten ungleich der erwarteten Länge im Empfangsdatenpuffer des CP 443-1 wodurch ein undefinierter Offset entsteht. Die Daten können dann von AG_Recv nicht mehr richtig eingelesen werden, da die Datenlänge nicht mehr der Länge des Arrays entspricht.
Ist meine Annahme richtig? Kann das so vorkommen? Gibt es eine Möglichkeit den Empfangsdatenpuffer des CP zu löschen?
Vielen lieben Dank im voraus.
Mit freundlichen Grüßen
Max
ich schreibe zur Zeit einen Treiberbausten in SCL für ein elektronisches Vorschaltgerät zum Schalten von UV-Lampen. Die S7-400 CPU kommuniziert über industrial Ethernet (CP 443-1) via Modbus/TCP Protokoll mit dem EVG. Der Baustein ist für die Verwendung im OB32 (1s Weckalarm) vorgesehen.
Grundsätzlich gibt es zwei Datentelegramme: 1. Statusabfrage (12 Byte ans EVG, 47 Byte Antwort vom EVG)
2. Command (49 Byte ans EVG, 12 Byte Antwort vom EVG)
Der Datenaustausch ist folgendermaßen geregelt:
1. Die zu sendenden Daten werden durch Abfrage der Ein- und Ausgänge generiert und in ein entsprechend langes Array geschrieben. AG_Send wird mit diesem Array aufgerufen.
2. Im nächsten Bausteinaufruf wird AG_Send nochmals mit den selben Parametern wie in Schritt eins aufgerufen, diesmal allerdings mit ACT = 0 um die Parameter "Done", "Error" und "Status" zu aktualisieren. Tritt ein Fehler auf, werden die Schritte eins und zwei wiederholt.
3. Wurde nach Schritt zwei durch Auswertung von "Done" bzw "Error" ein abgeschlossener Sendevorgang sichergestellt, wird AG_Recv mit einem entsprechend großen Array (durch Programmflags bekannt) aufgerufen. Die Parameter "LEN" und "Error" werden ausgewertet und ggf. wird Schritt drei wiederholt.
Das alles klappt auch so wie es soll und in der Regel braucht das Programm hierfür 4 Bausteinaufrufe. Um das Verhalten bei Verbindungsfehlern zu analysieren, habe ich das Ethernetkabel am EVG ausgesteckt und nach variierender Zeit wieder eingeteckt. In den meisten Fällen nimmt der Baustein die Kommunikation wieder auf, allerdings nicht wenn der Verbindungsausfall - wie ich annehme - unmittelbar während des Rücksendens (EVG an CP) eintritt.
Meine Annahme ist nun folgende:
Durch den abgebrochenen Rücksendevorgang liegen Daten ungleich der erwarteten Länge im Empfangsdatenpuffer des CP 443-1 wodurch ein undefinierter Offset entsteht. Die Daten können dann von AG_Recv nicht mehr richtig eingelesen werden, da die Datenlänge nicht mehr der Länge des Arrays entspricht.
Ist meine Annahme richtig? Kann das so vorkommen? Gibt es eine Möglichkeit den Empfangsdatenpuffer des CP zu löschen?
Vielen lieben Dank im voraus.
Mit freundlichen Grüßen
Max