Network.lib

[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

[peewit]

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

[mactoolz]

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

[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

[peewit]

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

[mactoolz]

Hi,

was meinst du mit Kommunikation genau?

Doch mein Size ist Null, garantiert, alles schon geprüft.


MacToolz

[peewit]

deine sps kommuniziert die welchen gerät und was wird dort an information ausgetauscht

[mactoolz]

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

[peewit]

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

[mactoolz]

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

[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