PnSistemi Gestione MicroControllori/Plc tramite Integrated Development Environment (IDE) su Pc

Descrizione del sistema

La genesi del sistema nasce dalla esigenza di automatizzare un impianto di pirolisi (generazione di gas combustibile e alimentazione di un co-generatore) nelle sue tre parti fondamentali: la vasca di alimentazione con il feeder per la biomassa, il “gasogeno” vero e proprio (ovvero la macchina che compie il processo di generazione del gas a partire da una biomassa solida in carenza di ossigeno), il generatore; era necessario quindi pilotare i tre elemetni con programmi distinti.

Ho sfruttato un ambiente di sviluppo da noi realizzato per gestire base dati; sono state progettate delle tabelle per gestire le funzioni tipiche dell’automazione, ovvero l’interfacciamento con sensori e attuatori, l’elaborazione dei dati e dei successivi comandi di pilotaggio degli attuatori, la creazione di una interfaccia di comando e la raccolta dei dati di funzionamento.

Il progetto nasce praticamente da un foglio bianco, in quanto non si basa sulle caratterisitiche di prodotti esistenti e poi adattati o migliorati, ma è la traduzione a livello organizzato del normale procedimento di sviluppo di un progetto, assimilabile alla produzione di un flow-chart del funzionamento dell’impianto e della distinta base dei suoi componenti. E’ una fase inevitabile da sviluppare all’interno di ogni progetto: spesso viene svolta in maniera implicita, nel nostro software viene esplicitata al massimo livello.

Un’altra esigenza era quella di potere gestire qualsiasi tipo di “apparecchiatura” ci si trovasse di fronte in quanto il progetto era in continua evoluzione.

Tutti i dati delle applicazione sono archiviati su diversi database, quindi il limite di dimensione di ogni applicazione è quello della dimensione del disco del Pc….praticamente illimitato. Inoltre immaginate di avere un Plc con la potenza di clock o la ram di un Pc.

Comunicazione con Micro o Plc

La comunicazione da Pc e Plc/Micro è gestita tramite le varie porte installate sul Pc, quindi seriali o Usb, Ethernet, ed i loro vari protocolli di comunicazione. Siccome a grandi linee questi ultimi sono basati su scambio di sequenza di caratteri (Ascii,hex,ecc.) è praticamente possibile emularli tutti.

Il Plc o il Micro vengono precaricati con un software standard (di cui ho diverse versioni per i linguaggi ST e C/C++), che non varia a seconda della applicazione da sviluppare. E’ possibile interagire ad esempio con tutte le periferiche Modbus o con altri standard industriali.

Il linguaggio di colloquio per scambiare dati tra Pc e Plc/Micro è in ASCII quindi più leggibile per facilitare la fase di debug.

Il software del micro non fa altro che ricevere un comando, eseguirlo e ri-trasmettere il risultato (valore numerico o successo, ad esempio). Così la programmazione del micro si riduce all’osso e non cambia aggiungendo sensori o attuatori alle porte del micro che gestisce l’ impianto.

Apparecchi di rete già predisposti per la comunicazione come gli inverter o come certi tipi di sensori sono gestibili direttamente senza passare dal Plc. Ciò aumenta di molto le capacita di gestire elementi delle automazioni, in quanto è possibile bypassare il limite fisico dei Plc e accedere direttamente alla app sul Pc.

All’interno del software precaricato sul micro sono state implementate la funzione “encoder”, “contagiri”, “PID”, per sfruttare direttamente le sue capacità real time;

Sezione Controllo e acquisizione dati.

Esempio di programmazione condizionata: un timer di evento

Come prima operazione per un timer creiamo tre variabili: la variabile “ora di sistema” che impiegheremo per tutti i timer, la variabile “intervallo di evento”, la variabile “ora ultima esecuzione evento”.

La seconda operazione è creare la tabella dei comandi elementari che contiene gli elementi da confrontare e l’operazione da effettuare in caso di esito positivo del confronto.

Utilizzando più righe con lo stesso nome e ordinate con un progressivo si possono comporre diversi test di esecuzione su diverse variabili con i comuni operatori logici.

Il successo della valutazione del test del comando può portare a: esecuzione di una operazione verso un attuatore e/o assegnazione di un valore ad una variabile, oppure nulla.

La lettura dei sensori (o di una serie di sensori) può essere forzata all’interno del comando o affidata al ciclo standard.

Per comporre un ciclo di runtime si definisce una tabella che associa i vari comandi al determinato ciclo; il ciclo viene gestito tramite una variabile che ne forza la ripetizione o consente il passaggio al ciclo successivo.

Quindi di solito ci saranno cicli di avviamento, un ciclo centrale con una variabile di loop, cicli di spegnimento.

