Beiträge

OK now with a little smile: I patched the error!! (see the (* XXXX *) in the screenshot)

But the source of the error lays deeper in the library.
The interlocking between FTP_CLIENT, IP_CONTROL and FILE_SERVER is not completely correct. IP_CONTROL is instructed to send packets of zero size. This is very successful so the number of "bytes_sent" is indeed zero. This causes the c_status := 253 and a termination of the connection.

In my opinion the S_BUF.SIZE is being abused for handshaking. A possible way to solve this could be to expand the NETWORK_BUFFER type with a field for it's maximum size. This would require recoding of at least the three FB named above. Should I just carry on and send in what I think could be a solutions or are there other developing guidelines I should take in consideration?

[gelöscht durch Administrator]

Peewit,

I redid the test with NETWORK_BUFFER_LONG_SIZE = 1407 and break point in step 210, program halt on this break point 23 times. Only 1,37 KB of the test file (22 KB) is actually transporter to the ftp destination.
Somehow the FTP_CLIENT stops transmitting after the first data pack. What does the IP_ERROR mean in MSG[75], see attachment?

What can I do to get this solved?

[gelöscht durch Administrator]

NETWORK_BUFFER_LONG_SIZE = 1500 same results as before. Timed out after 30 seconds. But I noticed after about 10 seconds the IP error in LOG-CL.MSG[74]. IP_ID 2 is for the data channel.

P.S. my next forum visit is likely coming Friday.

[gelöscht durch Administrator]

First time: FSD.FILE_SIZE = 21958
Second -- seventh time: FSD.FILE_SIZE = 21958
There after other program path with the time-out.
Attached the screen dump of the LOG_CL, the WireShark capture, my program and the test file.


[gelöscht durch Administrator]

I try to send a file from an Eaton HMI/PLC to a FileZilla Server.
This works for files smaller than 4 kB. With larger files the FB times out with ERROR_T = 16#05 and ERROR_C = 16#03DE0096. (step 990, last response 150 opening data channel).
I know this works OK with the WAGO plc's so I made a compare.
Attached the Wireshark en LOG_CL debug info for the EATON and the WAGO.
But I can't find the reason why the connection on the data channel in the EATON is "gracefully timeout", PLC_PRG.FTP_CLIENT.IPC2.c_status = 253. Please help.
For EATON test plc contact on pm.

[gelöscht durch Administrator]

überprüfe doch nochmals das ganze...
deine ergebnis kann ich nicht nachvollziehen...

da die bausteine prinzipiell auf den von mir getesteten plattformen laufen, ist es schwer
eine plattform zu testen die man nicht hat bzw. simulieren kann

Überprufen, daß habe Ich gemacht ja letzten Zeit, viel Zeit! Es fehlt mich an detail Kenntnis von FTP-protocol um genau zu beurteilen was hier falst geht. Siehe Anhang Log_03. Nachricht auf Zeile 21 ist am Datakanal der FTP-Server gesendet und nicht am Steuerkanal wie im Log_01.
Log_03: Eaton XV4 Panel HMI/SPS mit FTP_CLIENT_DEMO und syslibsockets_option auf 16#01. Den Datei "TST 22 KB.CSV" wird sogar angelegd auf denn Oscat test Server, und hat 4096 Bytes.
Log_01: Wago 750-881 mit FTP_CLIENT_DEMO und syslibsockets_option auf 16#04. Den Datei "TST 22 KB.CSV" wird komplett gesendet.
Was muss Ich Ausprobieren / Testen um hier weiter zu kommen?

Für ein Platform zum testen bitte Kontakt über pm.

P.S. Habbe noch ein bischen aufs Forum rundgeschaut und Ich war nicht den Ersten mit diesem Problem: http://www.oscat.de/community/index.php/topic,1825.msg9681.html#msg9681


[gelöscht durch Administrator]

Gut, mittlerweile kann Ich ein kleine Datei Senden mit den Einstellung SYSLIBSOCKETS_OPTION := BYTE#2@0000_0001;
Dass heißt das wahrscheinlich fast alle Moeller / MicroInnovation / Eaton targets mit diese Einstellung die Netlib von Oscat nutzen können.

Aber, wie gesagt, kleine Dateien kann Ich über FTP senden. Große Dateien aber nicht   ???

Eine Fehler habe Ich gefunden im IP_CONTROL.
IF S_BUF.SIZE > 0 THEN
   IF c_ready AND c_enable THEN
      IF NOT s_active AND IP_C.MAILBOX[2] = 0 THEN
         (* Gesamtanzahl an Bytes limitieren und uebergeben *)
         s_total := LIMIT(0,UINT_TO_INT(S_BUF.SIZE),r_max_size);

Dass muss wahrscheinlich s_max_size sein.
Wenn Ich das anpasse werden von größere Dateien nur die erste 4 KB gesendet. In FTP_CLIENT werden die Schritten 200 und 210 verschiedenen mahlen wiederholt. Doch vermute Ich dass da etwas Falsch geht mit das anordnen der Dateistückchen. Ein bisschen Hilfe könnte Ich hier sicher nutzen.
Anbei mein Programm und ein Beispiel von ein Datei die Ich gerne über FTP senden möchte.


[gelöscht durch Administrator]

Dass loggen der Daten lauft ja mittlerweile.
Nächste Schritt soll dass übertragen zu einem Server sein.

Dass loggen wird gemacht auf ein Eaton (Micro Innovation) XVS-460-15MPI, ein sogenanntes HMI-PLC.
CodeSys 2.3.9.35 mit "oscat_basic_333.lib" und "codesys_network_130.lib".
Auch den Demo "DLOG_FILE_CSV_FTP_DEMO" kommt mit ERROR_T = 2 und ERROR_C = FF 00 00 00

Irgendwie vermute Ich dass SYSLIBSOCKETS_OPTION ein bestimmte Wert haben soll.
Welche?
Ist dass irgendwo dokumentiert?

Vielleicht kann jemand mir bestätigen was Ich hier unten behaupte.

DLOG_STORE_FILE_CSV hat ein Fehler wenn in ein Datei mehr geschrieben wird als im PT.BUFFER passt.
Wenn Ich meine log Dateien nachsehe vermisse Ich in regelmäßige Abstände ein Zeigen.
Soweit Ich jetzt diese wunderschöne Funktionsbausteine verstehe wird hier auf die Falze "size" begrenzt.

20:   IF X.UCB.BUF_COUNT > 0 THEN (* Einträge vorhanden *)
      X.UCB.D_MODE := 10;
      UCB(DATA:=X.UCB); (* Element lesen , aber noch nicht entfernen *)
      IF X.UCB.D_HEAD = WORD#16#FF00 THEN (* LOG_STOP Command *)
         X.UCB.D_MODE := 11;
         UCB(DATA:=X.UCB); (* Element entfernen *)
         log_stop := TRUE;
         step := 40; (* Daten schreiben *)
      ELSIF idx + LEN(X.UCB.D_STRING) + 2 < SIZEOF(PT) THEN (* Platz für Element vorhanden ? *)


Wie Ich es sehe muss nur auf die Abmessung der Buffer geachtet werden und nicht auf die Abmessung von ganzen PT. Also:
      ELSIF idx + LEN(X.UCB.D_STRING) + 2 < SIZEOF(PT.BUFFER) THEN