Perché i dati di manutenzione sono essenziali per l’affidabilità industriale

La fuga intermittente della slitta è un evento di sicurezza della macchina

Un asse che si muove senza il comando previsto non è un normale guasto di messa in servizio. È un evento di movimento incontrollato che può danneggiare utensili, strutture della macchina, pezzi, attrezzaggi e persone. Il rischio diventa più difficile da gestire quando la slitta si comporta normalmente per molte ore prima di muoversi improvvisamente a una velocità o in una direzione impreviste.

La macchina considerata in questo caso utilizza una Siemens SIMATIC S7-200 CPU 226, un’unità SIMOVERT MASTERDRIVES per gli assi delle slitte, un MICROMASTER 440 per il mandrino e un pannello operatore TP 170A. I dati di comando e di stato vengono trasferiti tramite una rete di comunicazione seriale USS.

Il problema segnalato si verifica su una o entrambe le slitte. Un incidente può verificarsi una o due volte durante una giornata lavorativa, seguito da due o tre giorni di funzionamento normale. I tentativi precedenti hanno incluso la separazione del VFD del mandrino dall’armadio di controllo principale e il miglioramento della messa a terra. Tali interventi non hanno eliminato il guasto.

Questo schema spesso incoraggia una ricerca dei guasti speculativa. Gli ingegneri possono sostituire un encoder, instradare nuovamente un cavo, modificare un parametro dell’azionamento o aggiungere un altro conduttore di messa a terra. Una modifica può alterare temporaneamente il sintomo, creando l’impressione che il problema sia stato risolto. L’evento si ripresenta quindi perché il percorso effettivo del comando non è mai stato verificato.

Un’indagine affidabile deve identificare il primo punto in cui il comportamento previsto diventa anomalo. Il team deve sapere che cosa ha richiesto l’HMI, che cosa ha accettato il PLC, che cosa ha trasmesso il PLC, che cosa ha ricevuto l’azionamento, che cosa ha attivato internamente l’azionamento e che cosa ha effettivamente fatto il motore.

Inizia confermando ogni dispositivo installato

I sistemi Siemens legacy spesso rimangono in funzione a lungo dopo che il team di messa in servizio originario ha lasciato l’impianto. I disegni possono contenere modifiche scritte a mano. I backup dei parametri possono essere incompleti. Moduli sostitutivi possono essere stati installati senza aggiornare la documentazione. Pertanto, l’identificazione dell’hardware deve precedere l’interpretazione dei parametri.

Registra il numero d’ordine completo riportato su ogni targhetta identificativa. Non fare affidamento esclusivamente su un elenco delle apparecchiature trascritto a mano. Il numero della CPU S7-200 riportato contiene caratteri che potrebbero essere stati copiati in modo errato. Il controller effettivo potrebbe corrispondere al Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, ma l’alimentatore e la variante delle uscite devono essere confermati direttamente sull’unità installata.

Un solo carattere errato può portare al manuale, allo schema dei morsetti o al ricambio sbagliato. La lettera O viene spesso confusa con lo zero. Il numero uno può essere confuso con la lettera I. Anche un suffisso mancante può nascondere un’importante opzione hardware.

La stessa disciplina si applica all’unità SIMOVERT MASTERDRIVES. MASTERDRIVES è un’ampia famiglia, non un unico design di azionamento fisso. Le schede di controllo, le versioni software, le opzioni encoder, le schede tecnologiche e le configurazioni Vector Control o Motion Control possono modificare i parametri disponibili e il percorso interno dei segnali.

È opportuno verificare anche il numero d’ordine del MICROMASTER 440. Sebbene l’MM440 controlli il mandrino anziché le slitte, condivide l’ambiente dell’armadio e potrebbe condividere il percorso di comunicazione USS. I suoi eventi di commutazione, il percorso dei cavi, la configurazione degli indirizzi e la temporizzazione della comunicazione possono influire sul sistema complessivo.

Registrare il modello del TP 170A, la versione del progetto HMI, le impostazioni di comunicazione e gli indirizzi PLC collegati. Il pannello può contenere eventi dei pulsanti, funzioni delle ricette, valori di avviamento o comportamenti dei tag che non possono essere identificati dal solo programma PLC.

Prima di modificare qualsiasi parametro, creare backup completi del programma PLC, del progetto HMI, del set di parametri MASTERDRIVES e del set di parametri MM440. Fotografare le schermature dei cavi, i selettori delle schede, i collegamenti ai morsetti e i moduli opzionali. Questa configurazione di riferimento consente di confrontare e annullare ogni modifica successiva.

Definire cosa intendono gli operatori per «fuorigiri»

La parola «fuorigiri» può descrivere diversi eventi. Un’accelerazione alla massima velocità è diversa da un breve jog involontario. Un movimento durante l’avviamento è diverso da un movimento durante una sequenza automatica. Il percorso diagnostico cambia in base all’evento preciso.

Intervistare tutte le persone che hanno assistito al guasto. Chiedere osservazioni, non conclusioni. «L’encoder è guasto» è una conclusione. «La slitta si è spostata rapidamente in direzione positiva mentre l’HMI indicava velocità zero» è un’osservazione.

Registrare l’asse coinvolto, la direzione, la velocità stimata, la durata, la posizione iniziale, la modalità della macchina, lo stato del mandrino, il passo attivo del programma e il metodo con cui è stato arrestato il movimento. Determinare se il movimento è iniziato da fermo o si è sviluppato durante un movimento già in corso.

Se la slitta accelera fino alla velocità massima, verificare la polarità del feedback, le sorgenti attive del setpoint, la sequenza di abilitazione e la regolazione dell’azionamento. Se percorre solo una breve distanza, verificare i bit di jog, i trigger di fronte duplicati, i comandi obsoleti e le transizioni di stato della sequenza.

Se l'evento si verifica solo in modalità automatica, la logica della sequenza diventa più rilevante. Se si verifica anche in modalità manuale, concentrarsi sull'arbitraggio dei comandi condiviso da entrambe le modalità. Se l'asse si muove durante l'accensione, la transizione della CPU, il reset dell'azionamento o la riconnessione dell'HMI, l'inizializzazione all'avvio merita un'attenzione immediata.

