-> Hier kostenlos registrieren
Hallo
Wir haben ein Projekt wo die SPS (S315DP mit einer CP343-1) als Client
über TCP/IP mit einem Server auf einem normalen PC verbunden ist.
Die Verbindungen & co funzt im Normalfall auch recht gut.
Unser Sendbaustein sieht im folgenden so aus
// I fuer input, S fuer statische Daten eines Funktionsbaustein
U #I_StartSend // Startsignal
UN #S_Busy // und die aktuelle Verbindung macht gerade nichts
= #S_Start // dann Datenübertragung starten
S #S_Busy
.....
CALL "AG_SEND"
ACT :=#S_Start
ID :=#I_ID
LADDR :=#I_LADDR
SEND :=#S_Daten
LEN :=#I_Laenge
DONE :=#S_AG_Send_DONE
ERROR :=#S_AG_Send_ERROR
STATUS:=#S_AG_Send_STATUS
CLR
= #S_Start
U #S_AG_Send_DONE // Übertragung beendet
UN #S_AG_Send_ERROR
R #S_Busy
D.h. beim 1. Zyklus wenn es etwas zu Senden gibt wird S_Start auf 1 gesetzt, danach sofort auf 0.
Das Busy Bit wird gesetzt wenn es was zu senden gibt und gelöscht wenn die Nachricht angekommen ist.
Problem ist manchmal das bei einem Neustart des Servers die Send-Verbindung haengt, und erst ein RUN->STOP->RUN der SPS dann wieder Pakete von der SPS zum PC geschickt werden. Bei einem Wiederanlauf wird das S_Busy Bit hart gelöscht.
So meine Frage ist, was ist die sauberste Variante ohne einen manuellen Wiederanlauf der SPS dieses Problem zu lösen.
Ich bin mir nicht sicher was das Verhalten von AG_SEND bei Fehlern ist.
Wenn ein Fehler aufgetreten ist, wird natürlich das Busy-Bit nicht gelöscht.
Meine Frage, versucht es dann AG_SEND erneut, bzw nur in bestimmten Konstellationen.
Dann sollte aber der Effekt wie oben nicht passieren.
Ich kann bei Fehlen das Busy-Bit direkt löschen und den Sendeauftrag noch einmal starten lassen. Da wir noch jedesmal ein Ack-Telegramm versenden, kann ich in dem Baustein das auch "Wegwerfen" die Logik darüber sorgt dafür dass dieser Code dann das gleiche Telegramm nocheinmal vorgesetzt bekommt.
Bin für Ideen dankbar.
Wir haben ein Projekt wo die SPS (S315DP mit einer CP343-1) als Client
über TCP/IP mit einem Server auf einem normalen PC verbunden ist.
Die Verbindungen & co funzt im Normalfall auch recht gut.
Unser Sendbaustein sieht im folgenden so aus
// I fuer input, S fuer statische Daten eines Funktionsbaustein
U #I_StartSend // Startsignal
UN #S_Busy // und die aktuelle Verbindung macht gerade nichts
= #S_Start // dann Datenübertragung starten
S #S_Busy
.....
CALL "AG_SEND"
ACT :=#S_Start
ID :=#I_ID
LADDR :=#I_LADDR
SEND :=#S_Daten
LEN :=#I_Laenge
DONE :=#S_AG_Send_DONE
ERROR :=#S_AG_Send_ERROR
STATUS:=#S_AG_Send_STATUS
CLR
= #S_Start
U #S_AG_Send_DONE // Übertragung beendet
UN #S_AG_Send_ERROR
R #S_Busy
D.h. beim 1. Zyklus wenn es etwas zu Senden gibt wird S_Start auf 1 gesetzt, danach sofort auf 0.
Das Busy Bit wird gesetzt wenn es was zu senden gibt und gelöscht wenn die Nachricht angekommen ist.
Problem ist manchmal das bei einem Neustart des Servers die Send-Verbindung haengt, und erst ein RUN->STOP->RUN der SPS dann wieder Pakete von der SPS zum PC geschickt werden. Bei einem Wiederanlauf wird das S_Busy Bit hart gelöscht.
So meine Frage ist, was ist die sauberste Variante ohne einen manuellen Wiederanlauf der SPS dieses Problem zu lösen.
Ich bin mir nicht sicher was das Verhalten von AG_SEND bei Fehlern ist.
Wenn ein Fehler aufgetreten ist, wird natürlich das Busy-Bit nicht gelöscht.
Meine Frage, versucht es dann AG_SEND erneut, bzw nur in bestimmten Konstellationen.
Dann sollte aber der Effekt wie oben nicht passieren.
Ich kann bei Fehlen das Busy-Bit direkt löschen und den Sendeauftrag noch einmal starten lassen. Da wir noch jedesmal ein Ack-Telegramm versenden, kann ich in dem Baustein das auch "Wegwerfen" die Logik darüber sorgt dafür dass dieser Code dann das gleiche Telegramm nocheinmal vorgesetzt bekommt.
Bin für Ideen dankbar.