Network.lib

[alexdrik]

Hallo,

gibt es die Network.lib auch für CoDeSys 3?

Gruß
     Alex

[peewit]

deine frage habe ich anscheiend übersehen

spät aber doch .....

damit die network.lib auf codesys läuft müssen der ip_control und der file_server neu geschreiben werden
dies ist aus zeit gründen bislang nicht geschehen...

[RamonR]

Hallo,
ist das Bestreben, die Network-Lib auf Codesys V3 umzusetzen, mittlerweile fortgeschritten?
Wenn nein, gibt es Möglichkeiten, zumindest Teile der Library (für mich spannend: das Handling von CSV-Dateien) unter V3 zu nutzen?
Grüße
RamonR

[peewit]

hallo

erste experimentelle ausführungen gibt unter diesen link

http://www.oscat.de/community/index.php/topic,1784.msg9460.html#msg9460

der kern der sache ist der ip_control und der file_server
diese beiden bausteine sind immer plattformspezifisch und hardwareabhängig
alle anderen bausteine kannst du normalerweise 1:1 von codesys 2.x auf 3.x übernehmen
es gibt nur ein paar wenige syntax anpassungen die notwendig sind.

[mactoolz]

Hi,

ich bin gerade dabei die socketverbindung in CoDeSys V3 einzubinden. Dabei kämpfe ich mich schwer durch.
Gibt es da eine fertige Version für V3?

Ich kämpfe gerade mit den Namensbereichen und sonstige V3 Socketfunktionen, die doch geringfügig anders sind.

Danke

MacToolz

[mactoolz]

Hi,

also ich habe die Socket Implementierung mit dem IP_Control in CoDeSys V3 umgesetzt.

Jetzt habe ich eine Frage. Und zwar folgende. Die Datengröße "pdt_R_BUF.SIZE".
kommt seltsam in die Steuerung. Das Verhält sich auch genau so in CoDeSys V2.

Bis jetzt habe ich es so probiert, sobald ich im Zyklus im Size Daten sehe, sprich >0, dann kopiere ich Daten um und lösche selber das Size ab.
Dann kommen wieder neue Daten usw.

Im Empfangspuffer sehe ich z.B. 2000Byte (Array Index)mit Daten gefüllt. Aber die anzahl der Bytes die ich quasi zusammen zähle entspricht nicht der Zahl die bis zu dem letzten Byte im Empfangsbuffer, in Bezug auf den Array Index, Daten geschrieben wurde.

Ich habe z.B. jede Size mal in ein array von Dint weggeschrieben und das Size abgenullt.
In Summe habe ich ca. 4000 Byte aber es sind wirklich im Empbangsbuffer 2000Byte beschrieben worden.

Wo ist da mein Denkfehler.
Kannst du das nachvollziehen wie ich das beschreibe.


MacToolz

[mactoolz]

Hi,

also komisch war dann doch garnichts. Die Summer der Empfangenen Bytes war richtig, nur das ich meinen speicher überlaufen habe und erneut von vorne wieder mein
Empfangsbuffer überschrieben wurde.

Gibt es eigentlich keine Meldung das der Empfangsbuffer überlauf statt gefunden hat. Ich meine das kann ich ja selber rein machen. Das ist nicht das Thema.
Aber es wird aber auch nirgend wo gebildet oder ???

Dann stelle ich mir aber jetzt die Frage, wie ich den Ablauf, vom Daten einsammeln abhängig mache.
Worauf reagiere ich denn jetzt um Daten umkopieren oder für mich lesbar in Ascii Zeichen zu wandeln.

ist denn das "Size" denn richtig?

Oder eher aus dem SocketRecv der Rückgabewert wieviele Zeichen generell empfangen wurden, sprich aus dem Empfangspuffer vom Ethernet Stack.
Weil im ersten denke ich benötige ich nicht die Gesamtgröße.

Weil sobald -1 aus dem SocketRecv kommt, sind auch keine Daten aktuell mehr vorhanden?

Also was das angeht bin ich etwas unschlüssig.

Danke

MacToolz

[peewit]

eine umsetzung der network lib für codesys 3.x findest du hier

http://www.oscat.de/community/index.php/topic,1784.msg9460.html#msg9460

[mactoolz]

Hi,

also ich für meinen Teil sehe hier kein Problem. Ich habe das "Size" für den Buffer falsch interpretiert.
Das Size ist ja die Größe die ja gerade im TCP Stack gerade in die Steuerung kopiert wird.

Wenn ich z.B. 5200 Bytes empfangen dann sind die auch im Buffer zu sehen. Das heißt das nach jedem SysSockRecv die Anzahl der Daten in den Buffer kopiert werden.

Ich stelle mir gerade die Frage wann ich die Daten umkopieren soll?

MacToolz

[peewit]

der empfangs und sendepuffer ist in den globalen setting der lib vorgegeben

wenn du mehr als diese vorgegebene datenmenge auf einmal verarbeiten musst, dann ist es für alle die den ip_control nicht sehr gut kennen das beste wenn man die globalen setting anpasst.

der ip_control lässt sich bei groesseren datenmengen auf dementsprechend handhaben, aber wie gesagt das ist das schon was für die profis

