oscat.lib > oscat.lib fuer CoDeSys 3
Network.lib
peewit:
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
mactoolz:
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
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]
peewit:
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.
mactoolz:
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
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln