Beiträge

Hi,

wenn ich das richtig sehe liegt das ja nicht am Puffer. Der benutzt ja den Puffer vom Typ

Code Auswählen Erweitern

TYPE
NW_BUF_LONG  : ARRAY[0..NETWORK_BUFFER_LONG_SIZE] OF BYTE;
END_TYPE

(* revision history
ks 01. 01. 2009 rev 1.0
original version
*)


Ich sehe das eher so das vielen Funktionen im XML_READER alle mit einem INT arbeiten wie z.B. schieben etc.
daran scheitert doch das ganze oder !!!


Gruß
MacToolz

Hi,

wie sieht es denn mit dem Thema aus. Läuft das noch. ICh hätte auch interesse.
Vielleicht kann man das zusammen versuchen.


Gruß
Mactoolz

Hi,

eine Frage. Ich habe festgestellt das man nur XML Files mit bis zu 32Kb verarbeiten kann.

Ist das richtig ???

Gruß

Hi,

jetzt reg dich mal nicht so auf ... ist doch halb so wild was da passiert.
Du liest auch nicht alles ...

Ich habe geschrieben das ich weis das nicht jedes Byte ein Sinnvolles Zeichen ergibt.

Eins habe ich nicht bedacht ein Byte mit Inhalt von 16#00 bei der Konvertierung in String die Terminierung ergibt.

Danke

Hi,

dann schau dir mal bitte den Anhang an ...



[gelöscht durch Administrator]

Hi,

die Sichtweise ist mir bekannt. Nicht jedes Base Zeichen ergibt ein sinnvolles Ascii Zeichen. So ein Base64 Zeichen kann auch nur als Wert gesehen werden.
Genau so soll der gewandelte Text aussehen, und das zu erwartende Zeichen ist auch richtig.

Das heißt, du hast deinen Base Baustein verwendet?

Wenn ja, dann frage ich mich was falsch sein sollte?

Kannst du dein Beispiel mal posten bitte.

Danke


MacToolz

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

Hi,

meine Daten habe ich im Netz gegen geprüft. Das Ergebnis was ich als Base64 habe und erwarte ist richtig.

Das ist der String den ich dekodieren möchte. : EQUZ4wUAEg9KRVEwNDcwNjQ2
Das Ergebnis ist : ãJEQ0470646

Ich habe den Baustein "BASE64_DECODE_STREAM" verwendet.

Mactoolz

Hi,

also nachdem ich das eine Thema abgeschlossen habe, mache ich gerne ein neues Fass auf.
Also, in der Oscat Lib gibt es Bausteine die sich mit Base64 Zeichensatz auseinander setzen.

Ich bin gerade der Meinung das die irgendwie nicht funktionieren.

Und zwar, die Daten die ich Empfange habe ich im Internet bei anderen Base64 Decoder mal gegen getestet.
Dort werden alle Daten mir richtig angezeigt. Leider in der Oscat Lib nicht.

Oder gibt es da was was ich nicht weiß ... ???

Danke


MacToolz

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

Hallo,

haaaallooo ...


MacToolz

Hi,

geht es hier weiter? ;)

Danke

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,

ok ich schaue mal rein. Habe mir da jetzt was selber implementiert aber wenn man schon was hat, warum das Rad nochmal Rund machen :-)

MacToolz

Mahlzeit,

mein Stream kommt aus dem TCP IP Socket worüber wir gerade die ganze Zeit schon in einem anderem Post diskutieren. :-)


MacToolz