es gibt keine garantie das etwas über ethernet im selben zyklus gemacht wird !
die meisten codesys ethernet bibliotheken arbeiten im blocking mode
das heisst das du ziemliche zykluszeitschwankungen hast und du bei ethernet funktionen eigentlich deine
sps für unbestimmte zeit einfriert, oder du lagerst extra das alles in einen seperaten task aus !
das verlagert aber nur das problem
darum habe ich bei codesys alle im non-blocking mode programmiert
bei der sps programmierung ist das leider so, das man nicht einfach ewig auf ein ergebnis warten kann
da wir hier einen möglist konstanten zyklus aufrecht erhalten müssen
da haben es pc programmierer einfacher die rufen eine funktion auf und warten auf das ergebnis , auch wenn nichts kommt
(jeder kennt doch die schönen hängenden programme -> man nennt es auch absturz)
nachdem es keine garantie gibt das es im selben zyklus übernommen werden kann, bzw. irgendwann auch die interen stack/speicher überlaufen, müsstest du einen weiteren telegramm zwischenspeicher einführen
das hat keinen sinn
das kannst du komplett vergessen , das im selben zyklus zu machen
das hier ist halt etwas komplizierter als einen digitalen ausgang zu setzen
wenn du wüsstest was das für eine arbeit war einen simplen standard zu erfinden der auf drei hardwaremäßig völlig unterschiedlichen plattformen zu gleichen ergebnissen führt
was anderes noch ....
was wäre wenn du bei s_buf.size > 0 (senden aktiv) dein anwenderprogramm nicht durchläufst und nur den ip_control immer aufrufst.
dann würde das datensenden für dein anwenderprogramm formal im selben zyklus passieren
das würde für dein anwenderprogramm nur den schein haben das ein etwas längere zyklus gewesen ist