wie sowas ausieht kannst du zb. im smtp_client oder ftp_client baustein ansehen
diese bausteine können mit theoretisch beliebigen datenmengen umgehen.

wenn du beim s_buf eine size einträgst dann werden automatisch diese anzahl an bytes vom buffer übertragen
wenn die daten vollständig versendet worden sind wird automatisch size = 0 gemacht

wenn daten empfangen werden dann wird dir über size mitgeteilt wieviele byte im buffer bereitstehen

[mactoolz]

Hi,

ab wann darf man denn sich Profi nennen :-).
Die Funktionsweise vom "Size" ist mir bekannt, in beide Richtungen.

Aber ich habe ein seltsames Problem. Sobald ich in der gleichen Task das bytes_receveid nehme sozusagen
als Start das Daten im Puffer vorhanden sind, fange ich an die Daten umzukopieren.

Seltsamer weise muss ich die zeitlich versetzt umkopieren. Dann funktioniert es.
Wenn ich z.B. auf den ersten 70 Bytes umkopiere überschreibe ich mir Daten, obwohl ich in der gleichen Task liege.

Arbeiten die Funktionsaufrufe SysSockRecv Synchron oder Asynchron.

Ich kann irgendwie das Problem nicht einkreisen.


MacToolz

[peewit]

syssockrcv arbeitet synchron

aber der ip_control arbeitet asynchron zu der restlichen applikation
der ist normalerweise freilaufend im empfang

solange daten empfangen werden und der buffer noch nicht vollgelaufen ist werden die daten im buffer aneinandergereiht.



profi ist man dann wenn man so ein problem nicht hat :-)

ich kenne dein problem nicht , aber bei manchen situationen ist es notwendig den weiteren datenempfang anzuhalten
um in ruhe die empfangsdaten zu verarbeiten um den empfang danach gezielt wieder freizuschalten

ansonsten kann es bei gewissen situationen vorkommen das während des verarbeiten des empfangsbuffer diese noch anwächst


wie das geht siehst du - wie schon erwähnt - im ftp-client und smtp client

[mactoolz]

Hi Peewit,

das der IP_Control freilaufend ist das habe ich auch gesehen.

Ok, das mit dem Synchronen Aufruf von SysSockRecv habe ich mir fast gedacht.

Aber das mit dem Datenempfang anhalten, da habe ich nicht den Sinn verstanden, warum man das überhaupt macht.
Kannst du das bitte mal erklären?

Das der Puffer anwächst ist auch ok, soll ja auch so sein. Mein Gedanke ist, das ich eigentlich alles was an Empfangsbytes nach dem Synchronen Aufruf von  SysSockRecv kommt "bytes_received" direkt aus dem Empfangsbuffer zu kopieren.

Das sollte doch rein theoretisch funktionieren. Die Bedingung zu dem ist auch klar, das man auch überwacht das auf Daten aus dem SysSockRecv vorhanden sind, sprich "-1" sind natürlich keine Daten vorhanden.

Kannst du dir das erklären was das für ein Verhalten ist, das ich unbedingt Zeit verzögert erst kopieren kann.
Ich habe mal als Hausnummer eine Zeit herausgefunden, unter t#100ms brauch ich nicht anfangen zu kopieren.

Ich habe keine Ahnung warum.
Halte ich die Zeit ein, funktioniert alles wunderbar. Wie schon erwähnt, ich habe mitgeloggt wie die Daten aus dem SysSockRecv rein kommen.
Um erkennen zu können ob ich auch die richtige Anzahl von Bytes umkopiere. So nach dem Motto, nicht schneller oder eher zu viel direkt aus dem Empfangspuffer kopiere,
wo eigentlich noch keine Daten sind.

Das kann ich von mir aus gesehen ausschließen. !!!


MacToolz

[peewit]

ein einfaches beispiel

wenn du per ftp client baustein eine datei von einen ftp-server runterlädst, dann überschwemmt dich der ftp-server mit daten
sobald der datenbuffer voll ist, darfst du den syssockreceive nicht mehr aufrufen denn wohin mit den daten

dann musst du die daten im buffer weiterverarbeiten wie zb daten in datei schreiben

danach machst du r_buf.size = 0 und gibst den empfang wieder frei

wenn du das nicht machst dann wirst du einen grossteil der daten verlieren


eine sps hat sehr beschraenkte möglichkeiten und ressourcen (steinzeitliche handhabung und möglichkeiten)


sowas in hochsprache zu programmieren ist dagegen heutzutage ein kindergeburtstag

[mactoolz]

Hi Peewit,

ok das habe ich verstanden. Das heißt ihr bekomme was in dem Empfangspuffer, verarbeite die Daten,
lösche das "Size" wieder ab, muss aber dafür sicher stellen das keine Daten über den Synchaufruf SysSockRecv kommen können.

Was müsste ich denn jetzt in der Oscat Lib dafür tun damit der SysSockRecv nicht mehr aufgerufen wird.

Ist das die Mailbox --> IP_C.MAILBOX[3] ???


Gibt es da schon was das der Empfang geblockt wird. Weil ich würde ja gerne die LIB unberührt lassen,
außer man findet bei einem Profi einen Fehler ;-) ...


MacToolz