Il comportamento durante l'arresto fornisce elementi preziosi. Se la rimozione del segnale di abilitazione dell'azionamento dal PLC arresta l'asse, lo stadio di potenza potrebbe ancora rispondere al percorso di abilitazione previsto. Se il movimento continua finché non viene isolata l'alimentazione principale, esaminare l'hardware dell'azionamento, il cablaggio dell'abilitazione esterna, il comportamento dei contattori e le sorgenti di comando esterne al PLC.

Determinare inoltre se l'azionamento ha generato un avviso o un guasto. Un evento senza guasti non dimostra che l'azionamento fosse integro, ma suggerisce che potrebbe aver considerato validi il comando e la retroazione.

Considerare la macchina come una catena di comando completa

Il comando di movimento può iniziare dal pannello operatore TP 170A. Un pulsante, un ingresso numerico, una ricetta, un evento di schermata o una sequenza automatica imposta un valore nella memoria del PLC. L'S7-200 convalida tale richiesta e calcola una velocità o un riferimento di movimento. Una routine di comunicazione USS costruisce quindi un telegramma contenente dati di comando e di processo.

L'unità MASTERDRIVES riceve il telegramma e trasferisce la parola di comando e il riferimento attraverso la propria struttura interna dei segnali. Il comando finale attivo può includere anche velocità fisse, ingressi analogici, comandi da morsettiera, riferimenti aggiuntivi, ingressi di jog o blocchi funzione interni.

Il percorso di ritorno è altrettanto importante. Il motore o il carico può utilizzare un encoder incrementale, un resolver, un tachimetro o un altro dispositivo di retroazione. L'azionamento interpreta quel segnale come velocità o posizione. Alcuni valori effettivi possono poi essere trasmessi al PLC.

I finecorsa meccanici, i sensori di zero, gli interruttori di oltre-corsa, i contattori, i freni e i contatti di azionamento pronto creano percorsi aggiuntivi. Ogni percorso può influire sull'avvio, sulla prosecuzione o sull'arresto del movimento.

Ogni fase dovrebbe avere un valore misurabile. Nel PLC, registrare la richiesta HMI grezza, la modalità operativa selezionata, lo stato della sequenza, il riferimento finale validato, la direzione, il comando di abilitazione e l'esito della comunicazione. Nell'azionamento, osservare la parola di comando ricevuta, il riferimento ricevuto, il riferimento interno attivo, la velocità effettiva, lo stato della retroazione, la corrente, gli avvisi e i guasti.

Uno zero visualizzato sull'HMI non dimostra che il PLC abbia trasmesso zero. Uno zero in un registro PLC non dimostra che un'altra sorgente di comando fosse inattiva. Un telegramma USS corretto non dimostra che l'azionamento fosse configurato per utilizzare quel telegramma come unica sorgente del riferimento.

L'indagine dovrebbe individuare il primo punto in cui il valore previsto e quello registrato non corrispondono. Quel punto divide il problema in logica HMI, applicazione PLC, comunicazione, configurazione dell'azionamento, retroazione, hardware di potenza o meccanica.

La distinzione diagnostica più importante

La prima domanda tecnica è semplice: l’azionamento ha ricevuto un comando legittimo di movimento?

Confrontare quattro valori durante l’evento:

• Il setpoint finale di movimento del PLC.
• Il setpoint ricevuto dall’azionamento.
• Il setpoint interno attivo dell’azionamento.
• Il movimento effettivo misurato del motore o della slitta.

Se il setpoint finale del PLC diventa diverso da zero e l’azionamento lo segue, l’azionamento potrebbe funzionare correttamente. Il movimento indesiderato è stato generato a monte. Esaminare gli eventi dell’HMI, la logica di sequenza, i valori conservati, le transizioni di modalità e le scritture multiple del comando finale.

Se il setpoint finale del PLC rimane a zero ma l’azionamento riceve un valore diverso da zero, esaminare la costruzione del telegramma, la mappatura della memoria, la scalatura, la gestione del buffer e l’esecuzione del blocco di comunicazione. Il valore imprevisto esatto può identificare il meccanismo. Un valore fisso ripetuto indica spesso dati conservati o obsoleti. Un valore positivo o negativo estremo può indicare un problema di numeri con segno o di ordine dei byte.

Se l’azionamento riceve zero ma il suo setpoint interno attivo diventa diverso da zero, esaminare la configurazione dell’azionamento. Potrebbero essere attivi una velocità fissa, un riferimento analogico, una funzione di jog, un ingresso a morsetto, un setpoint supplementare, un potenziometro motorizzato o un’opzione tecnologica.

Se il setpoint del PLC, il setpoint ricevuto e il setpoint interno rimangono tutti a zero mentre il motore accelera, l’evento è più grave. Esaminare il comportamento della retroazione, la regolazione dell’azionamento, l’alimentazione della scheda di controllo, l’hardware dell’azionamento, il comportamento dello stadio di uscita e l’accoppiamento meccanico.

Questo metodo a quattro segnali evita la sostituzione incontrollata dei componenti. Consente inoltre di formulare una conclusione tecnica difendibile. Il guasto viene attribuito in base alle prove registrate, non alle supposizioni.

La retroazione è un sospetto prioritario, ma non una conclusione automatica

Un guasto intermittente dell’encoder o del tachimetro è plausibile, soprattutto quando l’evento varia in base a vibrazioni, temperatura, movimento del cavo o posizione della slitta. Tuttavia, l’ipotesi che qualsiasi perdita della retroazione causi automaticamente la velocità massima è troppo generica.

Un azionamento configurato correttamente dovrebbe normalmente rilevare una retroazione assente o implausibile e reagire in base alle impostazioni di monitoraggio e di guasto. La risposta esatta dipende dalla versione del controllo, dall’opzione di retroazione, dalla configurazione e dall’applicazione.

