IP_CONTROL(2) Nachrichten versenden

[matt]

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

[peewit]

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

[matt]

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

[peewit]

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

[gravieren]

Hi

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

[matt]

Hallo peewit,

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.

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.

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 

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

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 ...

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