Client Socket auf Raspi vs. Windows

Hallo,

ich habe mit einen Client Socket mit meinem q3d Energiezähler verbunden. Auf dem RasPi bekomme ich:


alles super, genau so wie es sein sollte. Gleiches Experiment unter Windows:

Datensatz ist unvollständig und verstümmelt. Wie kann das sein ?

Verbindung erfolgte wie beschreiben wechselseitig auf das ein-und dasselbe Gerät (Port 7970)

nochmal genauer geschaut:

Das Söcken auf Windows schnobbelt immer nach 200 Bytes ab - auf dem RasPi ist das nicht so :confused::eek:

Das erinnert mich sehr an das „COM-Port Problem“ beim User „Wile_E.“ :eek: >> Skript läuft unter IPS 2.6 aber nicht unter 3.1

Am einen Computer kamen die Datensätze ganz anders rein als am nächsten Computer. Da waren die Datensätze auf einmal ganz anders abgehakt. Erst waren die unterschiedlichen IPS Versionen in Verdacht, aber dann kam der COM-Port in Verdacht, aber wenn ich das hier so lese komme ich ins Grübeln :confused:

Habe zu wenig Ahnung von sowas…ob es vlt. doch ein „Problem“ in IPS ist?!

Grüße,
Chris

Nein, hier liegt es wohl eher am OS und dessen TCP-Stack.
Darum gibt es ja Cutter und den Buffer der RegVar.
Michael

Hm, aber schon nach 200 Bytes :confused:

ich habe jetzt mal alles artig über die Buffers gemacht, wie es hier vielfach und in der Doku beschrieben wurde. Ich habe aber immer das Problem, dass der Client Socket + Cutter nach 200 Bytes neu einzulesen scheint:

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00019048.9556433*kWh)
1-0:21.7.255*255(000286.30*W)
1-0:41.7.255*255(000194.32*W)
1-0:61.7.255*255(000245.55*W)
1-0:1.7.255*255(0007:96.1.255*255(1ESY1001002159)/ESY5Q3DA1004 V3.02

da kann man es schön sehen.

Wo hast du die Daten den raus kopiert ?
Oder wie den Cutter konfiguriert.
So ist das doch eher stochern im Nebel.
Michael

die Daten stammen direkt aus dem Debugfenster. An Cuttereinstellungen habe ich alles mögliche probiert - auch das zeilenweise Einlesen über GetBuffer mit CRLF als Endekennung. Eigentlich immer das gleiche Ergebnis:

Die ersten Datensätze kommen richtig (200 Bytes), Danach kommt der Verschlucker: /ESY5Q3DA1004 V3.02 ist der neue Datensatz, der Rest vom alten fehlt.

Gleiches Skript auf dem RasPi läuft sofort richtig.

Immer noch Nebel :wink:
Welches Debug ? Das vom Cutter ? Der Socket ist doch egal.
Hast du den auch wirklich crlf als Endzeichen in den Daten ?
Hast du die Daten mal im Script per echo ausgeben lassen, oder dir das Debug der RegVar angesehen ?
Michael

Ja, Nebulös … ich verstehe auch nicht die ganz offensichtlich Grenze bei 200 Bytes.

Am Cutter habe ich alles erdenkliche probiert - CR / CRLF / Feste Zeichen / Feste Länge. Im Debug habe ich mir den Cutter angesehen und auch die RegVar. Und ja: Mit echos bekomme ich eben genau diesen Verschlucker. Zum Vergleich mit CRLF:

er liest nun mit dem Cutter zeilenweise ein, aber genau bei dem markierten Datensatz verschluckt er sich und würfelt die Daten durcheinander. Das ist exakt die gleiche Stelle wie oben, wo ich mit dem Cutter komplett einlese - bis zur Endekennung „!“.

Ich weiß ehrlich gesagt nicht mehr, wo ich suchen soll. Ich vermute, irgendetwas am Buffer ist faul - aber viel falsch kann man da ja nun auch nicht machen.

Ist es denn „normal“, dass man im Debug des Client Sockets nur 200 Bytes sieht?

Sorry so wird das nie was.
Es ist nicht nachzuvollziehen:
- Bitte schneide nicht so viel bei den Screenshots ab, man sieht nie welches Debug / welche Instanz du meinst. (Oder schreib es dazu!)

  • Ich habe auch noch nicht einmal die HEX-Ansicht deiner Daten gesehen, so dann man das Trennzeichen sehen kann.
  • Hast du nachgesehen ob es CRLF ist ? Oder nur geraten; weil so lesen sich deine Versuche mit dem Cutter.
  • Und was hast du wo im Cutter eingestellt (Screenshot bitte) ?
  • Oder wenn du ohne Cutter und mit dem Buffer der RegVar gearbeitet hast; dann zeig doch mal das Script.

Das bei einem Paketorientierten Protokoll du die Daten nur Blockweise bekommst ist normal. Warum der nun so klein ist… k.a. Vielleicht liegt es an der HW/OS vom IPS-Rechner, HW oder SW vom Sender… kann diverse Ursachen haben.
Sollte aber nicht stören. Wenn man die Pakete wieder zusammenfügt / zusammen fügen lässt.
Ich Debug können nicht alle Daten angezeigt werden; es wird immer eine Zeile geschrieben egal wie ‚lang‘.
Es wird mit … gekürzt. Du kann die Daten aber mit rechtsklick in die Zwischenablage kopieren.
Michael

Edit: Im ersten Scrennshot passen die darstellbaren Zeichen und Länge nicht immer, also müssen dort Steuerzeichen drinstecken.
Gib bitte mal ein Beispiel wie ein Datensatz am Stück aussehen soll.

okay, ich versuche es mal mit System…

also mit nc komme ich prima auf den Port, die Datensätze kommen sekündlich rein und haben das Format:

/ESY5Q3DA1004 V3.02

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00006623.7262665*kWh)
1-0:21.7.255*255(000054.33*W)
1-0:41.7.255*255(000116.63*W)
1-0:61.7.255*255(000355.25*W)
1-0:1.7.255*255(000526.21*W)
1-0:96.5.5*255(82)
0-0:96.1.255*255(1ESY1001002159)
!