Un comportamento pericoloso può comunque verificarsi quando il segnale di retroazione è presente ma errato. Polarità invertita, sequenza di fase errata, ampiezza instabile del segnale, canali danneggiati, tipo di encoder errato, scalatura non corretta, giunti allentati o una configurazione del regolatore non idonea possono far reagire l’azionamento nella direzione sbagliata.

Un cavo intermittente raramente si guasta come un circuito perfettamente aperto. Un conduttore può separarsi solo quando il cavo si piega. Un pin del connettore può perdere il contatto solo in presenza di forti vibrazioni. L’alimentazione dell’encoder può calare quando si attiva un contattore. La corrente nella schermatura può distorcere un canale differenziale senza eliminare completamente il segnale.

Confrontare la velocità effettiva indicata dall’azionamento con una misurazione indipendente. Un tachimetro portatile, un sensore temporaneo verificato o una misurazione adeguata con oscilloscopio possono stabilire se il valore effettivo interno corrisponde al movimento fisico.

Se l’azionamento segnala velocità zero mentre l’albero gira, il percorso di retroazione è sospetto. Se l’azionamento segnala la velocità corretta mentre il comando diventa errato, la retroazione potrebbe funzionare normalmente.

Non eseguire mai un test della retroazione esponendo il personale a una slitta in movimento. Utilizzare barriere, velocità ridotta, condizioni di test controllate e un metodo indipendente di arresto.

Ispezionare l’intero circuito di retroazione

Un sistema di retroazione comprende più dell’encoder. Il sensore, il collegamento meccanico, il cavo, il connettore, l’alimentazione, la schermatura, la configurazione della messa a terra, la scheda di ingresso e la configurazione dell’azionamento contribuiscono tutti al valore misurato.

Iniziare dal collegamento meccanico. Verificare che l’albero dell’encoder, la cinghia, l’ingranaggio o il giunto flessibile non possano slittare. Ispezionare i mozzi del giunto, le chiavette, i grani, le crepe, la contaminazione e il disallineamento. Un encoder scollegato meccanicamente può continuare a produrre un segnale che non rappresenta più il movimento effettivo del carico.

Ispezionare ogni connettore in condizioni di buona illuminazione e con un ingrandimento adeguato. Cercare contatti rientrati, crimpature deboli, pin piegati, corrosione, contaminazione da olio, fermacavi danneggiati e tensione sul cavo. Verificare che i connettori sostitutivi utilizzino il tipo di contatto corretto.

Verificare la continuità con la macchina isolata, ma non affidarsi soltanto a un test statico della resistenza. Un conduttore spezzato può risultare integro quando è dritto e interrompersi quando viene piegato. Nell’ambito di un test a basso rischio approvato, monitorare il segnale di retroazione mentre il portacavi percorre la sua corsa normale.

Misurare l’alimentazione dell’encoder direttamente sull’encoder durante il funzionamento sotto carico. Una tensione stabile all’interno dell’armadio non dimostra che rimanga stabile anche sul sensore. Registrare il valore minimo durante l’accelerazione del mandrino, l’inversione dell’asse, la frenatura e l’attivazione dei contattori.

Per un encoder incrementale, controllare l’ampiezza dei canali, la simmetria dei canali, la relazione di fase e l’impulso di indice, se utilizzato. Le coppie differenziali devono rimanere bilanciate. Picchi di disturbo, impulsi mancanti o ampiezza in calo possono indicare problemi del cavo, della schermatura, dell’alimentazione o del sensore.

Verificare il tipo di encoder, il conteggio degli impulsi, la polarità, la scala e la sorgente di retroazione nel set di parametri dell’azionamento installato. Non presumere che il numero di un parametro riportato in un altro manuale MASTERDRIVES sia applicabile a questa scheda di controllo.

Gli errori USS non devono essere ridotti a variazioni casuali dei bit

La comunicazione USS opera tramite un telegramma strutturato. Il protocollo include il controllo degli errori, quindi un telegramma danneggiato dovrebbe normalmente essere rifiutato anziché essere accettato come un setpoint di velocità valido ma non correlato.

Ciò non significa che USS possa essere ignorato. I problemi di comunicazione possono comunque contribuire a una fuga incontrollata attraverso il comportamento dell'applicazione. Il PLC può creare la parola dei dati di processo errata. Un valore con segno può essere interpretato in modo errato. I byte alto e basso possono essere scambiati. I dati precedenti possono rimanere in un buffer di trasmissione. Una risposta mancante può lasciare attivo il setpoint precedente.

Anche gli indirizzi duplicati degli slave possono creare comportamenti confusi. Ogni azionamento sulla rete deve utilizzare un indirizzo univoco. La sequenza di interrogazione del PLC deve associare ogni risposta allo slave corretto e all'area di memoria corretta.

La parola di comando merita la stessa attenzione del setpoint di velocità. Un azionamento può rimanere abilitato mentre il programma PLC presume che sia stato arrestato. Il riconoscimento dei guasti, i comandi ON/OFF, i bit di direzione e la logica di riavvio possono essere elaborati in modo errato durante il ripristino della comunicazione.

Contare le transazioni riuscite, i timeout, i frame rifiutati, i guasti consecutivi e gli eventi di ripristino. Un singolo bit di “guasto di comunicazione” fornisce informazioni insufficienti. I dati diagnostici devono identificare quale slave veniva interrogato e quale transazione è fallita.

Sul MICROMASTER 440, P2010 riguarda la configurazione della velocità di trasmissione USS. Non deve essere considerato una regolazione generica del timeout del telegramma. P2011 è comunemente associato all'indirizzo USS. Il significato di tutti i parametri deve comunque essere verificato nel manuale MM440 corretto e nella configurazione dell'interfaccia.

Un timeout più lungo non è automaticamente più sicuro. Se l'azionamento continua a utilizzare un setpoint precedente diverso da zero mentre attende il timeout, aumentare tale ritardo può prolungare un movimento indesiderato. Occorre prima definire la risposta richiesta alla perdita di comunicazione.

Lo strato fisico RS-485 conta ancora

