Hallo Marcus,

ich hab mal wegen der Sache mit einem alten Bekannten beim Systemtest gesprochen. So wie es aussieht ist das auf jeden Fall möglich und wurde schon bei etlichen Kunden angewendet die damit sehr Glücklich sind. [;)]

Was ich nun als Tipp habe ist folgendes:
Versuche die Daten in 2 Zügen abzuholen.
Zuerst die 16 Bytes des Headers. In diese Daten enthalten die Informationen ob der Auftrag erfolgreich war und wie viele Daten noch abzuholen sind da sie von der CP gesendet wurden.
Im zweiten Zug dann noch die wirklichen Daten der Steuerung.

Ein generelles Buffern über die gesamte Datenlänge macht keinen Sinn, da man nicht 100%ig sagen kann ob der Auftrag erfolgreich war.

Was man generell sagen kann ist das man durch schließen des Ports und neuerliches öffnen den Buffer der Verbindung, Steuerungsseitig, löscht und neu aufsetzt.

Wenn es hilft kann ich mir auch gern eine Aufzeichnung des Telegrammverkehrs über Etherreal ansehen.

Viele Grüße

eigentlich kann ich mir nur eines vorstellen. Das Fetch Telegramm "darf nur" 16 Byte lang sein. Das von Dir verwendete ist aber 17 Byte lang.
Durch die Eigenschaft des CP’s das er hier nur 16 Byte erwartet und auch nur 16 abholtist das ein Byte zu viel. Da der Telegrammspeicher im CP ein Ringpuffer ist kann ich mir vorstellen das es daraus zu einem Problem kommt und zwar mit einem Versatz von einem Byte das auch noch eine 00 enthält. [:cry:]

Als Ergebnis würde ich sagen das man hier am besten das letzte Byte am Telegramm wegnimmt und schon sollte es auch ein zweites mal funktionieren. [;)]
Wenn das zu aufwändig wäre sollte es auch genügen den Port zu schließen und wieder zu öffnen, dass leert den Telegrammpuffer auf dem CP auch. [:P]

Ich hoffe das hilft.

Viele Grüße