Cambio formato: il sensore IO-Link che riparte senza rifare il setup

img 20260526 220626 2ad2e28a

Ore 2:17, turno di notte, linea packaging ferma. Il display del drive è acceso, l’allarme punta al feedback di posizione su un asse secondario, il ricambio c’è. Sulla carta sembra un fermo corto: si cambia il sensore, si richiude il carter, si riparte. In reparto, però, il cronometro parte davvero dopo che il componente guasto è già in mano al manutentore.

Il guasto è la parte facile. La differenza la fa la sostituzione: dispositivo “muto” da rimontare e riconfigurare a mano, oppure device parametrizzabile su rete che rientra in macchina con i dati già pronti.

Il minuto perso non sta nel magazzino, sta nella procedura

Versione vecchio stile. Minuto 0: si individua il componente. Minuto 4: si apre la protezione, si libera il connettore, si verifica il codice. Minuto 9: il ricambio è corretto come meccanica, meno chiaro come settaggio. C’è da capire risoluzione, direzione di conteggio, zero macchina, eventuale finestra di camma, scala usata dal controllo. Minuto 16: il sensore nuovo è montato, ma la linea resta ferma. Parte la caccia al foglio giusto, alla nota lasciata in quadro, al laptop con il software, alla password che il collega del turno precedente “dovrebbe avere”. Minuto 24: il PLC vede di nuovo un segnale, però i valori non tornano con la posizione reale. Minuto 31: si corregge un parametro. Minuto 38: se va bene si riparte piano, con l’operatore che controlla il primo ciclo come si controlla un bicchiere crepato.

Versione con device parametrizzabile su rete. Minuto 0: stessa diagnosi, stesso cacciavite, stesso ricambio. Minuto 8: il componente nuovo è in sede. Minuto 10: il controllore o il master riconosce il device. Se il progetto è stato fatto con criterio, i parametri sono già memorizzati a monte e vengono riscritti sul nuovo componente in automatico. Phoenix Contact lo descrive in modo netto per IO-Link: i dati di parametrizzazione possono essere archiviati nel controllore e trasferiti al device sostitutivo senza programmatore esterno. Minuto 13: il manutentore verifica il valore a macchina ferma. Minuto 16: la linea torna a produrre. Il pezzo cambiato è lo stesso gesto meccanico; il tempo perso, no.

Qui si inciampa spesso. Si guarda il costo del sensore e si trascura il costo della sua reinstallazione reale. Eppure il fermo macchina non è un esercizio teorico: succede tra carter stretti, fine turno, attrezzi mancanti e ricambi montati sotto pressione.

“Digitale” non basta: conta dove stanno i parametri

Un encoder può dare un segnale digitale ed essere comunque muto quando serve davvero, cioè nel momento del cambio. Se l’intelligenza resta affidata a file sparsi, taccuini di bordo o memoria individuale del tecnico, il protocollo ha fatto metà del lavoro. L’altra metà – quella che fa ripartire la macchina – resta affidata all’improvvisazione. Con IO-Link, quando il caso d’uso è stato pensato a monte, la sostituzione automatica cambia il quadro: il ricambio non arriva nudo, arriva con un contesto operativo già definito dal controllo.

DigiKey lo fa notare parlando di IO-Link 1.1: la lettura corretta non è “versione nuova uguale upgrade”, ma valutazione dei casi d’uso nelle installazioni automatizzate. Tradotto in officina: non basta scrivere in distinta “encoder digitale”. Bisogna chiedersi se il protocollo scelto serve la manutenzione, oltre al funzionamento ordinario. Lo stesso ragionamento vale sui dispositivi collegati via Industrial Ethernet, dove funzioni di sostituzione, identificazione e recupero configurazione possono esserci, ma non arrivano per diritto divino del nome stampato sul catalogo. Dipendono dal progetto, dal controllore, dai file di descrizione, dalla disciplina con cui l’OEM governa le versioni. Agenda Digitale, parlando di adozione tecnologica, ricorda una cosa che nel manifatturiero si vede bene: molte misure raccontano la presenza di una tecnologia, non la qualità dell’integrazione. Vale uguale qui. Avere un dispositivo di rete non dice ancora nulla sui minuti che si perderanno al primo guasto.

Per l’OEM il conto arriva dopo la spedizione

Quando la macchina resta in Italia, il danno è già chiaro. Quando viaggia all’estero, il problema peggiora. Mettiamo il caso di una linea per alimentare o packaging installata a otto ore di fuso, con un manutentore locale preparato sulla parte meccanica ma non sul software proprietario del costruttore. Se il ricambio richiede un programmatore esterno, un file parametri recuperato da remoto e una sequenza di impostazioni non banale, il fermo si allunga per motivi organizzativi prima ancora che tecnici. E il cliente finale non fa sconti: lui vede una macchina ferma per un componente che “era disponibile”.

Non è più materia da pionieri. Automazione Plus segnala che GFCC è il primo IO-Link Competence Center italiano ed è il quarto in Europa, dopo due centri in Germania e uno nella Repubblica Ceca. Il dato conta perché sposta la discussione: non si parla di una tecnologia da laboratorio, ma di un ecosistema con riferimenti tecnici già strutturati. Il catalogo di https://www.elap.it/it/ — costruttore italiano attivo a Corsico dal 1968 — con encoder incrementali e assoluti su IO-Link, Profinet, EtherCAT, EtherNet/IP e CANopen rende visibile il punto: la manutenzione rapida nasce già a disegno, non davanti alla linea ferma.

Le domande giuste vanno fatte prima del collaudo

Chi progetta una macchina tende a giudicare il componente dal comportamento in esercizio. Ha senso, fino a un certo punto. Poi arriva il primo cambio e il banco di prova diventa il reparto manutenzione. Lì il protocollo smette di essere una sigla commerciale e diventa una procedura concreta. Serve il pc oppure basta il ricambio? Serve il tecnico senior oppure basta una procedura chiara su HMI? Serve ricordarsi un parametro scritto mesi prima oppure il controllo lo rimette da solo? La risposta a queste domande pesa più di parecchi euro risparmiati in acquisto.

  • Il ricambio riparte con il solo montaggio oppure chiede software, password, file e competenze rare?
  • I parametri stanno nel dispositivo, in un foglio separato o nel controllore con gestione ordinata della versione?
  • Il protocollo scelto copre davvero il caso d’uso di device replacement, oppure si è comprata una sigla più moderna senza sfruttarla?
  • Identificazione del componente, connettori e accessi fisici permettono un cambio rapido, o costringono a smontare mezza macchina per leggere un codice?
  • In caso di export, un manutentore locale può eseguire la sostituzione senza attendere teleassistenza o trasferta?

Quando queste risposte mancano, il fermo non comincia dal guasto. Comincia mesi prima, in ufficio tecnico, nel giorno in cui si decide che un sensore vale l’altro purché dia un dato. In produzione, quel conto torna sempre. E arriva in minuti persi, riavvii prudenti, telefonate fuori orario e clienti che del protocollo non vogliono sapere nulla.