TwinCAT 2 e data logger su file estero

Causa un fenomeno complesso da diagnosticare che ho sul programma di una macchina e che fa ammattire me, il costruttore, il cliente, e del quale nessuno di noi riesce a darsi una spiegazione plausibile, volevo fare un data logger su file, da TwinCAT, per memorizzare tuta una serie di info sull'eveluzione dell'elaborazione del programma, per tentare di capirci qualcosa di più sul problema in essere.

Il data logger che ho messo in piedi, efficiente se vogliamo, si porta dietro gli handicap del dover lavorare dall'interno di un runtime SoftPLC sui file del sistema operativo, con la conseguenza che tra tempi di apertura dei files, rinomina, ecc, il mio data logger con la gestione file dall'interno del SoftPLC, per quanto ottimizzato, è inutilizzabile. Infatti si assenta, alle volte, oltre un secondo, (causa il S.O.), per le operazioni di flush dati su file, ecc.

In soldoni significa perdere i log di tutti i dati in quel lasso di tempo e, siccome capita sovente, nella sostanza è una tecnica inutilizzabile. Immaginando una task a 5 ms, che debba loggare una ventina di stringhe, si traduce in una molde di dati da bufferizzare enorme, che satura i buffer prima che il sistema abbia il tempo di scaricare sul file e "flushare".

Mi stavo guardando attorno, ma non vedo, nenanche in libreria, possibilità di loggare stringhe, all'interno del SoftPLC, su un file predisposto.

Contrariamente ad altri sistemi di archiviazione dati, nel mio caso era mio desiderio di storicizzare tutta una serie di informazioni di ogni ciclo di scansione del programma. Non stiamo parlando di tracciare un trend, ma di debuggare un fenomeno, dalla natura e ragione ancora sconosciuta, ed unico modo per farlo e, per me, ora come ora, loggare tutti i dati immaginabili, in formato testuale, su un file poi facilmente leggibile.

Qualunque idea possiate offrirmi per ambiente CoDeSys la valuterò in ogni caso.

creare un sistema che traccia un log abbinato ad un task di un plc ch egira a 5ms....
quello che chiedi non è proprio una passeggiata ipotizzando che devi salvare 10 variabili e questo ogni 5ms vuol dire creare un tracciato su disco 2000 record, sicuramente per quantità di dati con i pc di oggi no ci sono problemi credo che il collo di bottiglia sia catturare l'evento ed il trasferimento dal softplc al sistema di log.

io personalmente creerei un sistema di buffer dentro il softplc con logica FIFO, e tramite un pc separato collegato in rete salverei il log.

ma sinceramente credo che costi di sviluppo e di attrezzatura influiscono non indifferentemente.
altra soluzione è acquistare un sistema log gia fatto

Nella semplicità del tuo intrvento, cisco, hai centrato il problema. Ne i SoftPLC, nei i PLC più tradizionali, e men che meno i resto dell'automazione che orbita attorno a uesti, non sono ancora orientati ad un uso e programmazione di ampio respiro, ma si limitano a lasciare l programmatore di turno veramente poco, poco spazio di manovra.

Hai perfettamente centrato e focalizzato l'unica architettura che potrebbe funzionare. Un buffer FIFO, già eistente, che, invece di inviare i dati ad un logger su file, li invia ad un server veloce per il log; su file o database che sia, ma libero dai limiti di un softPLC e del suo processore e S.O.

Ma qui, anche se ora vado un poco OT, si apre lo spiraglio per discutere più a ampio raggio di programmazione PLC. possibile che nel 2015, e prossimamente 2016, si veda questo oggetto unicamente come sostituto di logiche booleane cablate? Giusto oggi una persona mi ha domandato come mai nei programmi io faccia uso di tutti i linguaggi di programmazione possibili e non mi limiti al più "facile" ladder. (Già queste poche righe potrebbe bastare, sapendole leggere, a descrivere la mia rabbia nei confronti di un mondo e modo di programmare errato dell'automazione industriale). Restiamo nel tema dei log dati: possibile che nel 2015/2016 io debba prima scrivere un programma booleano o poco più su PLC, poi debba riscrivere un altro programma per runtime grafico, (di consegiuenza con diverso linguaggio e praticamente diverso ambiente di sviluppo), e debba appoggiare a variabili numeriche per, ad esempio, far comparire testi sul runtime grafico? PEr non parlare poi dei forti limiti che un poco tutti i sistemi hanno nell'uso dei puntatori, (Escluso forse CoDeSys. Mi riferivo di più ad ambienti di altri marchi blasonati).

Mah! PAzienza... Sono andato OT, ma il senso del post era anche questo: siamo del 2015 e su un PLC non riusciamo a scriverci un log su file. 5 ms ti sembra una velocità eccessiva? 200 volte al secondo? Allora tanto vale tornare a fare macchine a camme se non sappiamo e pretendiamo di fare di meglio.