"Perché comprare un PLC da 800 euro quando un Arduino da 25 fa la stessa cosa?" È una domanda legittima, e la risposta non è né "hai ragione" né "non scherziamo". Dipende da cosa deve fare quel dispositivo e da cosa succede il giorno in cui smette di farlo.
Cosa è nato per fare un PLC
Un controllore industriale è progettato attorno a un'ipotesi precisa: starà in un quadro, in un capannone, per quindici anni, con polvere, sbalzi di temperatura, vibrazioni e disturbi elettrici, e non dovrà mai fermarsi. Da questa ipotesi discende tutto il resto:
- Ingressi e uscite già a 24 volt, protetti e isolati, che sopportano cablaggi lunghi e ambienti rumorosi.
- Montaggio su barra DIN, morsettiere serie, temperature di funzionamento ampie.
- Programmazione con linguaggi standardizzati, che un altro tecnico è in grado di leggere anche fra dieci anni.
- Ricambi disponibili a lungo e assistenza del produttore.
- Versioni certificate per le funzioni di sicurezza, dove la normativa lo impone.
Il prezzo non paga il calcolo: paga la continuità e la responsabilità.
Cosa è nato per fare un microcontrollore
Un Arduino o un ESP32 è nato per prototipare in fretta e costare poco. È flessibile, si programma in un pomeriggio, si collega a qualsiasi sensore esista e comunica in rete senza moduli aggiuntivi. In cambio: ingressi a 3,3 o 5 volt facilmente disturbabili, nessuna protezione seria, contenitore da procurarsi, e nessuno che vi risponda se si guasta.
La domanda che decide, in una riga
Cosa succede se questo dispositivo si blocca alle tre di notte e nessuno se ne accorge fino al mattino?
- Se la risposta è "manca un dato nel grafico", il microcontrollore va benissimo.
- Se la risposta è "si ferma la linea", "si rovina il lotto", "si allaga il locale" o "qualcuno si fa male", serve un PLC, con le protezioni e le certificazioni del caso.
Non è una questione di bravura di chi programma. È una questione di chi risponde del guasto.
La zona grigia dove si lavora meglio
Esiste una fascia intermedia molto interessante, ed è quella in cui in genere ha senso muoversi nelle piccole aziende: leggere senza comandare.
Un microcontrollore che ascolta un contatto pulito della macchina, conta i cicli e li pubblica in rete non interferisce con il funzionamento della macchina, non è nel percorso critico e, se si blocca, produce solo un buco nei dati. È il modo corretto di portare informazione fuori da impianti che non sono nati per comunicare, senza rischi e senza toccare la logica esistente.
Il salto di categoria avviene quando quel dispositivo comincia a comandare qualcosa. Lì il discorso cambia.
Le soluzioni intermedie che spesso sono la risposta
Fra i due estremi esistono prodotti che valgono la pena di essere considerati: microcontrollori in versione industriale, montati su barra DIN, con ingressi a 24 volt già protetti e alimentazione industriale. Costano più di una scheda nuda e molto meno di un PLC completo, e vi danno il compromesso giusto per il monitoraggio permanente in ambienti veri.
Allo stesso modo, sul fronte opposto, esistono PLC compatti di fascia bassa che oggi costano poche centinaia di euro e includono già connettività e pagine web: per un'automazione semplice ma seria, spesso il confronto economico non è così sbilanciato come sembra.
Il costo che nessuno conta
Il paragone fra 25 euro e 800 euro è ingannevole perché ignora la voce più pesante: il tempo. Un progetto su microcontrollore richiede ore per essere costruito, chiuso, provato e documentato, e altre ore ogni volta che va modificato. Se l'azienda non ha nessuno in grado di metterci mano, quel dispositivo è un punto di fragilità: funziona finché funziona, poi diventa una scatola nera che nessuno sa toccare.
Da qui una regola semplice: tutto ciò che resta installato deve essere documentato, con schema dei collegamenti e copia del programma conservata in azienda. Vale sia per l'Arduino sia per il PLC.
Conclusione
Il microcontrollore non è un PLC povero e il PLC non è un microcontrollore caro: risolvono problemi diversi. Leggere dati e produrre avvisi è terreno ideale per il primo; comandare processi, gestire sicurezze e garantire continuità è terreno del secondo. Se dovete portare in rete i dati delle vostre macchine o automatizzare qualcosa in reparto, possiamo aiutarvi a capire da che parte cade il vostro caso prima di investire nella direzione sbagliata.