Erro di overflow SLC 500 0020: come correggere il latch S:5/0
Diagnostica l’errore grave 0020H di SLC 500 prima di cancellare S:5/0. Scopri come funziona la promozione di fine scansione, identifica la prima istruzione responsabile, definisci una politica di r...
L’errore grave 0020H dell’SLC 500 viene comunemente descritto come un errore di overflow, ma il codice è più ampio di una singola istruzione ADD errata. Rockwell lo definisce una condizione di errore minore rimasta attiva quando il processore ha raggiunto END, TND o REF e che è stata quindi convertita in un errore grave. L’attività diagnostica consiste nell’identificare quale bit di stato ha causato la conversione, determinare quale operazione lo ha impostato e decidere se un recupero controllato sia sicuro.
L’errore 0020H dovrebbe portare a un’analisi del file di stato, non alla conclusione automatica che l’hardware del processore sia guasto.
Leggere il file di stato prima di cancellare qualsiasi dato
Registrare il codice di errore, il numero di catalogo del processore, la modalità operativa, l’ora, lo stato della produzione e i valori di S:5 e S:6 prima di reimpostare il controllore. S:5/0 è il trap di overflow matematico. S:5/2 indica un errore del registro di controllo causato da istruzioni come FIFO, scorrimento dei bit o operazioni con sequenziatori. Anche altri bit di S:5 possono essere convertiti alla fine della scansione. Cancellare i dati del processore prima di acquisire questi valori distrugge le prove e favorisce il ripresentarsi dello stesso guasto.
Il Manuale di riferimento del set di istruzioni Rockwell SLC 500 afferma che S:5/0 viene impostato quando si verifica un overflow matematico e che viene dichiarato un errore grave 0020H se il bit è ancora impostato quando viene eseguita END, TND o REF. Il manuale consiglia di esaminare il bit dopo l’istruzione pertinente, adottare le misure appropriate e solo in seguito cancellare S:5/0 con un OTU oppure cancellare la parola di stato applicabile.
Comprendere il risultato matematico oltre al trap
Per ADD, SUB, MUL, DIV o NEG, un risultato che non può essere rappresentato nella destinazione imposta il bit di overflow aritmetico S:0/1 e il trap S:5/0. Con lo stato predefinito di S:2/14, un risultato positivo è limitato a 32767 e uno negativo a -32768. Quando S:2/14 è impostato, nella destinazione possono invece essere inseriti i 16 bit meno significativi. Questa impostazione modifica il comportamento della destinazione; non dimostra che il risultato dell’applicazione sia valido.
DDV e alcune istruzioni di conversione o scalatura seguono regole aggiuntive, quindi l’analisi deve basarsi sul riferimento specifico dell’istruzione. Una divisione per zero, una lunghezza di controllo non valida o un indirizzo indiretto al di fuori dell’intervallo consentito possono produrre un percorso di stato diverso. Non raggruppare ogni evento 0020H sotto la voce “overflow di intero” senza controllare S:5 e l’istruzione eseguita immediatamente prima che il bit venisse impostato.
Individuare la prima operazione responsabile
Esaminare le modifiche recenti e fare un controllo incrociato di ogni istruzione in grado di impostare il bit di stato osservato. Per l’overflow matematico, verificare i calcoli di scalatura, i totali di produzione, le conversioni delle unità, i valori cumulativi di runtime, i limiti con segno e le destinazioni intermedie. Un calcolo può essere matematicamente valido nelle unità ingegneristiche, ma non sicuro quando un passaggio intermedio viene memorizzato in un intero a 16 bit.
Registrare o acquisire gli operandi di origine, i valori di destinazione, S:0/1 e S:5/0 intorno alle istruzioni sospette. In un sistema di test offline, riprodurre i casi limite appena al di sotto, esattamente al limite e appena al di sopra dell’intervallo consentito. Se durante una scansione più istruzioni possono impostare il trap, aggiungere latch diagnostici temporanei che identifichino la prima posizione. Questi bit diagnostici devono essere verificati, denominati e rimossi oppure mantenuti formalmente dopo aver individuato la causa principale.
Utilizzare la logica di recupero solo con una politica esplicita
Un OTU S:5/0 generalizzato sull’ultima riga può impedire la conversione alla fine della scansione, ma sopprime anche l’arresto indipendentemente dal calcolo che ha generato l’overflow. Ciò può essere accettabile per un contatore non critico il cui valore viene limitato e segnalato tramite allarme. Non è accettabile quando il risultato influisce su movimento, pressione, temperatura, dosaggio, protezione delle apparecchiature o su una decisione legata alla sicurezza.
Una logica robusta controlla il risultato dell’istruzione nel punto in cui viene prodotto. Convalidare gli operandi prima dell’esecuzione, scegliere una destinazione con un intervallo sufficiente, limitare il valore solo quando il significato del processo lo consente, impostare un allarme diagnostico, sostituire il valore con uno sicuro e documentato, quindi cancellare il trap. Se la risposta corretta consiste nell’arrestare la sequenza, preservare il guasto invece di forzare la prosecuzione del processore.
Una routine di guasto dell’utente può supportare il recupero controllato per eventi selezionati e il manuale Rockwell include un esempio che conta le occorrenze ripetute di 0020H e consente infine l’arresto. Questo schema è più informativo della cancellazione incondizionata perché distingue un evento isolato e gestito da un difetto ricorrente. La routine di guasto stessa deve essere testata con attenzione; un secondo errore al suo interno può sovrascrivere le informazioni diagnostiche o impedire il recupero.
Distinguere i guasti software dai problemi hardware
Un trap di overflow indica solitamente un problema nei dati del programma e nel comportamento delle istruzioni, non un guasto del telaio. Tuttavia, un’alimentazione instabile, problemi di memoria o modifiche involontarie al programma possono alterare i dati e meritano un’analisi quando le prove lo suggeriscono. Verificare la batteria e la cronologia dell’alimentazione del controllore, confrontare il programma in esecuzione con l’archivio approvato e controllare se un HMI, un messaggio o un sistema esterno scrive gli operandi coinvolti.
Non sostituire un processore SLC come prima risposta a un limite matematico riproducibile. Un processore sostitutivo che esegue lo stesso programma con gli stessi dati riprodurrà il guasto. Se la piattaforma è obsoleta, gestire le scorte e la migrazione secondo il piano del sito per il ciclo di vita dei sistemi PLC e PAC, mantenendo però separata questa decisione dall’analisi immediata della causa principale.
Dimostrare l’efficacia della correzione
Testare la logica corretta con valori normali, a entrambi i limiti dell’intervallo, con ingressi non validi, perdita delle comunicazioni, prima scansione e qualsiasi condizione di reset. Verificare che gli allarmi identifichino il calcolo interessato, che il valore sostitutivo sia sicuro e che gli eventi ripetuti vengano conteggiati. Osservare S:5/0 e S:0/1 durante un ciclo di produzione rappresentativo e verificare che il processore non si limiti a nascondere un overflow ricorrente.
Archiviare i file RSS prima e dopo la modifica, le prove del guasto, i risultati dei test e la motivazione alla base di qualsiasi logica di recupero. Abbinare questa documentazione alle indicazioni sulla migrazione della scalatura da SLC del sito durante la modernizzazione dell’applicazione. L’errore 0020H diventa gestibile quando il team lo considera un problema preciso di stato e qualità dei dati, anziché un bit da disattivare immediatamente.