er macht es so wie ich es vorgeschlagen habe:
Der Code ist ja so
Also er versucht es im Konfliktfall einfach immer neu.
Da jeder Teilnehmer ja einen Puffer hat, ist das auch kein Problem.
Befindet sich das RS232 Gateway z.B. im Direkt Mode staut es sich dort auch. Ist der Direkt Mode beendet kann man sehr schön sehen, wie dann der Puffer geleert wird (Es kommen sehr schnell Daten). (da war auch mein Problem beim tracen, das kam zu schnell) Danach purzeln die Daten wieder einer nach dem anderen raus.
Das Problem ist hier beim RS232 Gateway, dass es eben so implementiert ist wie es ist. Wir können daran nicht ändern. Offensichtlich versteht es nicht wenn im Konfliktfall ein DLE geschickt wird dieses als Bestätigung zum Senden. Es interpretiert das Zeichen als Fehlerhafte Übertragung (NAK oder beliebiges Zeichen!!!) und überträgt die Payload erneut. Ich halte das für eine fehlerhaft Implementierung im RS232. Ich habe aber keine Zeit das mit Buderus zu diskutieren. Wir können das aber jetzt nicht ändern.
Ich denke, wenn wir es so machen, wie im JAVA Code und wie ich es auch vorgeschlagen habe, dann sind wir auf der sicheren Seite.
Das funktioniert jedefalls zuverlässig.
Das RS232 Gateway wird ja auch wieder versuchen zu senden. Es wird so schnell also nicht verhungern
Gruß Tbi
- kurz warten (sehe ich als optional)
- Dann einfach neu versuchen (mein Vorschlag)
Der Code ist ja so
Code:
if Zeichen == STX) ## Konflikt Warten (zufällig zwischen 0-5 Sec.) versuche es neu if Zeichen == DLE sende meine Payload
Da jeder Teilnehmer ja einen Puffer hat, ist das auch kein Problem.
Befindet sich das RS232 Gateway z.B. im Direkt Mode staut es sich dort auch. Ist der Direkt Mode beendet kann man sehr schön sehen, wie dann der Puffer geleert wird (Es kommen sehr schnell Daten). (da war auch mein Problem beim tracen, das kam zu schnell) Danach purzeln die Daten wieder einer nach dem anderen raus.
Das Problem ist hier beim RS232 Gateway, dass es eben so implementiert ist wie es ist. Wir können daran nicht ändern. Offensichtlich versteht es nicht wenn im Konfliktfall ein DLE geschickt wird dieses als Bestätigung zum Senden. Es interpretiert das Zeichen als Fehlerhafte Übertragung (NAK oder beliebiges Zeichen!!!) und überträgt die Payload erneut. Ich halte das für eine fehlerhaft Implementierung im RS232. Ich habe aber keine Zeit das mit Buderus zu diskutieren. Wir können das aber jetzt nicht ändern.
Ich denke, wenn wir es so machen, wie im JAVA Code und wie ich es auch vorgeschlagen habe, dann sind wir auf der sicheren Seite.
Das funktioniert jedefalls zuverlässig.
Das RS232 Gateway wird ja auch wieder versuchen zu senden. Es wird so schnell also nicht verhungern

Gruß Tbi
Kommentar