# IP\_CONTROL(2) Nachrichten versenden **URL:** \ **Category:** Codesys 2\ **Created:** [29. September 2012 um 16:35 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435 "2012-09-29T16:35:39Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/oscat/original/1X/2efdfb9c592ff9a666c94dff124ee84fa863dae5.jpeg) [@system](https://oscat.discourse.group/u/system)\ **Post date:** [29. September 2012 um 16:35 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/1 "2012-09-29T16:35:39Z")
Hallo zusammen, Frage: Darf ich in den S\_BUF des Bausteines IP\_CONTROL und/oder IP\_CONTROL2 jederzeit Daten einstellen, oder muß ich warten bis der Buffer leer ist (S\_BUF.SIZE=0)? Gruß matt ---
**Author:** ![peewit](https://avatars.discourse-cdn.com/v4/letter/p/ecc23a/32.png) [@peewit](https://oscat.discourse.group/u/peewit)\ **Post date:** [29. September 2012 um 18:36 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/2 "2012-09-29T18:36:18Z")
du musst warten bis s\_buf\_size = 0 ist, denn dann sind alle daten gesendet worden, bzw bei einen ip\_control error musst du selber entscheiden was weiter passieren soll ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/oscat/original/1X/2efdfb9c592ff9a666c94dff124ee84fa863dae5.jpeg) [@system](https://oscat.discourse.group/u/system)\ **Post date:** [29. September 2012 um 20:22 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/3 "2012-09-29T20:22:18Z")
Hallo peewit, danke für die schnelle Antwort. Das trifft mich etwas unerwartet, ich hätte gedacht das man in einen Buffer per Definition jederzeit Daten schreiben können sollte und das ich es hier mit einem Bug zu tun hätte. Ich habe inzwischen den Quellcode gelesen und auch einige Versuche gemacht → Beschreibt man den Buffer in jedem Zyklus ohne auf S\_BUF.SIZE=0 zu achten, so geht jedes zweite Paket verloren. Hättest Du Lust dazu (wenn gewünscht gemeinsam mit mir, oder durch mich): 1.) den Buffer von IP\_CONTROL und/oder wenigstens IP\_CONTROL2 ohne die Einschränkung S\_BUF.SIZE=0 beschreibbar zu machen? 2.) die minimale Zyklusanzahl beim Senden auf 1 zu verringern? Ich denke, dass das eine Vereinfachung im Handling des Bausteins bringen würde ohne das die Kompatbliität zu bestehenden Projekten aufgegeben werden müsste. Beispiel: Ich habe x (sagen wir mal 10) Bausteine, die Ihre Daten über einen IP\_Control versenden möchten (optimalerweise in jedem Zyklus). Wenn ich auf S\_BUF.SIZE=0 warten muss, so sendet der erste Baustein sofort und dann alle (etwa) 2 Zyklen und die anderen nie. (In der aktuellen Implementierung des IP\_CONTROL Bausteins müßte man einen Master zwischen schalten der das regelt.) Gruß matt ---
**Author:** ![peewit](https://avatars.discourse-cdn.com/v4/letter/p/ecc23a/32.png) [@peewit](https://oscat.discourse.group/u/peewit)\ **Post date:** [29. September 2012 um 22:47 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/4 "2012-09-29T22:47:23Z")
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 8) 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 ---
**Author:** ![gravieren](https://avatars.discourse-cdn.com/v4/letter/g/54ee81/32.png) [@gravieren](https://oscat.discourse.group/u/gravieren)\ **Post date:** [30. September 2012 um 11:00 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/5 "2012-09-30T11:00:00Z")
Hi > [@peewit post:4](#): > > 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 Eventuell “s\_buf” als FIFO. Jedoch verlagert das das Problem nur. Denn du darfst erst “nachspeisen” wenn ausreichend FIFO-Speicher noch vorhanden sind. Gruß Karl ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/oscat/original/1X/2efdfb9c592ff9a666c94dff124ee84fa863dae5.jpeg) [@system](https://oscat.discourse.group/u/system)\ **Post date:** [30. September 2012 um 11:32 UTC](https://oscat.discourse.group/t/ip-control-2-nachrichten-versenden/1435/6 "2012-09-30T11:32:22Z")
Hallo peewit, > [@peewit post:4](#): > > es gibt keine garantie das etwas über ethernet im selben zyklus gemacht wird ! Stimmt. Ist aber auch nicht das was ich sagen wollte. Vielmehr meinte ich, das wenn es möglich ist es in einem Zyklus zu übertragen es auch machen zu können. Beim IP\_CONTROL2 dürfte das aber doch in der Regel (immer?) funktionieren, da die Buffergröße, wenn ich das richtig sehe, extra darauf abgestimmt wurde. > [@peewit post:4](#): > > 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 Und das finde ich auch gut. > [@peewit post:4](#): > > 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 8) Beim IP\_CONTROL2 könnte ich mir folgendes vorstellen: Versuch den Puffer zu senden → SysSockSend meldet die gesendeten Bytes zurück → optimalerweise sind alle (oder keine) verschickt worden, dann die Buffer Size auf 0 setzen (oder nicht verändern). Wenn (was wohl die Ausnahme sein dürfte) nur einige Bytes gesendet wurden, dann die verbleibenden Daten nach vorne kopieren und die Buffer Size anpassen. Beim IP\_CONTROL gebe ich Die recht, da müsste man sich die Sinnfrage stellen. Hier könnte ich mir aber auch folgende Vorgehensweise vorstellen: Einführung eines internen Zeigers der auf das nächste zu sendene Byte und wenn der auf das Ende des Buffers zeigt, dann Buffergröße auf 0 setzen. Der Anwender hat dann die Möglichkeit entweder a) wie bisher mit IF S\_BUF.SIZE=0 zu warten bis er neue Daten in den Buffer schreibt oder b) nur Daten in den Buffer zu schreiben wenn noch Platz im Buffer ist > [@peewit post:4](#): > > 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 Na, da habe ich nur so eine Ahnung … > [@peewit post:4](#): > > 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 Für mein konkretes Problem werde ich schon eine Lösung finden. Zur Not Forke ich Deinen Baustein und passe mir den entsprechend an 😉 Hier geht es mir hauptsächlich um eine Diskussion a.) der Funktionsweise und b.) über eine mögliche Verbesserung des Vorhandenen. Gruß matt