Datalogger con connessione FTP
Home › Forum › Programmazione IEC 61131 (LogicLab) › Datalogger con connessione FTP
- Questo topic ha 10 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 3 anni, 1 mese fa da
Sergio Bertana.
-
AutorePost
-
Settembre 17, 2020 alle 11:05 am #57591
Fulvio Zucchi
PartecipanteBuongiorno, ho preso l’esempio del datalogger su FTP dal forum e l’ho adattato alla mia esigenza (Articolo), in pratica devo registrare i dati e trasferirli ogni giorno su un server FTP in rete locale. Ma il tutto funziona solamente in parte, mi crea i file locali ma non mi crea quelli sul server FTP, il modulo CPU utilizzato è quella con Raspberry.
Settembre 17, 2020 alle 11:10 am #57620Sergio Bertana
Amministratore del forumLa prima considerazione da fare è accertarsi che il server sia un FTP e non un SFTP, il FB FTPClient si connette solo a server FTP, e di avere correttamente definito la porta di connessione al server oltre alle credenziali di accesso.
Ti consiglio di fare un piccolo programma utilizzando con un copia/incolla l’esempio riportato sul manuale (Vedi manuale). Se utilizzi la nuova versione del FB ed esegui lo spionaggio (Vedi manuale), puoi verificare se la connessione al server avviene correttamente e capire la causa del tuo problema.
Febbraio 17, 2022 alle 8:12 am #63930Rubox
PartecipanteSu uno dei sistemi Slimline sto avendo l’errore 10063215. Ho inteso che è relativo a FTPClient da console di spionaggio, ma non trovo riferimento nell’elenco degli errori a cosa può essere dovuto.
Altri 3 sistemi usano lo stesso programma e funzionano egregiamente, mentre questo si connette al server FTP, inizia il trasferimento, ma non lo porta mai a buon fine.
L’unica differenza è che il file che deve trasferire è molto più grande degli altri. Mi può cortesemente dire a cosa si riferisce l’errore che cerco di trovare la soluzione?
Febbraio 17, 2022 alle 8:18 am #63932Sergio Bertana
Amministratore del forumNon trovi l’errore nella pagina elenco errori perchè abbiamo rilasciato una nuova versione della libreria eLLabNetworkLib (La puoi scaricare dal sito) con una nuova versione del FB FTPClient.
L’errore 10063215 adesso è diventato 10063415 ed identifica un errore dovuto al fatto che su comando Store durante il trasferimento del file sul server il server ha chiuso la comunicazione.
Febbraio 17, 2022 alle 11:49 am #63933Rubox
PartecipanteLa cosa che trovo strana è che il server mi chiuda la comunicazione solo su questo sistema: sono 4 sistemi identici (stesse CPU, con lo stesso programma utilizzando le stesse versioni delle librerie): 3 spediscono i file senza problemi, il quarto no.
C’è un qualche limite sulla dimensione del file trasferibile?
Sul server FTP non ho imposto nessuna restrizione, ma potrebbe essere l’unica differenza tra questo sistema e gli altri.Febbraio 17, 2022 alle 2:48 pm #63936Sergio Bertana
Amministratore del forumIn effetti è strano, mi sembra di capire che il server FTP è lo stesso per tutti i sistemi, ma i vari SlimLine sono su reti e connessioni diverse.
Non mi dici se dai sistemi che funzionano hai provato ad inviare un file di grosse dimensioni.
Potresti provare ad impostare un MTU sull aconessione ad un valore inferiore al valore di default che è 1500. Perchè molte volte nella rete dei dispositivi che gestiscono la connessione ad Internet ci sono dispositivi che hanno problemi con MTU di 1500. Per impostare l’MTU utilizza il comando IfConfig 0 -mtu 1024 (Od inferiore) vedi manuale.
Febbraio 17, 2022 alle 3:17 pm #63937Rubox
PartecipanteIl server FTP è lo stesso per tutti i sistemi, e allo scoccare della mezzanotte i vari sistemi spediscono il file.
Ogni sistema ha un suo account utente per l’FTP, ogni utente ha 10 connessioni simultanee possibili.
Le connessioni sono realizzate tutte con modem/router 4G con SIM M2M.Non riesco a provare a far spedire file di grosse dimensioni agli altri sistemi perché non li posso fermare, o rischiare di fermarli. Posso però provare su quello che non funziona a spedire file più piccoli (mi ritorna domani in ufficio), e poi a modificare il valore MTU del sistema.
Sto anche approntando un programmino semplice che prenda un file dalla scheda e lo spedisca via FTP senza che ci siano altre connessioni in rete (HTTP con richieste POST e EmailSend).
Febbraio 25, 2022 alle 9:04 am #63947Rubox
PartecipanteNon so dove sbaglio, ma quando do il comando per cambiare il valore di MTU, la console mi risponde con un Wrong command parameter.
Febbraio 25, 2022 alle 9:09 am #64016Sergio Bertana
Amministratore del forumC’è un bug nel firmware, il comando viene accettato solo se l’utente si è loggato come User.
Quindi dovresti loggarti come utente User (User:User come credenziali di default se versione firmware precente alla SFW198E000).
Per le versioni successive occore definire un utente con credenziali User utilizzando il comando UserConfig.
Febbraio 28, 2022 alle 8:05 am #64040Rubox
PartecipanteHo provato ad abbassare il valore di MTU ma non risolve in questo caso. Nell’elenco degli errori mi trovo la seguente stringa:
[SFR052][3020] Fct:eFGetOSpace [0x00000000]
E blocca la connessione sempre alla stessa quantità di dati:
18:22:27.797260| FTPClient:Lg|Data transfer start
18:22:43.185233| FTPClient:Lg|Sent:53248 bytes of data
18:22:43.187474| FTPClient:Er|Error:10063215, on CaseNr:513.Ho provato anche la nuova versione di FTPClient ma senza successo.
Il file da trasferire è un 1MByte, ma si blocca sempre alla medesima dimensione, e questa dimensione dipende ma DBSize che imposto in FTPClient.
C’è qualcosa che sbaglio ma non riesco a venirne a capo.
Febbraio 28, 2022 alle 8:12 am #64043Sergio Bertana
Amministratore del forumL’errore FGetOSpace [0x00000000] indica che alla funzione FGetOSpace è stato passato un file pointer null.
Mi dà l’idea che il server FTP abbia chiuso la connessione e quindi il file pointer del TCPClient che deve inviare i dati al server essendo stata chiusa la connessione è eNULL.
Puoi provare a spiare la connessione con Wireshark per vedere se si riesce a capire qualcosa di più.
Il fatto che sono stati inviati oltre 53Kb di dati indica che alcuni pacchetti di dati sono stati regolarmente scambiati (Ipotizzando 1Kb a pacchetto i due sistemi si sono scambiati una 5oina di pacchetti).
-
AutorePost
- Devi essere connesso per rispondere a questo topic.