Hallo Frank,
die anderen beiden IOs setzen ebenfalls $modules{CUL_HM}{defptr}{$id}{helper}{io}{nextSend}, aber ohne zu prüfen, ob ein anderes IO es schon gesetzt hat.
Durch das Busy Waiting für den CUL wird deren "Empfang" mit verzögert.
HMLAN könnte das noch mit Empfangsdelayberechnung anhand der HMLAN Empfangszeit kompensieren.
HMUARTLGW kann es nicht, wenn es nicht zufällig gerade den verlängerten Round Trip Delay ermittelt und die Verzögerung darüber mitbekommt.
Damit setzt, vermutlich HMUARTLGW, {nextSend} nach der veralteten Empfangsnachricht.
Das überschneidet sich beim CUL dann mit der Prüfung, ob das zu überschreibende {nextSend} abgelaufen ist, und CUL setzt daher {nextSend} nicht.
Wenn Rudolf in 00_CUL.pm die Prüfung raus wirft und {nextSend} auch einfach setzt, dann könnte es bei Deiner Multi-IO Umgebung klappen, weil Dein USB-angebundener CUL zuerst "empfängt", bei anderen aber nicht, die seriell angebundene CULs im Multi-IO Verbund nutzen. Diese CULs würden zuletzt "empfangen".
Besser sollte es werden, wenn auch HMLAN und HMUARTLGW vor dem Setzen prüfen würden, ob {nextSend} abgelaufen ist und ebenfalls dann auch nur setzen, wenn ihr {nextSend} besser=früher liegt.
Gruß, Ansgar.
