- Questo topic ha 19 risposte, 1 partecipante ed è stato aggiornato l'ultima volta 4 anni, 2 mesi fa da
.
-
Post
-
Ho ricevuto richieste di clienti che desiderano utilizzare i nostri prodotti SlimLine e Netsyst per realizzare un DataLogger. In pratica la necessità è quella di acquisire valori sia analogici che digitali oppure leggere dati da strumenti via Modbus e storicizzarli ad intervalli regolari in un file csv sul sistema locale.
A questa esigenza facilmente realizzabile utilizzando il FB StringToLogFile_v1 (Topic), ho aggiunto la possibilità di trasferire il file di log dal disco locale del sistema verso un server remoto nel cloud via protocollo FTP utilizzando il FB FTPClient (Topic).
Il problema da superare in questa applicazione è il salvataggio dei records di log mentre è in corso l’operazione di trasferimento sul server FTP del file locale. Questo problema è facilmente superabile con il FB FIFOFile, che permette di memorizzare su file i dati e poi di estrarli quando possibile (Topic). Come si vede il programma di esempio storicizza i dati nel FIFO ogni minuto e contemporaneamente se il file locale di log è libero legge dal FIFO e salva nel file csv.
Ogni ora viene eseguita la connessione al server remoto (Nell’esempio è sul sito di AlterVista) e trasferito il file locale sul server remoto. Il nome del file sul server remoto viene creato componendo il valore di Data/Ora a cui il log è riferito (Avremo files del tipo 20160404-23.csv, 20160405-00.csv, ecc…).
Viene fornito il programma sorgente in modo che ognuno possa modificarlo in base alle proprie necessità (Stampa programma, Download programma).
Sto utilizzando da alcuni mesi il programma Ptp139a000 dopo averlo modificato per le esigenze del mio cliente nella parte di generazione delle stringhe, ma la logica a stati è rimasta quella originale. Ho riscontrato solo un piccolo problema: occasionalmente – due volte, la seconda due giorni fa – la chiamata
iSysremove:=(Logger.Filename); (* Cancello file locale *)
non va a buon fine e quindi il file cresce di dimensione ed ha le intestazioni replicate ogni ora. SysLastError è semplicemente 9961200 Errore nella cancellazione del file. Se fermo il programma, il sistema riparte senza problemi e l’ultima volta è andato avanti per 10 giorni.
Ho pensato che potrebbe essere un problema dovuto al blocco FTPClient (eLLabNetworkLib_A200) che non rilascia il file e per ovviare ho pensato di modificare il programma in modo da separare le due operazioni (attesa fine ftp, cancellazione) con un nuovo case 13. Però potrebbe anche dipendere dal blocco StringToLogFile_v1 e quindi pensavo di aggiungere:
Logger(Enable:=TRUE, Write:=FALSE);prima di Sysremove.Hai visto bene nel FB FTPClient c’era un bug che poteva creare il problema che tu lamenti, ho corretto il FB ed ho creato la nuova versione del programma PTP139A100, puoi eseguire il download dal sito.
In questa versione c’è il nuovo FB FTPClient, puoi aprire il progetto ed esportare il FB in una tua libreria, per poi importarlo nel tuo progetto sovrascrivendo il vecchio FB.
Scrivo in quanto ho realizzato un programma per il log orario su file mensili di un certo numero di grandezze acquisite via modbus RTU da 3 PLC schneider serie micro, lo SlimLine funge da data concentrator e datalogger, fino a qui tutto bene, i file vengono correttamente salvati sulla SD installata a bordo e risultano consultabili e scaricabili tramite Filezilla.
Il mio cliente avrebbe però la necessità di effettuare il download dei files tramite batch script da suo server in modo automatico e non è riuscito in alcun modo a connettersi al server FTP dello slimline ed effettuare il download, esiste una soluzione ?
Se come dici i files sono accessibili tramite Filezilla ma non riesce il batch script dal server a connettersi il problema è nello script utilizzato.
Sei sicuro che utilizzi una connessione FTP e non SFTP? Può essere che il programma FTP usato nel batch utilizza comandi FTP non implementati nel nostro server FTP, in tal caso mi occorrerebbe un report della connessione per capire quale è il problema.
Ma perché fare scaricare da un server i files quando può essere lo SlimLine ad inviarli al server FTP nel cloud, tra l’altro in questo modo il trasferimento è possibile anche se lo SlimLine è su una rete NATtata e non raggiungibile da Internet.
Devo eseguire periodicamente il trasferimento di un file in FTP da un sistema SlimLine, ho scritto un file batch con i comandi:
@ECHO OFF
echo Trasferimento FTP avviato
ftp -s:cmd.ftp 192.168.0.xxx
echo Fine trasferimentoEcco il contenuto del file di comando FTP “cmd.ftp”:
Admin
Admin
cd /Storage
binary
get /nomefile.csv
quitMa non riesco a scaricare il file. Non posso caricare i dati su cloud in quanto non ho accesso internet, la rete di impianto è separata dalla rete stabilimento dove è presente internet.Come posso fare ?
il comando ftp di Windows non gestisce il trasferimento passivo che è il traferimento gestito dal server FTP di SlimLine. Quindi se vuoi scaricare i files in automatico devi utilizzare un server LInux (Che supporta il trasferimento passivo) od un client per Windows che supporti il trasferimento passivo.
Ma visto che il tuo impianto è in rete locale, puoi sempre fare scaricare in automatico sul tuo server FTP i dati direttamente dallo SlimLine non è il caso di utilizzare il cloud basta definire l’indirizzo IP del tuo server FTP.
Dove posso trovare l’ultima revisione per il FB FTPClient? Lo chiedo perchè sto effettuando dei test comparativi fra i function block trovati fra i vari post del forum, FTPClient e FTPClient_v1 e per adesso solo il blocco FTPClient funziona senza andare in errore. Il blocco FTPClient_v1 in mio possesso genera il seguente warning in fase di compilazione:
warning G0015: MOVE => Accumulator extension
ed il seguente errore runtime:
[Admin]> syslog
[W] SFW184 [26/07/2018 14:52:31] 6000, User program error:10063030L’ultima versione della FTPClient_v1 si trova nella libreria networking eLLabNetworkLib_B000, scaricabile dal sito. La nuova versione v1 rispetto alla precedente gestisce l’allocazione dinamica dei buffer di memoria (Usando la funzione RMalloc). In questo modo è possibile dimensionare a piacere i pacchetti TCP scambiati con il server (Il massimo è 1500 bytes).
L’errore 10063030 indica che non è stata definita la dimensione del buffer (Parametro DBSize), probabilmente hai usato un progetto realizzato con la precedente versione e non hai definito il parametro. Dai una occhiata all’estratto del manuale e vedi l’esempio riportato.
Stò usando l’ultima versione della libreria (eLLabNetworkLib_B100) e compilando il programma di esempio in modalità SIMULAZIONE ho il seguente errore:
Generating function block FTPClient_v1
aborted.FTPClient_v1(394) – error G0129: NULL => Comparison between reference and non-reference
FTPClient_v1(519) – error G0129: NULL => Comparison between reference and non-reference0 warnings, 2 errors.
Resuscito questo post poiché sto approntando un sistema che invii in automatico dei file di log giornalieri su un server FTP.
Guardando il listato del programma capisco correttamente che nel caso il server FTP non sia disponibile il programma si “arresta” nella condizione CaseNr 11 fino a che la connessione non viene stabilita? Anche per il case 12, se l’operazione non viene conclusa, il programma continua con il CaseNr 12?
Il programma utilizza il FB FIFO per gestire il logging, in questo modo il record di log viene salvato nel file di FIFO e poi se il file di log è libero viene trasferito nel file di log (Case 0), questo permette di non perdere records quando il file di log è occupato dal trasferimento in FTP.
Quando viene comandato il trasferimento del file di log sul server (Case 10) iniziano le sequenze di connessione che potrebbero andare in errore, in tal caso si attiverebbe l’uscita Fault che porta l’esecuzione sul Case 20.
In caso di errore viene incrementato il numero di errori ed atteso un tempo prima di ritentare l’invio.
Quindi si certo il programma rimane bloccato nel Case 11 fino alla avvenuta connessione con il server ma se non riesce a connettersi dopo il tempo definito nel parametro Timeout (Vedi FTPClient_v1) si attiva l’uscita Fault. Stesso discorso per il Case 12 dove viene atteso il completo trasferimento del file.
Mi ero perso la riga 70 del listato PDF del programma, pensando erroneamente che tutta la gestione del trasferimento FTP fosse nello statement CASE. OK, adesso ho compreso il tutto, e funziona anche tutto.
Io appoggio i dati su un file sulla scheda SD (così ci sono comuque) e non appena cambia il giorno il programma spedisce il file precedente sul server FTP.
Grazie della precisazione dell’aiuto sempre puntuale.
Mi permetto di ritornare sul listato del programma (premesso che ne sto usando un altro leggermente differente), ma supponendo di essere nel case 20 mi ritrovo Store=FALSE. Si passa al case 21 e dopo il tempo di 10 minuti mi porto al case 10. Tenta la connessione e passa al case 11. Qui se non c’è il server disponibile (nella mia prova ho scollegato il cavo di rete) dopo un tempo di Timeout va in Fault.
Però la riga 70 verifica che ci sia Store a TRUE eFault a TRUE per andare al case 20 e gestire l’errore di connessione. Store diventa vero solo dopo aver stabilito la connessione al case 11. Io ho eliminato la verifica su Store a vero alla riga 70 e tutto sembra funzionare correttamente.
Il FB FTPClient se ha Connect=TRUE cerca di connettersi al server FTP, se non ci riesce (Come nel tuo caso che hai staccato il cavo) dopo il tempo di timeout genera errore 10063050 disabilita la connessione e la riabilita ritentando di connettersi.
Se non c’è connessione è inutile passare a cases successivi, quindi il programma non passa volutamente al case 20 ma continua ad aspettare di completare la connessione. Se tu riattacchi il cavo il tutto dovrebbe ripartire.
Certo in questa condizione essendo fermo nel case 11 continuerei ad avere il file di log locale bloccato ed i records di log andrebbero a saturare il FIFO. Ma se non si riesce a connettersi al server FTP non c’è molto altro da fare.
Nel tuo caso avendo tolto il controllo su Store salti al case 20 temporizzi poi riprovi e dopo 3 tentativi riprendi a salvare nel file di log locale riprovando ad inviarlo alla prossima scadenza. Può essere una soluzione per problemi di connessione che durano molto tempo. Ma se il cavo di rete si stacca continuerai a salvare nello stesso file di log saturandolo. Nel caso prevedere un qualche avviso magari con lampade di segnalazione o altro.
- Devi essere connesso per rispondere a questo topic.