da ein kompletter Satz immer mit /ESYQ3D anfängt und mit einem „!“ aufhört, fand ich es logisch, den Cutter auch so einzustellen:

im Debug dieses Cutters kommt:

und wenn ich mir die Inhalte anschaue, siehts komisch aus:
ReveivedDATA (ungekürzt, der bricht einfach ab):

/ESY5Q3DA1004 V3.02

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00019092.8574900*kWh)
1-0:21.7.255*255

CURRENTBUFFER (nur der Anfang):

/ESY5Q3DA1004 V3.02

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00019092.8535563*kWh)
1-0:21.7.255*255(000305.13*W)
1-0:41.7.255*255(000171.17*W)
1-0:61.7.255*255(000116.53*W)
1-0:1.7.255*255(0005/ESY5Q3DA1004 V3.02

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00019092.8538864*kWh)
1-0:21.7.255*255(000306.98*W)
1-0:41.7.255*255(000171.06*W)
1-0:61.7.255*255(000116.56*W)
1-0:1.7.255*255(0005/ESY5Q3DA1004 V3.02

1-0:0.0.0*255(1001002159)
1-0:1.8.0*255(00019092.8542160*kWh)
1-0:21.7.255*255(000305.91*W)
1-0:41.7.255*255(000171.00*W)
1-0:61.7.255*255(000116.65*W)
1-0:1.7.255*255(0005/ESY5Q3DA1004 V3.02

mit nem Script brauch ich da wohl nicht weiter probieren.
Es ist immer die Stelle 1-0:1.7.255*255(000… wo normalerweise die Gesamtleistung stehen sollte.

Nun der 2.te Versuch mit CRLF


das ergibt zwar Datensätze wie erwartet - aber eben auch genau an der Stelle „Murks“:

Au weia, jetzt habe ich mir ncat für windows besorgt und erhalte:

Unbenannt.PNG

das Problem liegt tatsächlich irgendwo im System. Mit nc auf dem Raspi bekomme ich fehlerfreie Daten. Oh-Oooh :eek:

Kurze Erklärung zum DEBUG des Cutter:

  • ReveivedDATA : Das was vom Clientsocket reinkommt (immer neu)
  • CURRENTBUFFER : Ist der Inhalt vom Buffer. Der wird bei dir immer größer !
  • SENDCHUNK : Der Cutter hat das END-Zeichen gefunden und sendet an die RegVar. (bei dir nie!)
    Die Erklärung hast du ja schon gefunden. Es kommt nie ein ! sondern immer ein neues Paket mit /ESY5Q3D dann kann der Cutter ja nix sinnvolles weitersenden.

Wo ist da CRLF ? Ich sehe einen leeren (nicht konfigurieten) Cutter :eek:

Aber bleibt lieber bei dem ersten Versuch mit /ESY5Q3D und ! oder wilst du die Zeilen einzeln haben ?
Nur warum das Ende auf dem Windows immer fehlt. Schon komisch. Mal mit Wireshark mitgeschnitten ?
Vielleicht wird die TCP-Verbindung gekillt ? Oder hat andere Probleme ?
Michael

Ich fürchte ja:

Auf einem anderen Windows-System kommen mit ncat die Daten völlig sauber rein. Nur natürlich auf dem System nicht, auf dem IPS läuft :mad:

Ich versuche jetzt unterschiedliche Treiberversionen für die Netzwerkkarte und komisch ist:

Immer nach dem Austausch bekomme ich mit ncat genau 1 richtigen Datensatz. Danach gibt es Verschlucker. Liegt wahrscheinlich daran, dass die Netzwerkdienste neu gestartet werden - nur dann liest er ein mal richtig ein.

Problem scheint behoben (gelöst will ich es nicht nennen):

Es liegt an dem Buffer des YPort (RS232<->LAN) am Net-IO. Den habe ich etwas angehoben, jetzt scheint es zu gehen. Warum sich das nur an dem 1 Rechner bemerkbar gemacht hat - man wird es wohl nie erfahren.

Vielen Dank für deine Hilfe. Ohne dein „Nachbohren“ hätte ich nie am Net-Io geschraubt :o

Bitte. Nerven kann ich gut (sehe ich ja an meinen Kids :wink: )
Michael