Anche quando i frame corrotti vengono rifiutati, una rete RS-485 instabile può causare nuovi tentativi ripetuti, dati obsoleti, aggiornamenti di stato persi e temporizzazioni irregolari dell'applicazione. La rete fisica richiede quindi un audit completo.

Documentare il bus dalla porta di comunicazione S7-200 a ciascun azionamento. Confermare che il cablaggio utilizzi una topologia lineare corretta. Le diramazioni a stella lunghe possono creare riflessioni e dovrebbero essere evitate, salvo che la documentazione dell'interfaccia installata le consenta esplicitamente.

Verificare che tutti i dispositivi utilizzino impostazioni di comunicazione corrispondenti. Queste includono velocità di trasmissione, parità, struttura del telegramma, lunghezza dei dati di processo e indirizzo dello slave. Annotare le impostazioni invece di modificarle a memoria.

La terminazione deve rispettare i requisiti delle interfacce e dei connettori Siemens effettivamente utilizzati. Non aggiungere automaticamente una resistenza generica da 120 ohm. Una terminazione o una polarizzazione errata possono peggiorare il segnale.

Controllare il tipo di cavo di comunicazione, la continuità della schermatura, il collegamento equipotenziale dei connettori e il percorso dei cavi. Il cavo RS-485 non deve correre per lunghi tratti accanto ai cavi di uscita del motore, ai conduttori delle resistenze di frenatura, ai cavi dei contattori o ad altri circuiti di potenza ad alta frequenza.

Quando la separazione è limitata, incrociare i cavi di potenza e di segnale con un angolo di circa 90°. Mantenere un collegamento equipotenziale intenzionale tra gli armadi e le sezioni della macchina. Evitare lunghe trecce di schermatura, che riducono l'efficacia alle alte frequenze.

Quando necessario, utilizzare una sonda differenziale per oscilloscopio adeguata per esaminare la forma d'onda. Cercare riflessioni, tensione di modo comune eccessiva, ringing, fronti lenti, raffiche di rumore e variazioni di ampiezza durante l'accelerazione del mandrino o la frenata dell'asse.

Un laptop collegato o un convertitore USB possono alterare la messa a terra e il carico del bus. Registrare se il guasto cambia quando l'apparecchiatura diagnostica è collegata.

I componenti utilizzati nella comunicazione e nel networking industriali devono essere valutati insieme alla topologia, alla schermatura, alla terminazione, all'indirizzamento e alla gestione delle transazioni del PLC. La sostituzione di un connettore non correggerà una macchina a stati della comunicazione instabile.

Esaminare il programma S7-200 come una macchina a stati

I guasti intermittenti durante la messa in servizio si manifestano spesso durante le transizioni, anziché durante il funzionamento stazionario. La macchina può comportarsi correttamente mentre funziona in modo continuo, ma guastarsi quando passa dalla modalità manuale a quella automatica, completa la ricerca dello zero, recupera da un allarme, cambia una ricetta o ripristina la comunicazione.

Cercare nel riferimento incrociato del programma ogni istruzione che scrive nelle variabili finali di velocità, direzione e abilitazione. I programmi meno recenti spesso scrivono la stessa parola di memoria V in diverse reti. L'ultima scrittura eseguita controlla il risultato, producendo un comportamento che può sembrare casuale.

Creare un'unica fase chiara di arbitraggio dei comandi. Il jog manuale, il movimento automatico, la ricerca dello zero, le funzioni di configurazione e i comandi di manutenzione devono entrare in questa fase come richieste separate. Il setpoint finale deve essere generato solo dopo aver convalidato la modalità, i limiti, il feedback, la comunicazione e le condizioni di consenso alla sicurezza.

Esaminare la logica one-shot e di rilevamento dei fronti. Un comando destinato a durare un solo ciclo di scansione può rimanere attivo perché la memoria del fronte è stata riutilizzata, mantenuta o sovrascritta. Un comando può inoltre riattivarsi quando cambia un bit di modalità.

Esaminare ogni latch. Identificare la condizione che lo imposta e ogni condizione che lo resetta. Un latch di movimento che dipende solo da un passaggio successivo della sequenza può rimanere attivo quando la sequenza viene interrotta da un guasto.

Verificare la gestione dei dati con segno. Un intero negativo interpretato come parola senza segno può diventare un valore positivo elevato. La moltiplicazione può causare un overflow. Una parola copiata con l’ordine dei byte errato può creare un setpoint estremo.

Verificare la conversione dalle unità ingegneristiche al valore di processo USS. Applicare i limiti positivi e negativi dopo il calcolo finale, non solo all’ingresso dell’HMI.

I sistemi di controllo Siemens SIMATIC S7 legacy possono funzionare in modo affidabile per decenni, ma le loro applicazioni spesso contengono modifiche apportate durante diverse fasi di messa in servizio. Una revisione strutturata dei riferimenti incrociati è più utile che presumere che l’hardware della CPU sia diventato instabile.

Gli stati di avviamento e ripristino richiedono test separati

Dati non inizializzati o mantenuti possono causare movimenti sporadici dopo interruzioni dell’alimentazione, download del software, passaggi della CPU da STOP a RUN, reset dell’azionamento o riconnessioni dell’HMI.

Identificare ogni area di memoria ritentiva utilizzata dal programma di movimento. Determinare il valore iniziale del comando di velocità, della direzione, dell’abilitazione, della modalità, del passo della sequenza, dei bit jog e dello stato della comunicazione dopo ogni tipo di riavvio.

La routine di avviamento dovrebbe forzare a zero tutte le richieste di movimento. Dovrebbe cancellare i comandi jog e automatici in sospeso, validare il feedback, confermare lo stato dei finecorsa, stabilire la comunicazione e richiedere una nuova sequenza di abilitazione deliberata.

Un setpoint non nullo mantenuto non deve mai diventare effettivo semplicemente perché l’azionamento diventa pronto prima che il PLC completi l’inizializzazione.

Testare l’avviamento a freddo, il riavvio a caldo, il passaggio della CPU da STOP a RUN, il reset dell’azionamento, la riconnessione dell’HMI e il ripristino di uno slave USS guasto. Eseguire questi test con la macchina controllata meccanicamente e alla velocità disponibile ridotta.