L’esecuzione dei vari cicli o l’avanzamento al ciclo successivo è sempre determinato dalla assegnazione di una variabile come risultato della esecuzione del ciclo.

Durante il funzionamento è possibile modificare i valori delle variabili nella tabella assegnazioni, anche durante il runtime; è l’operazione che viene fatta tramite il pannello operatore alla pressione dei tasti.

É possibile predefinire dei formati di output (per pagine web, stampe e pdf) e condizionarli ad eventi del programma, cosi come a tasti operatore.

Il pannello Hmi

Si basa sulla tabella variabili, e su altre tabelle che definiscono le sequenze e le proprietà da mostrare nel pannello. Una variabile può essere usata per un bottone di accendi spegni o per uno strumento a lancetta, piuttosto che per un elemento sinottico.

Per ogni variabile si può definire il formato di rappresentazione a video, possono essere usate indifferentemente variabili alfanumeriche o numeriche.

Nel caso di elementi grafici si possono usare le proprietà standard per costruire strumenti analogici a lancetta, oppure creare dei bitmap appositi da utilizzare come elementi sinottici

Archiviazione Dati

I dati storici si archiviano con un intervallo a partire da 1 secondo. Ovviamente siccome i dati sono salvati sul disco di un pc in modo che praticamente non ci siano limiti di archiviazione.

I dato storici vengono accumulati a partire dai dati di sessione e contengono il valore delle variabili al momento della scrittura del file di log.

Per ogni variabile è possibile definire se deve essere archiviata oppure no.

Il debug

Il debug è attivabile a scelta dell’operatore anche durante il runtime.

Esso si basa sulla scrittura su disco di tutte le operazioni effettuate nel run-time, scritte in linguaggio chiaro con ora di esecuzione e durata esecuzione;

oltre a risolvere facilmente i problemi logici di esecuzione consente di conoscere i valori delle variabili in ogni istante anche passato;

è possibile ottimizzare la durata dei cicli così da evitare inutili operazioni che possono rallentare il ciclo di esecuzione; ad esempio la lettura dei sensori ambientali tipo umidità può essere eseguita a tempi poco ravvicinati, mentre il contagiri di un motore critico per l’applicazione può essere letto l’istante prima che si debba valutare la sua operatività.

E’ possibile in questo modo valutare il ritardo di lettura per da adeguare la logica di programmazione alle prestazioni necessarie.

Per conoscere i tempi di esecuzione in un Plc programmato in maniera tradizionale dovrei costruire dei timer che poi in fase di rilascio dovrei escludere dal sorgente in modo da non occupare risorse di sistema, con continui caricamenti di programma, ovviamente d fare a mcchina spenta, oppure utilizzare se presenti funzioni di debug che comunque non potrebbero essere attive durante il funzionamento dell’impianto.

Il debug mostra il numero progressivo di istruzioni eseguite per ogni decimo di secondo e la durata di ogni istruzione, l’istruzione eseguita e il valore delle variabili utilizzate. Per ogni ciclo viene calcolata la frequenza di ciclo e quella di visualizzazione pannello.

Tempi di esecuzione e sicurezza.

Un problema affrontato e risolto riguardava i tempi di ciclo di una sequenza completa di istruzione: ci siamo accorti che la interazione con la tastiera e i vari dispositivi di input del Pc rallenta l’esecuzione del ciclo a seconda che nella coda degli eventi della tastiera ci siano o meno eventi: la loro assenza (anche di un semplice movimento del mouse) comporta un decadimento delle prestazioni.

Allora abbiamo diviso il runtime in due thread, dei quali uno gestisce il runtime vero e proprio verso il plc e l’impianto senza rallentamenti di sorta, mentre il secondo thread gestisce gli eventi dei sistemi di input e non influenza le caratteristiche di velocità del thread principale.

Questo fa si che si possa valutare caso per caso se la velocità di esecuzione del sistema Pc/Plc rientra nella specifica di sicurezza richiesta dalla macchina pilotata.

Eventualmente il Plc può essere comandato con blocchi di comandi: ad esempio un sensore può essere istruito che ad una determinata soglia di valore agisca direttamente su di un attuatore con il comando appropriato, ovviamente ritornando tutte le informazioni al sistema su PC.

In media vengono eseguite almeno 5000 istruzioni al secondo per il ciclo principale e 1000 per il ciclo di input tastiera, mouse, pannello.

Per ogni istruzione viene creata una riga nel file di log, (quindi fino a 10 righe al secondo).

nel caso di necessità di operazioni a tempo di cpu del micro si possono creare dei set di istruzioni combnate per cui il micro a fronte di un determinato evento il micro può già preordinare l’esecuzione di una operazione, oltre ovviamente ad informare il Pc dell’evento occorso.