Quando una macchina deve leggere sensori, comandare motori e reagire a un’anomalia in pochi millisecondi, la qualità del programma incide direttamente su produttività, sicurezza e manutenzione. La programmazione PLC non consiste solo nello scrivere contatti Ladder: richiede una logica di controllo chiara, la scelta del linguaggio adatto e una verifica rigorosa del comportamento dell’impianto. In questa guida mostro come funziona un PLC, quali linguaggi si usano e come impostare un progetto affidabile nell’automazione industriale.
Una logica ben progettata rende la macchina più veloce da capire e più semplice da mantenere
- Il PLC legge gli ingressi, esegue il programma e aggiorna le uscite in un ciclo continuo.
- IEC 61131-3 definisce i principali linguaggi, tra cui Ladder, FBD, Structured Text e SFC.
- Ladder è efficace per la logica a contatti, mentre lo Structured Text gestisce meglio calcoli e algoritmi complessi.
- La struttura del software conta più del singolo linguaggio: nomi chiari, moduli separati e diagnostica riducono gli errori.
- La sicurezza non può dipendere soltanto dalla logica standard del PLC e richiede dispositivi e procedure dedicati.
Che cosa fa davvero un PLC in una macchina automatica
Un PLC, cioè un controllore logico programmabile, riceve i segnali dai dispositivi di campo e decide quali azioni eseguire. Gli ingressi possono arrivare da sensori di presenza, finecorsa, encoder, pulsanti e sonde analogiche; le uscite comandano invece elettrovalvole, contattori, inverter, servomotori e segnalazioni.
Il funzionamento segue normalmente un ciclo ripetuto. La CPU acquisisce lo stato degli ingressi, esegue le istruzioni del programma, aggiorna le uscite e svolge attività di comunicazione e diagnostica. Questo intervallo, chiamato tempo di scansione, può essere di pochi millisecondi nei programmi semplici, ma cresce quando aumentano il numero di I/O, i calcoli e le comunicazioni.
Immaginiamo una macchina per la lavorazione di precisione. Un sensore conferma la presenza del pezzo, il PLC abilita il serraggio, verifica la pressione e avvia il ciclo solo quando tutte le condizioni sono vere. Se durante la lavorazione viene aperto un riparo o si perde un consenso, il programma porta la macchina in uno stato definito, invece di limitarsi a spegnere un’uscita senza registrare la causa.
La differenza tra logica combinatoria e sequenziale
La logica combinatoria risponde immediatamente allo stato attuale degli ingressi. Per esempio, una pompa può funzionare quando il livello è basso e il consenso generale è attivo. La logica sequenziale, invece, gestisce fasi ordinate nel tempo, come carico, serraggio, lavorazione, scarico e ritorno in posizione iniziale.
Molti problemi nascono quando una sequenza viene costruita con decine di bit sparsi nel programma. Io preferisco definire stati espliciti, condizioni di transizione e azioni associate a ogni fase. Il codice diventa più leggibile e il tecnico può capire subito dove si è fermata la macchina.
I linguaggi disponibili e il ruolo dello standard IEC 61131-3
Lo standard IEC 61131-3 raccoglie le regole principali per organizzare programmi e linguaggi destinati ai controllori programmabili. I software dei diversi costruttori possono usare nomi propri, ma i concetti fondamentali restano riconoscibili.
| Linguaggio | Quando conviene usarlo | Limite principale |
|---|---|---|
| LD, Ladder Diagram | Comandi digitali, interblocchi, consensi e logica simile agli schemi elettrici | Può diventare dispersivo con algoritmi e calcoli complessi |
| FBD, Function Block Diagram | Regolazioni, funzioni riutilizzabili e collegamento visuale tra blocchi | Le reti molto estese sono difficili da seguire |
| ST, Structured Text | Calcoli, array, ricette, diagnostica e gestione di dati strutturati | Richiede maggiore familiarità con la programmazione testuale |
| SFC, Sequential Function Chart | Processi a fasi, cicli macchina e sequenze con transizioni definite | Non sostituisce da solo la logica dettagliata delle singole azioni |
| IL, Instruction List | Manutenzione di applicazioni legacy ancora basate su istruzioni testuali brevi | È poco leggibile e non è la scelta migliore per nuovi progetti |
Il Ladder rimane molto usato perché un elettricista può riconoscere contatti, bobine e autoritenute senza imparare un linguaggio software completo. Lo Structured Text è invece più naturale quando devo eseguire formule, cicli FOR, confronti su array o gestione di ricette. Nella pratica non vedo un vero vincitore assoluto: un progetto ben fatto spesso combina due o più linguaggi.
Ladder, FBD e ST a confronto con un esempio semplice
Per avviare un motore servono normalmente un comando di marcia, un consenso di sicurezza e l’assenza di un allarme. In Ladder questa relazione è immediata da leggere, perché rispecchia la logica dei contatti. In Structured Text la stessa idea può essere espressa in modo compatto:
Motore_Avviato := Comando_Marcia
AND Consenso_Sicurezza
AND NOT Allarme_Motore;Il codice è breve, ma non basta da solo. Occorre definire cosa succede dopo un’interruzione, come viene registrato l’allarme e se il riavvio automatico è consentito. Un programma industriale non deve soltanto comandare l’uscita corretta, ma anche gestire stati anomali e ripartenze controllate.
Come impostare un progetto PLC senza creare confusione
Prima di aprire l’ambiente di sviluppo, raccolgo la sequenza della macchina e trasformo il funzionamento reale in condizioni verificabili. Questo passaggio sembra poco tecnico, ma spesso fa la differenza tra un software stabile e una serie di correzioni aggiunte durante il collaudo.
1. Descrivere il processo prima del codice
La prima domanda non è “quale contatto devo inserire?”, ma “quali condizioni permettono alla macchina di passare alla fase successiva?”. Per ogni fase conviene indicare ingressi richiesti, uscite attive, timer, allarmi e condizioni di uscita.
- stato iniziale e posizione sicura;
- condizioni necessarie per avviare il ciclo;
- azioni eseguite durante la fase;
- tempo massimo concesso all’operazione;
- reazione in caso di sensore assente o consenso perso.
2. Organizzare variabili e moduli
Nomi come M10 o DB4.DBX2.1 possono essere validi per il compilatore, ma aiutano poco chi deve fare manutenzione dopo mesi. Preferisco nomi descrittivi come Sensore_Pezzo_Presente, Comando_Morsa_Chiudi o Allarme_Temperatura_Olio, con commenti brevi e coerenti.
È utile separare il software in aree dedicate a gestione I/O, sequenza macchina, allarmi, ricette, comunicazione e diagnostica. Quando una valvola viene comandata in cinque punti diversi senza una regola precisa, diventa difficile capire perché sia attiva. Un’unica logica di assegnazione riduce questo rischio.
3. Simulare prima del collaudo fisico
Prima di collegarsi alla macchina verifico il comportamento con ingressi simulati, watch table e test delle singole funzioni. Il forcing degli I/O può essere utile, ma va usato con estrema prudenza e rimosso alla fine del test, perché un valore forzato dimenticato può mascherare un guasto reale.
Per un ciclo semplice, preparo almeno questi casi: avvio normale, sensore che non arriva, arresto durante la fase, perdita di alimentazione e ripartenza. Se il programma reagisce bene solo nel percorso ideale, non è ancora pronto per il campo.
Quando scegliere Ladder, Structured Text o una soluzione ibrida
La scelta dipende dal tipo di macchina, dalle competenze del reparto e dalla durata prevista dell’impianto. Un linguaggio elegante ma sconosciuto ai manutentori può creare più costi di un programma leggermente meno compatto, ma immediatamente leggibile.
| Esigenza | Scelta consigliata | Motivo pratico |
|---|---|---|
| Interblocchi e comandi digitali | Ladder | La logica è visibile e vicina agli schemi elettrici |
| Controllo di una sequenza a fasi | SFC con blocchi LD o ST | Gli stati e le transizioni sono facili da diagnosticare |
| Calcoli e gestione di ricette | Structured Text | Le operazioni su numeri e dati risultano più compatte |
| Regolazioni e funzioni ripetibili | FBD | I blocchi rendono chiaro il flusso dei segnali |
| Macchine con molti tecnici di manutenzione | Linguaggio già conosciuto dal team | La continuità operativa conta più della preferenza personale |
La soluzione che trovo più equilibrata è spesso ibrida. Uso Ladder per consensi, blocchi di sicurezza logica e comandi semplici; Structured Text per calcoli, diagnostica avanzata e gestione dati; SFC per rappresentare una sequenza articolata. La regola importante è documentare questa scelta, così chi subentra non deve ricostruire l’architettura osservando il codice a posteriori.
Gli errori che rallentano il collaudo e la manutenzione
Il primo errore è confondere il corretto funzionamento in condizioni normali con un progetto completo. Una macchina automatica deve sapere cosa fare quando un cilindro non raggiunge il finecorsa entro il tempo previsto, quando un encoder perde impulsi o quando l’operatore interrompe il ciclo.
Affidarsi troppo al tempo di scansione
Un ingresso breve può non essere rilevato se il segnale cambia più velocemente del ciclo del PLC o se il filtro hardware è impostato male. Per impulsi rapidi servono spesso ingressi ad alta velocità, interrupt, contatori dedicati o moduli tecnologici, non semplicemente un contatto aggiunto nel programma.
Usare timer e bit senza una strategia
Timer duplicati, bit di memoria riutilizzati e reset sparsi rendono il comportamento imprevedibile. Ogni temporizzazione dovrebbe avere uno scopo dichiarato, una condizione di avvio e una gestione chiara del superamento del tempo. Se un attuatore non risponde, l’allarme deve indicare almeno quale fase e quale condizione sono mancate.
Leggi anche: Corsi Automazione Industriale PLC: Guida Completa alla Scelta
Trattare la sicurezza come una normale uscita
Arresto di emergenza, ripari, barriere fotoelettriche e funzioni come STO richiedono una progettazione specifica. Un bit chiamato “Sicurezza_OK” nel PLC standard non sostituisce un circuito o un controllore di sicurezza certificato, né la valutazione dei rischi e la validazione della funzione.
Un altro problema frequente è il riavvio automatico dopo un’anomalia. In molte applicazioni la macchina deve tornare in uno stato sicuro e richiedere un nuovo consenso dell’operatore, invece di riprendere il movimento appena ricompare il segnale mancante.
Come verificare che il programma sia pronto per la macchina
Prima della consegna controllo il programma su tre livelli. Il primo riguarda la logica: ogni transizione deve avere una causa leggibile e ogni uscita deve essere attivata da una condizione tracciabile. Il secondo riguarda il comportamento: gli allarmi devono comparire nel momento giusto e condurre a una reazione sicura.
Il terzo livello è la manutenzione. Un tecnico deve poter capire in pochi minuti perché la macchina è ferma, quali sensori risultano attivi e quale fase sta aspettando. Per questo aggiungo diagnostica sull’HMI, commenti essenziali e una tabella degli I/O coerente con lo schema elettrico.
- verificare il ciclo normale dall’avvio alla fine;
- provare ogni sensore scollegato o non raggiunto;
- controllare i tempi massimi delle movimentazioni;
- testare arresto, reset e ripartenza manuale;
- misurare il tempo di scansione sotto carico;
- salvare versione del software e parametri di macchina;
- documentare modifiche e condizioni di collaudo.
La misurazione del tempo di ciclo del PLC va fatta nelle condizioni più pesanti, includendo comunicazioni, ricette e funzioni attive. Un valore di 5 millisecondi in laboratorio non garantisce lo stesso risultato quando la macchina gestisce più assi, pannelli operatore e scambi dati con altri dispositivi.
La qualità del codice si vede quando la macchina esce dal caso ideale
Per me un buon progetto non è quello con meno righe, ma quello che rende prevedibili anche i problemi. La combinazione corretta di sequenze esplicite, linguaggi scelti con criterio, diagnostica e test degli stati anomali riduce i tempi di fermo molto più di una semplice ottimizzazione estetica del codice.
Chi lavora su macchine utensili, linee di assemblaggio o impianti per lavorazioni di precisione dovrebbe quindi partire dal processo reale e non dal linguaggio preferito. Il PLC deve parlare la lingua della macchina, dei suoi operatori e dei tecnici che la manterranno per anni.
Quando questa impostazione manca, anche una piccola modifica può richiedere ore di ricerca. Quando invece ogni fase, consenso e allarme ha un posto preciso, il software diventa un componente industriale solido, verificabile e davvero utile alla continuità produttiva.