Monitorare l’alimentazione di comando a 24 V durante gli eventi di alimentazione. Il PLC, l’encoder, l’HMI, l’interfaccia di comunicazione, i contattori e l’elettronica di controllo dell’azionamento possono eseguire il reset a soglie di tensione diverse. Un breve calo di tensione può lasciare un dispositivo in funzione mentre un altro si riavvia.

Registrare la sequenza di alimentazione di comando, PLC in RUN, comunicazione attiva, azionamento pronto, rilascio del freno e abilitazione del movimento. L’ordine deve essere esplicito e ripetibile.

L’HMI può produrre comandi che non sono più visibili

Il progetto TP 170A deve essere verificato insieme al programma del PLC. Un comando HMI può essere scritto durante la pressione di un pulsante, il rilascio del pulsante, l’apertura o la chiusura di una schermata, il download di una ricetta, l’aggiornamento di un tag o il ripristino della comunicazione.

Un pulsante a impulso può creare una condizione pericolosa quando l’azione di pressione imposta un bit e l’azione di rilascio lo azzera. Se la comunicazione si interrompe mentre il pulsante è premuto, il comando di azzeramento potrebbe non raggiungere mai il PLC.

L’operatore in seguito vede un pulsante non premuto, ma il bit del PLC rimane attivo. Un’altra transizione di modalità o una condizione di consenso potrebbe quindi permettere alla richiesta jog obsoleta di raggiungere il comando di movimento finale.

Una funzione jog robusta non dovrebbe basarsi solo su una coppia di eventi di pressione e rilascio. Il PLC dovrebbe richiedere un aggiornamento continuo del comando, applicare un breve tempo di scadenza, convalidare la modalità operativa e rimuovere il comando quando la comunicazione diventa non valida.

Controlla ogni evento HMI associato a jog, inserimento della velocità, direzione, reset, selezione della modalità, ricerca dello zero e controllo del ciclo automatico. Cerca tag duplicati che puntano allo stesso indirizzo PLC.

Gli ingressi numerici richiedono controlli dell’intervallo sia sul pannello sia nel PLC. Il PLC deve rifiutare i valori al di fuori dell’intervallo tecnico consentito anche quando il campo HMI sembra configurato correttamente.

I sistemi HMI Siemens SIMATIC legacy possono contenere comportamenti a livello di schermata non visibili nella logica del PLC. La registrazione separata del tag HMI grezzo e del comando PLC convalidato aiuta a identificare la vera origine del comando.

L’MM440 può influire sull’evento senza controllare la slitta

Il MICROMASTER 440 controlla il mandrino, ma può comunque influire sull’ambiente di controllo della slitta. Il suo raddrizzatore d’ingresso, il circuito intermedio in CC, l’uscita verso il motore, il circuito di frenatura e la frequenza di commutazione possono generare interferenze condotte o irradiate.

Il disturbo più intenso può verificarsi durante l’accelerazione, la decelerazione, i picchi di corrente o la frenatura del mandrino, anziché durante il funzionamento a regime. Confronta i timestamp dei movimenti incontrollati con lo stato del mandrino.

Registra l’avvio, l’arresto, la variazione di velocità, la corrente, lo stato del bus CC, la cronologia dei guasti e l’attività di frenatura del mandrino. Determina se ogni evento si verifica durante una transizione simile del mandrino.

Se le unità MM440 e MASTERDRIVES condividono il bus USS, anche il mandrino influisce sulla temporizzazione della comunicazione. Il PLC deve interrogare ogni slave in modo prevedibile ed elaborare ogni risposta nella struttura di memoria corretta.

Verifica che le aree dati USS del mandrino e della slitta non si sovrappongano. Nelle applicazioni compatte S7-200 la memoria V viene talvolta riutilizzata senza una separazione chiara. Un blocco scritto per il mandrino potrebbe sovrascrivere parte del comando della slitta.

Spostare l’MM440 all’esterno dell’armadio non elimina completamente la sua influenza. I cavi motore, i percorsi di messa a terra, il cablaggio della comunicazione e gli alimentatori condivisi possono rimanere collegati.

Utilizza le misurazioni invece di effettuare continui spostamenti. Esamina la separazione dei cavi, il collegamento delle schermature, le reattanze di linea o i filtri specificati per l’azionamento, il collegamento equipotenziale dell’armadio, la terminazione del cavo motore e la relazione temporale tra gli eventi di commutazione e gli errori di comunicazione.

Audit di MASTERDRIVES per funzione del segnale

Un audit dei parametri MASTERDRIVES dovrebbe seguire l’intero percorso del segnale. Non iniziare con un elenco di numeri di parametro copiato da un’altra installazione.

Verificare innanzitutto la versione del sistema di controllo installato, la release software, la scheda di controllo e l’opzione di feedback. Quindi esaminare la modalità di controllo, i dati del motore, il tipo di feedback, la scalatura del feedback e la sorgente del feedback.

Identificare ogni origine che può controllare i comandi ON/OFF del convertitore. Queste possono includere parole di comando USS, ingressi dei morsetti, comandi fissi, collegamenti binector interni o funzioni tecnologiche.

Identificare ogni origine che può contribuire al setpoint finale di velocità o posizione. Controllare il setpoint principale, i setpoint supplementari, le velocità fisse, le funzioni di jog, gli ingressi analogici, le funzioni del potenziometro motorizzato e i blocchi funzione interni.

Rivedere i limiti di velocità positiva e negativa, le rampe di accelerazione, le rampe di decelerazione, i limiti di corrente, i limiti di coppia e le restrizioni di direzione. Impostazioni temporanee conservative possono ridurre il rischio diagnostico, ma non costituiscono una protezione di sicurezza indipendente.

Esaminare il monitoraggio del feedback e la risposta ai guasti. Determinare cosa è configurato per fare il convertitore quando il feedback diventa assente, instabile, invertito o non plausibile.

Leggere lo storico degli avvisi e dei guasti del convertitore prima di cancellarlo. Un avviso che appare non correlato può registrare il momento in cui è cambiata la condizione di controllo.

