Come si può ottimizzare il programma del PLC per renderlo più veloce? In che modo è possibile risparmiare memoria nei controllori logici programmabili? Ci sono differenze in termini di prestazioni programmando i PLC nei diversi linguaggi?
Benvenuto su questo sito, in questo articolo parliamo di ottimizzazione del software per PLC, e vedremo alcuni consigli utili per rendere i programmi più performanti; le considerazioni che faremo sono di carattere generale, e riguardano in parte sia come i plc funzionano, che il modo in cui scriviamo il programma.
Chi programma PLC sa che in alcuni casi le performances del software possono rappresentare qualcosa a cui badare, anche se la maggior parte delle volte, i processori sono abbastanza potenti da non doversi preoccupare di ottimizzare il programma.
Quando si lavora con controllori grandi come il Simatic S7-1500 o l’Allen Bradley ControlLogix, i tempi di scansione sono veloci e la memoria abbonda, se il sistema d’automazione è dimensionato correttamente, per la maggioranza delle applicazioni il programmatore è libero di scrivere il software come preferisce.
Cosa accade invece quando si utilizzano processori compatti, e si cerca di spingerli al massimo delle loro possibilità per risparmiare sui costi? In questo caso, ci sono alcuni accorgimenti che possiamo seguire per non sovraccaricare la cpu; li vediamo nei prossimi paragrafi.
I dati strutturati e la memoria del PLC.
Oggi i processori hanno molta più memoria di un tempo, tuttavia non è raro trovarsi con poca memoria di caricamento, perché per esempio si portano sul controllore pezzi di programma che non vengono utilizzati, come nel caso di variazioni al software che una volta collaudate, si lasciano dietro istruzioni non più necessarie.
Per quanto riguarda il dimensionamento delle variabili, i plc di ultima generazione offrono la possibilità di creare tipi di dati personalizzati strutturati; questi rendono la scrittura del programma più piacevole, tuttavia possono portare a uno spreco di memoria.
Facciamo un esempio per comprendere meglio questo concetto, e supponiamo di avere un tipo di dati strutturato che rappresenta un ciclo di lavorazione presente 50 volte nel nostro impianto; ecco come potremmo dichiarare questo tipo di dati.
bit_stati: array [0..100] of bool
temporizzatori: array [0..10] of IEC_TIMER
dati_interi: array [0..20] of Int
dati_reali: array [0..20] of real
stringhe: array [0..20] of string[40]
Se abbiamo 50 variabili di questo tipo, avremo almeno 5000 bit, 500 temporizzatori, 1000 interi, 1000 reali, e 1000 stringe da 40 caratteri.
Per un PLC grande questi numeri non rappresentano un problema, tuttavia se utilizziamo un sistema compatto, potremmo ritrovarci a fare i conti con la memoria.
Nella figura che segue vediamo l'occupazione di memoria della struttura appena descritta, in un blocco dati del PLC Siemens.
Creando una base dati nel Simatic S7-1200 con questa struttura, dichiarando 50 variabili di questo tipo, abbiamo un consumo di memoria di quasi 60 Kbytes, decisamente troppo; in pratica non rimarrebbe spazio per il programma.
In questi casi, molto spesso basta analizzare quali davvero sono le esigenze di programmazione, per scoprire che magari un ciclo non necessiterà di 100 bit per gli stai ma 80 saranno più che sufficienti, che con 7 temporizzatori per ciclo riusciamo a scrivere quello che ci serve, e che stringhe, interi e reali, sono stati previsti in abbondanza, quando invece 15 per tipo basterebbero.
Ristrutturando il tipo di dati, otteniamo più del 30% di risparmio sulla memoria.
Quello che accade è che quando si usano dati strutturati, si tende a sovradimensionarli per essere sicuri di disporre di ciò che ci serve, senza dover eventualmente modificare il tipo; in realtà quasi sempre si può risparmiare.
Nell'immagine seguente troviamo la struttura dati ridimenzionata, possiamo notare il notevole risparmio di memoria.
Scrittura del programma e occupazione memoria del PLC.
Anche il modo di scrivere il programma influisce sul consumo di memoria. Routines con molti interrupts e salti richiedono memoria per gestire lo stack di esecuzione; al contrario, programmi scritti in maniera lineare (anche se più lunghi da editare), occupano meno memoria, e sono anche più veloci da eseguire.
Il PLC interpreta bene istruzioni elementari, per cui quando creiamo routine personalizzate e parametrizzate, è vero che ci agevoliamo molto nella stesura del software, per il controllore però questo significa lavoro in più.
Le istruzioni sulla stessa linea di programma sono interpretate più velocemente delle stesse istruzioni messe su righe (o rami ladder) separate.
I paralleli occupano più delle serie, e le istruzioni di calcolo complesse occupano di più di quanto farebbero le stesse istruzioni scomposte in istruzioni più elementari.
In linea di massima, tutto ciò che incorpora e raggruppa una serie di istruzioni, richiede al PLC qualche risorsa in più per scorporare la funzione ed eseguirla.
Istruzioni ridondanti e istruzioni non utilizzate.
Quando si lavora su programmi complessi, soprattutto se si devono collaudare modifiche mentre l’impianto è in marcia, a volte si duplicano delle funzioni per apportare le variazioni richieste, poi al momento giusto si caricano nel PLC.
A volte succede che le vecchie funzioni, ormai non più schedulate per l’esecuzione, vengano lasciate nel controllore pensando “non si sa mai, un domani potremmo dover tornare indietro”; questo è un altro spreco di memoria.
Certo, se abbiamo molta memoria libera a disposizione non è un problema, ma è buona norma non esagerare, e non considerare la memoria del plc come un archivio.
Se è necessario oppure se vogliamo tenere le versioni precedenti dei programmi, meglio salvarle sull’hard disk del computer e archiviarle su un qualsiasi supporto di memoria.
