OSCAT Forum
oscat.lib => oscat.lib fuer CoDeSys 3 => Thema gestartet von: alexdrik am 06. Juli 2011, 14:17:06
-
Hallo,
gibt es die Network.lib auch für CoDeSys 3?
Gruß
Alex
-
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...
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
Hi,
ich nochmal zur frühen Stunde,
Ich habe das mir nochmal angeschaut und sehe das hier mit der Mailbox die Verriegelungen für das SysSockRecv gemacht werden.
Ok, also was habe ich geamcht, nachdem ich im Size direkt Daten sehe, habe ich die Mailbox[3] := 1 gesetzt damit im nächsten Zyklus
keine Daten mehr vom Client abgeholt werden.
Jetzt kommt das große aber. Es kommen VIELLEICHT Daten im nächsten Aufruf oder auch nicht.
Sobald ich nach meiner Verarbeitung das Byte wieder zurück setze, kommen meistens keine Daten mehr.
Es sieht so aus das der Client von dem ich die Daten habe möchte die alle irgend wie los geworden ist.
Nur wohnin ???
MacToolz
-
was sind das für daten
welches protokoll wird verwendet
normalerweise ergibt sich das logischerweise ob noch daten kommen oder nicht
du solltest mal die kommunikation mit wireshark aufzeichnen dann sehen wir was sich wirklich aus der leitung tut
-
Hi,
also ich verwende das TCP Protokoll. Die Daten sind aus dem Zeichensatz Base64. Aber das wäre doch nicht ganz so wichtig oder.
Ist doch alles Byteorientiert.
Für mich sieht das so aus als würden auch noch Daten kommen, nachdem ich wieder die Freigabe für das SysSockRecv wieder gebe.
Kann das sein das die Puffergröße zu groß ist. Weil der Client weis ja wie groß der Puffer ist (SysSockRecv) und befüllt entsprechend,
das heißt er schaufelt solange rein bis der Puffer Voll ist. Ich unterbreche aber zu früh, zu früh meine ich, das der Client in seiner Abarbeitungszeit z.B. die ersten 100Byte von den Maximal möglichen 1000Byte kopiert hat und somit könnten dann beim nächsten Lesen Daten verloren gehen oder,
weil ich ja das "Size" ablösche.
MacToolz
-
Hi,
ich denke das habe ich jetzt im Griff.
Ich bin der Meinung, und das habe ich auch nachgestellt, das wenn der Puffer entsprechend groß gewählt wird, dann wird dieser auch im vollen Umfang befüllt solange Daten kommen.
Das heißt ich muss meinem Puffer klein stellen. Zu einem das intern in der IP_Control der Überlauf eh überwacht wird und das "Size" selber abgelöscht wird,
zum anderen, darf man eigentlich immer bis in die Puffer Grenze laufen. Macht das überhaupt Sinn?
Mir fehlt immer noch das Verständnis wie auf TCP IP Ebene das Abrufen von Daten statt findet. Ich sehe momentan keine schlüssigen Weg für mich.
Was ich auf jeden Fall festgestellt habe ist, das der Client an dem ich mich anmelde und dann den Puffer sehr groß wähle, das er selber in seiner Verarbeitungszeit unterschiedlich große Pakete
in den Puffer sendet.
Was ich gerade selber noch in den Baustein als Test implementiert habe ist,
das wenn ich das Mailbox[3] Byte zum blockieren nehme, da habe ich dann eine neue Methoden Aufrufe genommen die das Betriebssystem anweist
das kein Sende/Empfang Kommunikation zugelassen ist.
--> SysSockShutdown(server_socket, 0);
--> halbes Kommando zurück, diese Funktion ist Systemspezifisch und funktioniert z.B. bei der Wago 750-880 nicht. Andere Zielsysteme wie PLCWinNT habe
ich nicht getestet weil ich zu faul bin. BEi der 750-880 und der RTE kommt vom Shutdown nicht die Rückmeldung das er das ausgeführt hat !!!
Damit funktioniert das ganze meiner Meinung nach besser und flüssiger, ohne das ich selber dann in meinem Code was zusätzlich als verriegelung machen muss,
außer das Byte in der Mailbox zum blockieren zu bringen
Ich bin mal auf deine Antwort gespannt.
MacToolz
-
der standard ist das man daten sendet und aufgrund dessen welche bekommt
und das normalerweise in kleinen datenmengen
kann es sein das du nach dem empfang nicht size = 0 machst ?
denn dann ist logischerweise der puffer irgendwann voll
was für eine kommunikation nutzt du denn nun genau
-
Hi,
was meinst du mit Kommunikation genau?
Doch mein Size ist Null, garantiert, alles schon geprüft.
MacToolz
-
deine sps kommuniziert die welchen gerät und was wird dort an information ausgetauscht
-
Morgen,
der client ist von der Firma Eq3 (MaxCube).
Also ich bin zu dem Entschluss gekommen, das der Client viel schneller ist als ich mit meiner SPS Task, wobei meine Task auf eine 1ms gestellt ist.
Wenn 8000 Byte zur Verfügung stehen dann versucht er die dort rein zu schreiben. Da ich zwar selber das "Size" für den Puffer ablösche,
schafft der Client es trotzdem noch Daten zu schreiben.
Trotzdem bin ich verwundert das dass SysSockRecv ja ein Synchroner Aufruf an das Betriebssystem ist. Der Client aber trotzdem weiter
an die Adresse vom Puffer schreibt, solange der nicht voll ist.
Weil es wird ja niemand dem Client sagen hör mal gerade auf Daten zu senden. Sondern das Betriebsystem kümmert sich auf TCP IP Basis darum wie viel dort rein geschrieben werden kann.
Das sieht so aus das ein einmaliger Aufruf von SysSockRecv dazu führt das dass Betriebssystem auf dem Socket Daten holt und
das Asynchron und solange bis der Puffer voll ist.
Wähle ich einen kleinen Puffer dann funktioniert die Sache. Den Puffer habe ich mal so gewählt weil er nie Daten unter 100Byte sendet.
Das wäre eine Lösung in Bezug auf diesen Hersteller.
Oder liegt es eventuell doch eher an meinem Wago Ethernet Kopper 750-880?
MacToolz
-
den tcp-stack schalte ich mit dem ip_control in den non-blocking mode
denn sonst konnte deine ganze sps beeinflusst werden
empfangene daten laden im internen tcp-stack buffer und diese daten holst du dir dann gezielt mittels syssockrev
das der client viel schneller ist , ist auch völlig logisch
deine sps ist wie schnecke zu ice-zug
das du den datenempfang in einen 1ms task laufen kann auch zu problemen führen
lass mal vorerst den datenempfang in einen normalen freilaufenden task
was macht der eq3 genau
-
Nabend,
also der EQ3 sprich Maxcube bringt Daten von einem Heizungssystem. Das heisst es gibt Thermostate, Wandthermostate und Fensterkontakte.
Das Gateway dazu ist so zusagen die Schnittstelle zwischen Ethernet Funk von allen Geräten innerhalb dieses Heizungssystems.
Wie gesagt sobald der Socket auf ist, sendet der Client alles raus was er aktuell an Informationen hat.
Wie schaltest du den "Non-blocking mode", wo und wie passiert das.
Es gibt ja einenfertige Funktionnfür einen Sende und Empfangsvorgang dem Betriebssystem sprich dem Client mitteilen zu können aber das Funktioniert auf dem Koppler und der RTE nicjt. Warum auch immer.
Was und wie müsste ich denn jetzt mit dem Non-blocking mode umgehen.
MacToolz
-
du musst nichts mit den blocking mode machen
das muss so auch gehen
das hat andere ursachen
mach doch mal einen wireshark datenmitschnitt
damit ich sehen kann was da über die leitung flitzt
-
Hi,
also ich kann machen was ich will. Der Wireshark läuft, alle Netzwerkteilnehmer sehe ich und kann auch entsprechend die Filter setzen.
Nur meinen EQ3 Cube sehe ich nicht. Daten und verwertbare Daten kommen aber in die Steuerung rein.
Jetzt stellt sich die Frage liegt das am Switch, aber andere Teilnehmer sehe ich alle, oder liegt es eher daran das ich mein CoDeSys V3 in der Virtuellen Maschine laufen habe???
Trotz alle dem, lasse ich den Wireshark laufen wenn ich mit der HErsteller Software über dem Browser drauf gehe, sehe ich genau die Daten im Wireshark, genau die gleichen wie in der Steuerung.
Frage bleibt, wie fange ich die Daten kontrolliert ein. ???
Nochmal zu Erinnerung, nicht das der Faden verloren geht.
Mit kleinem Puffer kein Problem, mit großem ist das Problem vorhanden?
Beides der gleiche Ablauf in der Steuerung???
MacToolz
-
Hi,
also ich denke wir können da reden wie wir wollen. Ich habe folgendes getan und es verhält so wie man es erwartet.
Der Client zu dem ich ein Socket aufbaue verhält sich irgendwie wie das UDP Protokoll.
Mit dem Aufruf SysSockRecv ist entsprechend vom Client ein Paket abgerufen worden und wird vermutlich mit diesem Aufruf auch quittiert.
Alles andere macht eigentlich auch keinen Sinn.
Der Client sendet eine gewisse Größe als Paket raus. Die Steuerung ruft mit SysSockRecv die Daten ab. Wenn die Daten im Puffer mit SysSockRecv im Puffer gelandet sind ist das die Quittierung die über das Zielsystempezifische System läuft.
Das habe ich folgendermaßen so getestet. Ich habe mir aus dem Netz eine TCP Server besorgt, habe wie wir das schonmal angedacht haben, mit dem Mailbox[3] Byte den nächste Aufruf blockiert.
Habe das Rücksetzen von dem Mailbox[3] Byte seitlich verzögert, z.B. 2s. Auf der TCP Server Seite kann ich Daten senden auf Knopfdruck.
Ich habe mal 100 Zeichen eingegeben. Jetzt Pole ich Zyklisch den SysSockRecv ab, die ersten 100 Byte kommen, dann 2s verzögert wird die Blockierung wieder aufgehoben.
Aaaaaber, innerhalb dieser 2s drücke ich mehrfach hintereinander das Senden auf der TCP Server Seite, siehe da, 5x gedrückt bedeutet jetzt nicht mehr 100Byte Daten, sondern 500Byte Daten.
Dabei lösche ich auch jedes Mal aufs neue das "Size" aus dem Empfangsbuffer ab.
Mache ich genau das gleiche mit dem EQ3 Client, funktioniert das nicht. Das sieht so aus als würde er sich um die Quittierung nicht mehr Kümmern, was aber nicht auf TCP/IP Protokoll Ebene gehen kann.
So ganz verstehe ich den WireShark nicht. Oben sind zwei Pakete mit dem UDP Protokoll zu sehen, aber dann kommen TCP Pakete.
Was sagt mir das jetzt.
MacToolz
[gelöscht durch Administrator]
-
es wäre von vorteil wenn du die ip-adressen aller teilnehmer angeben würdest
auf welchen port wird kommuniziert
PC
EQ3
SPS bzw. virtuelle Umgebung
wireshark in der wirtuellen maschine laufen lassen, dann sieht man zumindest was von und zu der sps kommuniziert wird.
-
Hi,
also 192.168.182.33 ist der EQ3 Client
192.168.182.38 ist mein PC.
192.168.182.11. die SPS
192.168.182.45 die VmWare
Ich hatte aber erwähnt das meine SPS nicht zu sehen ist, daher der Mitschnitt vom PC aus. Ich kann dir nicht sagen warum ich keine Kommunikation zwischen SPS und EQ3 mitschneiden kann.
Auf dem Port 62910 wird der Socket aufgebaut.
Aber es wird irgendwie am Anfang über UDP ein Port gesucht usw. um den Port rein theoretisch nach außen zu verschleiern, das man grundsätzlich
nur über die Hersteller Domain sich einloggt oder eine App.
MacToolz
-
das du den datenverkehr zwischen sps und eq3 nicht siehst , liegt daran das du an einen normalen switch-port hängst
und du nur das siehst was auch für den pc bestimmt ist.
da würde dir ein normaler alter hub helfen
zwischen pc und eq3 wird kaum etwas kommuniziert und das wenige ist nicht lesbar wenn man denn datenaufbau und die kodierung nicht kennt
[gelöscht durch Administrator]
-
Hi,
na da steht aber doch verdammt viel drin, genau das was man erwartet :-).
Ich weis was du meinst. Der Stream ist aber genau richtig.
Die Zeitliche Ababreitung ist aber ja falsch weil ich ja nicht direkt mitloggen kann, wie du schon gesagt hast, wegen dem Switch.
Ich wollte nur die Inhalte mal zeigen.
Wie schon erwähnt, die Kommunikation über TCP IP ist genau so wie man es erwarten würde. Das Verhalten oder eher mein Test habe ich ja beschrieben.
Trotzdem würde mich interessieren wieso das sich nicht bei diesem Cliebt so verhält.
Ich werde mir einen Hub besorgen und dann nochmal den WireShark Log posten.
Dann schauen wir nochmal.
MacToolz
-
Hi,
so, sag mal wie machen wir denn jetzt weiter.
Mich würde schon interessieren wie sich dieser Client verhält, zumindest das weis ich. Fakt ist aber das er sich nicht wie ein klassicher Client im TCP IP verhält.
Wie erwähnt, mit einem TCP Client/Server Tool funktioniert das wie es sich gehört. Selbst wenn ich mit Mailbox[3] blockiere und von der Seite mehrfach 100Byte hintereinander sende,
werden beim nächsten Aufruf genau die Anzahl der gesendeten Bytes aus dem SysSockRecv geholt.
Das funktioniert wie es soll. Nur warum bei diesem Client nicht.
Was machen wir jetzt?
Also interessieren würde mich das schon.
MacToolz
-
Hi,
geht es hier weiter? ;)
Danke
MacToolz
-
Hallo,
haaaallooo ...
MacToolz
-
ich habe irgendwie den faden verloren
über die sps (immer 100 bytes ..) funktioniert es
aber über den client geht es nicht
(welcher client ?)
vielleicht kannst du deine erkenntnisse nochmals kurz zusammenfassen
du musst berücksichtigen das andere deinen wissenstand nicht haben und es so sofort zu missverständnissen kommt.
-
Hi,
also meine test waren folgende.
Nachdem dieser Client sich seltsam verhält, habe ich eine Socket Verbindung zu einen Software TCP Server erstellt.
Da verhält sich der Socket, sprich das empfangen der Daten so wie man es zu erwarten hat.
Und zwar, man geht davon aus und das ist auch der normale Fall, das wenn Daten über das SysSockReceive kommen, diese direkt aus dem Puffer zu verwenden und auch zu kopieren.
Das heißt wenn der Puffer größer ist als das was wirklich gesendet wird, sendet der Server seine Pakete vollständig und es können alle direkt entnommen werden.
Der Test sah so aus, 100Byte gesendet, 100Byte kamen in der Steuerung an und wurden dann von mir ausgewertet.
So, jetzt der extrem Fall, ich habe auf dem SysSockReceive ein Breakpoint gesetzt, die SPS steht, der TCP Server sendet jetzt mehrfach 100Byte hintereinander,
sprich lasse ich dann das SysSockReceive durchlaufen, kommen genau alle diese Daten in der Anzahl richtig in die Steuerung.
Also ein ganz normales Verhalten.
Jetzt zu dem komischen Client. Ich habe noch festgestellt das dieser zwischen seinen Daten eine Pause einlegt.
Es gibt aber in seinem Protokoll kein STX/ETX.
Sobald ich mich verbinde sendet er alles was er hat, nur halt zeitlich versetzt. Das heißt der SysSockReceive meldet dann auch mal ein paar Zyklen (-1) kein Daten.
Damit ich alles von diesem Client Daten bekomme und auch vollständig, musste ich einen Timer einsetzen.
Dieser Timer prüft dann das bei (-1) n-Sekunden keine Daten mehr kommen, das er auch wirklich alles gesendet hat.
Das funktioniert auch soweit. Genau das was im WireShark steht, sind genau die Daten die ich dann auch in der Steuerung im Ascii Zeichensatz
lesen kann.
Für mich stellt sich gerade die Frage ob wir dem noch nachgehen sollen, aus reinem Interesse oder wir das einfach lassen, weil es geht mit regulären Client
die das sehr vernünftig machen.
Ich denke eher schon. Belassen wir das Thema, schließen das ab, weil der Code funktioniert einwandfrei.
PS: Ich komme gleich aber mit einem anderem Thema ... :-) ...
Danke ...
MacToolz
-
wenn die daten keine segementierung haben sondern eigentlich ein zusammenhängender datenstrom
dann gibt es logischerweise das problem des erkennens wann es zu ende ist.
im normalfall spielt das keine grosse rolle da fast alle geräte heutzutage einen ausreichend grossen puffer zur verfügung stellen. also speicher im überfluss.
das ist bei einer sps leider anderes, sehr wenig speicher und schlechte arbeitsbedingungen, da eine sps ursprünglich für andere zwecke entwickelt wurde und die file und ethernet kommunikation eigentlich erst nachträglich hinzugefügt wurden.
wenn keine echtes ende vorhanden dann musst du mit timer oder ähnlichen unschönen dingen arbeiten.
streng genommen sollte dein buffer groesser sein als die menge an daten die als datenstrom kommen können.
-
Hi,
die Bedingungen einer SPS sind schon klar. Das Verhalten ist aber zu diesem client anders.
Ich habe das schon geschrieben das ein anderer Client sich ganz normal verhält wie man es erwartet.
Das hier kein STX/ETX vorhnden ist, ist nicht die Frage oder Aufgabe. Es geht um die Tatsache das wie im ersten Ansatz sich auf dem TCP IP Protokoll irgendwie anders verhält als man erwartet.
Gut belassen wir es dabei so wie es ist. Es verhält isch alles ganz normal. Der Socket funktioniert wie zu erwarten.
Warum der Client sich so seltsam verhält kann ich nicht sagen ...
Danke und bis dann ...
PS: Schau mal in das Base64 Post rein ... :-) ... da geht es weiter ...
MacToolz