Utilizzare il metodo di ingegneria installato, come DriveMonitor, PMU, OP1S o un’altra interfaccia approvata, per osservare i connettori interni e i valori effettivi. Selezionare i valori in base alla versione specifica del sistema di controllo.

Questo approccio funzionale si applica ai sistemi Siemens legacy e attuali di azionamento e controllo del movimento. Il software di controllo, le opzioni di feedback e il routing interno possono differire anche quando due convertitori sembrano fisicamente simili.

Creare un registratore di eventi attivato

Un evento che si verifica una volta al giorno non può essere risolto osservando continuamente l’HMI. Il sistema necessita di un registratore diagnostico che acquisisca il periodo precedente e successivo al movimento anomalo.

Creare un buffer circolare PLC contenente il comando HMI grezzo, il comando validato, il setpoint finale di velocità, la direzione, l’abilitazione, la modalità, lo stato della sequenza, gli ingressi dei finecorsa, lo stato di convertitore pronto, il risultato della transazione USS e un contatore dei campioni.

Sul convertitore, acquisire la parola di comando ricevuta, il setpoint ricevuto, il setpoint interno attivo, la velocità effettiva, lo stato del feedback, la corrente di uscita, la corrente che produce coppia, se disponibile, gli avvisi e i guasti.

Il trigger può basarsi su una velocità effettiva superiore a una piccola soglia mentre il comando PLC finale è zero. Un altro trigger può rilevare un movimento al di fuori di uno stato di sequenza approvato. Anche una discrepanza tra la direzione comandata e quella misurata può attivare la registrazione.

Conservare i dati precedenti all’attivazione. Se la registrazione inizia solo dopo che la slitta si è mossa, la condizione iniziale potrebbe essere già scomparsa.

La diagnostica della comunicazione dovrebbe distinguere tra transazioni riuscite, risposte mancate, messaggi rifiutati, guasti consecutivi ed eventi di ripristino. Registrare quale slave era attivo durante l’errore.

Mantenere compatta la logica diagnostica. L’S7-200 dispone di memoria e capacità di scansione limitate. Verificare che la registrazione non alteri la temporizzazione delle routine USS esistenti.

Esportare i dati dopo ogni evento. Memorizzarli insieme alla data, allo stato della macchina, al rapporto del testimone e a qualsiasi osservazione fisica. Una sequenza di diversi eventi può rivelare uno schema che un singolo evento non può evidenziare.

Utilizzare contatori diagnostici che rispondano a domande specifiche

I contatori sono utili solo quando il loro significato è chiaro. Un contatore generale dei comandi e un contatore generale del feedback possono divergere per molte ragioni normali.

Contare ogni richiesta di movimento HMI accettata. Contare ogni comando di movimento accettato dall’arbitraggio finale del PLC. Contare ogni trasmissione USS completata correttamente. Contare ogni risposta valida ricevuta dall’azionamento dell’asse.

Contare anche i timeout di comunicazione, gli eventi di azionamento non pronto, le attivazioni dei finecorsa, i cambi di modalità e le scadenze dei comandi.

Memorizzare l’ultimo valore di velocità trasmesso e la parola di controllo. Memorizzare l’ultimo valore reale valido ricevuto e la parola di stato. Ove pratico, aggiungere un numero di sequenza alla struttura del comando.

Quando si verifica un evento, i contatori possono rispondere a diverse domande:

• L’HMI ha generato una richiesta?
• Il PLC ha approvato quella richiesta?
• Il PLC ha trasmesso un nuovo telegramma?
• L’azionamento ha restituito una risposta valida?
• Il movimento effettivo è iniziato senza un nuovo comando approvato?

Un contatore non dovrebbe essere azzerato automaticamente a ogni avvio, a meno che il suo valore storico non sia necessario. Si consideri il salvataggio di un contatore degli eventi in una memoria ritentiva, forzando al contempo tutti i comandi di movimento a un valore di avvio sicuro.

La protezione indipendente dal superamento della corsa non può dipendere dalla logica normale

I limiti di posizione software sono utili, ma non possono essere l’unica difesa contro un guasto che potrebbe avere origine nel programma del PLC, nel percorso di comunicazione o nel normale controllore dell’azionamento.

Ogni asse dovrebbe disporre di una protezione di finecorsa adeguatamente progettata. A seconda della valutazione dei rischi della macchina, ciò può includere finecorsa cablati, sensori di posizione con classificazione di sicurezza, relè di sicurezza, circuiti di inibizione dell’azionamento, contattori, freni o un’altra architettura convalidata.

Un ingresso standard del PLC che scrive un comando di velocità pari a zero non è automaticamente una funzione di sicurezza. Lo stesso errore logico che ha causato il movimento potrebbe impedire l’elaborazione di quel comando di arresto.

La rimozione del riferimento di velocità non garantisce comunque la rimozione della coppia. L’azionamento potrebbe rimanere abilitato, potrebbe rimanere attivo un riferimento secondario oppure l’energia meccanica immagazzinata potrebbe continuare a muovere il carico.

Testare indipendentemente l’arresto di emergenza, gli interblocchi dei ripari, i finecorsa di extracorsa, i contatti di guasto dell’azionamento, i freni e i contattori. Confermare che il riavvio richieda un’azione deliberata dopo l’intervento della protezione.

Durante il funzionamento diagnostico, ridurre, ove tecnicamente possibile, la velocità massima, l’accelerazione, la coppia e la corsa disponibile. Gli arresti meccanici temporanei devono essere utilizzati solo se progettati per l’energia d’impatto possibile.

Nessun obiettivo diagnostico giustifica l’esposizione di una persona a un asse che ha già dimostrato un movimento incontrollato.

Esempio: un cavo che si guasta solo durante l’inversione

Considerare una slitta che si comporta normalmente durante i test statici lenti, ma si muove violentemente durante una rapida inversione di direzione. Il registro PLC mostra un comando stabile. La traccia dell’azionamento mostra un’improvvisa perturbazione nella velocità misurata, seguita da una grande uscita correttiva.

