Network.lib

peewit · 23. November 2014, 09:14:16

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]

mactoolz · 24. November 2014, 12:21:48

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

mactoolz · 26. November 2014, 20:27:05

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

mactoolz · 03. Dezember 2014, 19:53:46

Hi,

geht es hier weiter? ;)

Danke

MacToolz

mactoolz · 11. Dezember 2014, 23:20:11

Hallo,

haaaallooo ...

MacToolz

peewit · 12. Dezember 2014, 09:13:05

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.

mactoolz · 12. Dezember 2014, 20:00:38

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

peewit · 14. Dezember 2014, 07:35:30

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.

mactoolz · 15. Dezember 2014, 23:35:15

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