Un test di continuità sul cavo dell’encoder dà esito positivo mentre la macchina è ferma. Tuttavia, il cavo passa attraverso una catena portacavi mobile. Un conduttore è fratturato vicino al raggio minimo di curvatura e si interrompe solo quando la catena raggiunge una determinata posizione.

Una misurazione con oscilloscopio all’ingresso dell’azionamento mostra il collasso di un canale dell’encoder durante l’inversione. Il comando rimane corretto e non viene registrato alcun guasto USS.

Il cavo viene sostituito con il tipo corretto per la flessione continua. Vengono ripristinati il pressacavo e la terminazione dello schermo. L’alimentazione dell’encoder e la qualità della forma d’onda vengono testate lungo l’intera corsa della slitta.

La verifica finale include inversioni ripetute a velocità ridotta, seguite da un funzionamento controllato alla normale velocità di produzione. Una nuova forma d’onda integra viene memorizzata come riferimento.

Questo caso mostra perché un guasto di feedback deve essere dimostrato dinamicamente. Un test statico della resistenza può dare esito positivo anche quando il cavo si guasta durante il servizio.

Esempio: un comando di jog sopravvive alla perdita di comunicazione dell’HMI

In un’altra macchina, premendo un pulsante di jog si imposta un bit PLC. Rilasciando il pulsante, il bit viene azzerato. L’HMI perde la comunicazione mentre il pulsante è premuto, quindi il comando di rilascio non raggiunge mai il PLC.

In quel momento, un altro interblocco impedisce il movimento. Il bit di jog obsoleto rimane nascosto. In seguito, l’operatore cambia la modalità della macchina. La logica PLC definitiva accetta ora la vecchia richiesta di jog e la slitta si muove inaspettatamente.

L’azionamento segue un setpoint PLC legittimo. La comunicazione USS è integra quando inizia il movimento. Sostituire l’encoder o aggiungere un altro collegamento dello schermo non risolverà il problema.

La logica PLC revisionata richiede una richiesta di jog continuamente aggiornata. Il comando scade dopo un breve intervallo. Viene accettato solo nella modalità corretta, con una comunicazione valida e la condizione di abilitazione richiesta.

La logica di avvio cancella tutte le richieste di movimento. L’azione di rilascio dall’HMI rimane, ma non è più l’unico meccanismo che rimuove il comando.

Il registratore degli eventi conferma che il bit grezzo dell’HMI è rimasto attivo dopo il precedente guasto di comunicazione. La causa principale non era la corruzione della comunicazione, bensì la gestione non sicura di un comando valido ma obsoleto.

Esempio di caso: il rumore mette in evidenza una gestione debole del buffer USS

Una terza macchina presenta timeout USS quando il mandrino accelera. I telegrammi danneggiati vengono rifiutati, quindi la rete non converte direttamente un comando di velocità in un altro.

Tuttavia, l’applicazione PLC non invalida il comando precedente dell’asse dopo una transazione non riuscita. Anche la routine USS viene eseguita in modo condizionale, creando intervalli di interrogazione irregolari.

Durante una transizione di sequenza, il nuovo comando zero viene scritto in una posizione di memoria mentre il buffer di trasmissione contiene ancora un valore diverso da zero più vecchio. Il telegramma successivo, andato a buon fine, invia dati validi ma obsoleti.

L’azionamento riceve un comando strutturato correttamente e risponde normalmente. Il disturbo sul livello fisico ha messo in evidenza una debolezza software, invece di generare direttamente il setpoint.

L’azione correttiva migliora il percorso dei cavi e il collegamento della schermatura. La routine di comunicazione del PLC viene quindi riprogettata in modo che ogni azionamento utilizzi una memoria dedicata. Il setpoint finale convalidato viene copiato nel buffer di trasmissione immediatamente prima della transazione.

Una risposta mancante contrassegna i dati come non validi. La risposta programmata alla perdita della comunicazione viene verificata mediante test controllati.

Questo caso dimostra perché la risoluzione dei problemi di comunicazione deve comprendere sia la forma d’onda elettrica sia il ciclo di vita dei dati applicativi.

Una sequenza pratica di indagine sul posto

Passaggio 1: Mettere in sicurezza la macchina. Predisporre una protezione indipendente contro il superamento della corsa, ridurre l’energia di prova e limitare l’accesso del personale.

Passaggio 2: Confermare l’hardware. Registrare i numeri d’ordine completi, le versioni software, le schede opzionali, i dispositivi di feedback e i moduli di interfaccia.

Passaggio 3: Creare i backup. Salvare il programma S7-200, il progetto TP 170A, il set di parametri MASTERDRIVES e i parametri MM440.

Passaggio 4: Definire l’evento. Registrare la direzione, la velocità, la durata, la modalità operativa, la posizione, lo stato del mandrino e il comportamento all’arresto.

Passaggio 5: Mappare la catena dei comandi. Identificare ogni sorgente del setpoint, dell’abilitazione, della direzione, della velocità fissa, del jog e del riferimento supplementare.

Passaggio 6: Aggiungere la registrazione sincronizzata. Acquisire i comandi del PLC, i dati USS, i valori interni dell’azionamento, il feedback, la corrente, i limiti, gli avvisi e i guasti.

Passaggio 7: Testare gli stati di avvio. Esaminare l’avviamento a freddo, il riavvio a caldo, le transizioni della CPU in RUN, la riconnessione dell’HMI e il ripristino della comunicazione.

Passaggio 8: Ispezionare dinamicamente il feedback. Verificare la tensione di alimentazione, la qualità della forma d’onda, l’accoppiamento, i connettori, la schermatura e la flessione dei cavi.

Passaggio 9: verificare USS e RS-485. Controllare l’indirizzamento, la topologia, la terminazione, le aree dati, la temporizzazione e la gestione degli errori.

Passaggio 10: esaminare i riferimenti incrociati del PLC. Individuare ogni scrittura del setpoint finale, della direzione e dell’abilitazione dell’azionamento.

Passaggio 11: verificare il percorso dei segnali dell’azionamento. Verificare ogni sorgente di comando e ogni elemento che contribuisce al setpoint attivo.

Passaggio 12: modificare un solo elemento alla volta. Registrare lo stato precedente, quello nuovo, il motivo, il risultato del test e il metodo di rollback.

Il consolidamento a lungo termine deve affrontare l’architettura

Dopo aver individuato la causa immediata, chiedersi perché un singolo guasto potesse produrre un movimento dannoso. Un singolo timeout della comunicazione, la rottura di un cavo o un errore dell’HMI non dovrebbe bypassare tutti i livelli di protezione.

Separare la generazione dei comandi, la validazione dei comandi, il trasporto della comunicazione, il controllo dell’azionamento e la protezione di sicurezza. Ogni livello dovrebbe avere una responsabilità definita.

Il PLC dovrebbe generare un comando limitato e con stato validato. La routine di comunicazione dovrebbe trasmettere dati aggiornati con validità e freschezza chiaramente definite. L’azionamento dovrebbe applicare i limiti operativi configurati e il monitoraggio della retroazione. Le funzioni di sicurezza indipendenti dovrebbero controllare il movimento pericoloso.

Valutare se l’architettura S7-200 e USS sia ancora supportabile. La migrazione a una piattaforma PLC e azionamenti più recente può migliorare la diagnostica, la registrazione temporale, la disponibilità dei componenti, la visibilità della rete e la gestione dei backup.

Una rete più recente non rende automaticamente sicura una macchina. PROFINET da solo non corregge un’arbitraggio debole dei comandi, una logica di avviamento inadeguata o una protezione insufficiente contro il superamento della corsa.

La modernizzazione dovrebbe includere l’HMI, gli schemi, il controllo delle versioni software, l’architettura di sicurezza, la strategia per i pezzi di ricambio e la formazione del personale. Sostituire solo il PLC può spostare il problema su un’altra piattaforma.

Per le applicazioni di posizionamento impegnative, valutare se il profilo di movimento debba essere eseguito all’interno di un azionamento dedicato o di un controllore di movimento, anziché tramite ripetuti comandi seriali di velocità. La decisione corretta dipende dalla precisione di posizionamento, dalla sincronizzazione, dal tempo di ciclo, dall’architettura di retroazione e dal rischio della macchina.

La verifica è più che aspettare il ripetersi del guasto

Sette giorni senza incidenti sono incoraggianti, ma non dimostrano che la causa principale sia stata rimossa. La verifica dovrebbe riprodurre deliberatamente le condizioni che in precedenza avevano aumentato il rischio.

Eseguire cicli ripetuti a corsa completa a velocità controllata. Includere inversioni rapide, accelerazione del mandrino, frenata del mandrino, condizioni di quadro caldo, carico normale massimo e movimento della catena portacavi.

Ripetere i test di avviamento e ripristino. Commutare l’alimentazione di comando secondo una procedura approvata. Testare il passaggio della CPU da STOP a RUN, il reset dell’azionamento, la riconnessione dell’HMI, la perdita di uno slave USS e il ripristino della comunicazione.

Verificare la risposta a un guasto del feedback utilizzando un metodo di test approvato. Non scollegare un encoder di produzione mentre il personale è esposto al movimento.

Testare ogni limite hardware, limite software, ingresso di guasto dell’azionamento, arresto di emergenza, freno e dispositivo indipendente di oltrepassamento della corsa. Confermare la risposta di arresto richiesta e il comportamento al riavvio.

Confrontare il comando finale del PLC, il comando ricevuto dall’azionamento, il setpoint interno attivo e il movimento effettivo durante ogni test.

Definire i criteri di accettazione prima dei test. I criteri idonei possono includere:

• Nessun movimento involontario durante qualsiasi condizione di avvio o ripristino.
• Nessun guasto di comunicazione USS non gestito.
• Nessun comando di movimento mantenuto dopo la perdita della comunicazione con l’HMI.
• Alimentazione del feedback stabile e forma d’onda stabile per tutta la corsa.
• Corretto funzionamento di ogni dispositivo indipendente di oltrepassamento della corsa.
• Concordanza registrata tra comando, setpoint ricevuto, setpoint attivo e movimento effettivo.

Mantenere il registratore degli eventi durante le prime fasi di produzione. Un’azione correttiva efficace dovrebbe eliminare sia il sintomo fisico sia il quadro diagnostico anomalo che lo ha causato.

La causa principale apparirà nel punto in cui i segnali non concordano per la prima volta

La corsa intermittente incontrollata in un sistema Siemens S7-200 e MASTERDRIVES non dovrebbe essere attribuita a “rumore”, “encoder” o “USS” senza prove.

Il metodo decisivo consiste nel correlare il comando finale del PLC, il comando ricevuto dall’azionamento, il setpoint interno attivo e la risposta meccanica effettiva.

Se il comando del PLC diventa errato, esaminare l’HMI e la logica applicativa. Se il valore trasmesso o ricevuto diventa errato, esaminare la gestione della memoria, la scalatura, la costruzione del telegramma e la rete RS-485.

Se l’azionamento attiva una sorgente di comando che il PLC non aveva previsto, verificare la configurazione interna dell’azionamento. Se tutti i comandi restano sicuri mentre il motore accelera, esaminare il feedback, l’alimentazione della scheda di controllo, l’hardware dell’azionamento e la meccanica.

I guasti del feedback restano plausibili, ma devono essere testati come circuiti completi. I problemi USS restano plausibili, ma dati validi obsoleti e una logica di ripristino debole sono spesso più plausibili del fatto che un telegramma danneggiato casualmente diventi un comando valido di velocità massima.

La macchina dovrebbe tornare al normale servizio solo dopo che la protezione indipendente è efficace, il meccanismo all’origine del problema è supportato da prove registrate e i test controllati hanno verificato sia l’azione correttiva sia la risposta a guasti futuri.

Questo approccio metodico richiede più preparazione rispetto alla sostituzione speculativa dei componenti. Produce inoltre un risultato più prezioso: una macchina il cui percorso di movimento è compreso, registrato, documentato e protetto dal prossimo guasto singolo.