Come ottimizzare il tempo di scansione e risolvere i guasti "Watchdog Exceeded" dell’IC695CPU310

Comprendere la causa principale del guasto di superamento del timer watchdog dell’RX3i

Un guasto "Watchdog Timer Exceeded" sul PACSystems RX3i IC695CPU310 di GE Fanuc non significa automaticamente che la CPU non disponga di sufficiente potenza di elaborazione. Non si dovrebbe mai gestire questo errore semplicemente aumentando l’impostazione del timer watchdog software. La causa principale è un picco imprevisto nel tempo di esecuzione di una singola scansione del programma PLC. Condizioni anomale nei cicli, eccessive chiamate ricorsive a funzioni o operazioni pesanti sulla memoria sono generalmente all’origine di questi ritardi di esecuzione.

Secondo le linee guida di riferimento delle CPU GE Fanuc, il watchdog software rileva ritardi anomali nel completamento della scansione. L’intervallo configurabile del watchdog software va da 10 ms a 2550 ms, regolabile con incrementi di 10 ms. I tecnici sul campo devono sempre individuare il collo di bottiglia del programma che aumenta il tempo di scansione nel caso peggiore, invece di mascherare i difetti logici sottostanti con timeout più lunghi.

Distinguere tra guasti del watchdog software e hardware

I tecnici devono identificare l’esatto meccanismo hardware o software alla base del guasto prima di modificare il codice.

• Guasti del watchdog software: si verificano quando una singola scansione supera la soglia del watchdog programmata. Tra le cause tipiche figurano cicli FOR o WHILE di grandi dimensioni, blocchi funzione ricorsivi, operazioni su array non limitate, elaborazioni intensive di stringhe, comunicazioni Ethernet concentrate o scritture dirette nella memoria non volatile.
• Guasti del watchdog hardware: rappresentano l’intervento di un meccanismo interno di sicurezza della CPU. A differenza degli errori software, i guasti del watchdog hardware spesso richiedono un ciclo completo di spegnimento e riaccensione fisica dell’alimentazione per essere cancellati sulle piattaforme CPU meno recenti come l’IC695CPU310.

Quando si verifica un arresto imprevisto, accedere alla tabella dei guasti di PAC Machine Edition (PME). Esaminare la descrizione del guasto, il codice del guasto, il timestamp e il conteggio delle occorrenze. Procedere con l’ottimizzazione della logica solo se il registro diagnostico indica esplicitamente la scadenza del watchdog software.

Analizzare la dinamica della scansione: scansione media e scansione massima nel caso peggiore

Molti tecnici dell’automazione si concentrano esclusivamente sul tempo medio di scansione del programma, creando un pericoloso punto cieco. Un sistema con un tempo medio di scansione di 18 ms può facilmente raggiungere 240 ms durante specifiche condizioni attivate. Se il limite del watchdog è impostato a 200 ms, il PLC passerà immediatamente a un arresto per guasto.

La logica condizionale pesante è spesso la causa di questi arresti casuali. Operazioni come i calcoli giornalieri per i report, l’archiviazione dei dati storici o le copie massicce in memoria vengono eseguite durante un singolo ciclo di scansione, aumentando il tempo di esecuzione di picco.

Metodi pratici per ridurre il tempo di scansione sul controller IC695CPU310

L’ottimizzazione dei cicli di scansione mantiene reattivi i circuiti di controllo negli impianti di confezionamento ad alta velocità, trattamento delle acque e produzione continua. Applicare queste tecniche ingegneristiche per ridurre il tempo massimo di scansione:

• ⚙️ Implementare la suddivisione temporale per i cicli di grandi dimensioni: non eseguire mai cicli FOR o WHILE di grandi dimensioni in un singolo ciclo di scansione. Suddividere l’elaborazione degli array in blocchi più piccoli distribuiti su più scansioni consecutive, utilizzando indici basati su macchine a stati.
• ⚙️ Verificare le chiamate ricorsive e i blocchi funzione: controllare l’albero delle chiamate ai blocchi in PAC Machine Edition. Eliminare le chiamate ricorsive indirette in cui la Funzione A attiva la Funzione B, che richiama accidentalmente la Funzione A in specifici rami logici.
• ⚙️ Passare dalla gestione continua dei dati a quella basata sugli eventi: evitare di copiare o ridimensionare migliaia di registri analogici a ogni scansione. Eseguire le formule matematiche complesse e l’ordinamento degli array solo quando vengono attivati i flag di modifica dei dati.
• ⚙️ Distribuire le attività di comunicazione Ethernet e seriale: scaglionare le comunicazioni attive come Modbus, SRTP o EGD su più cicli, utilizzando una strategia di interrogazione round-robin invece di interrogare contemporaneamente tutti i nodi esterni.
• ⚙️ Limitare le scritture nella memoria flash non volatile: le chiamate logiche dirette che scrivono dati operativi nella memoria non volatile richiedono una quantità significativa di tempo CPU. Attivare le scritture flash periodicamente o al completamento del lotto, anziché a ogni scansione della logica.

Procedura di troubleshooting sul campo passo dopo passo

Seguire questa sequenza ingegneristica metodica per eliminare in sicurezza i picchi del tempo di scansione:

1. Identificare l’origine del guasto: controllare la tabella dei guasti PME per confermare l’intervento del watchdog software.
2. Acquisire le metriche di riferimento: registrare la scansione media della CPU, la scansione massima nel caso peggiore e l’impostazione attuale del timeout del watchdog.
3. Individuare i colli di bottiglia nel codice: cercare cicli non limitati, trasferimenti continui di array, comunicazioni concentrate e scritture nella memoria flash.
4. Ristrutturare la logica: applicare macchine a stati, algoritmi di suddivisione temporale e blocchi logici basati sugli eventi per distribuire il carico di elaborazione.
5. Rivalutare le prestazioni: monitorare i tempi di scansione di picco durante diversi turni operativi, con il massimo carico produttivo.
6. Regolare il margine del watchdog: impostare il limite finale del watchdog software leggermente al di sopra del nuovo tempo di scansione nel caso peggiore, per mantenere un margine di sicurezza affidabile.

Scenario applicativo: ottimizzazione del sistema di trasporto di una linea di imbottigliamento

In uno stabilimento di imbottigliamento di bevande ad alta velocità controllato da un IC695CPU310, la linea di produzione registrava arresti intermittenti del PLC per guasto ogni pochi giorni durante i cambi turno.

La causa principale: durante i cambi turno, una subroutine di logica ladder attiva eseguiva un ciclo non limitato che ordinava, aggiornava e copiava 4.000 registri di tracciamento dei prodotti in un array di archiviazione all’interno di una singola scansione. Ciò aumentava il tempo massimo di scansione da un valore normale di 22 ms a 265 ms, superando la soglia del watchdog software di 200 ms.

La soluzione: il nostro team di ingegneria ha ristrutturato l’algoritmo di ordinamento in una macchina a stati con suddivisione temporale, che elaborava 200 registri per ciclo di scansione nell’arco di 20 scansioni consecutive. Questa modifica ha ridotto il tempo massimo di scansione da 265 ms a 38 ms, eliminando completamente il problema dell’intervento del watchdog senza modificare i componenti hardware.

Domande frequenti (FAQ)

D1: La nostra CPU310 attiva regolarmente guasti "Watchdog Timer Exceeded". Significa che la velocità del processore della CPU è troppo bassa e che deve essere sostituita?
Risposta: non necessariamente. La sostituzione della CPU dovrebbe essere l’ultima opzione. La maggior parte degli errori del watchdog deriva da una logica di programma strutturata male, operazioni su cicli non limitate o improvvisi picchi di comunicazione. È possibile eliminare i picchi di scansione ristrutturando i calcoli pesanti in macchine a stati con suddivisione temporale, distribuite su più cicli logici. Valutare un aggiornamento hardware solo se, dopo la ristrutturazione del codice, il tempo medio di scansione rimane vicino alla capacità della CPU.

D2: Possiamo impostare in sicurezza il timer watchdog software sul valore massimo di 2550 ms per evitare gli interventi?
Risposta: sebbene il menu di configurazione della CPU consenta fisicamente un valore fino a 2550 ms, si tratta di una pratica ingegneristica sconsigliata. Estendere il limite a tal punto maschera errori logici critici, come cicli infiniti o chiamate ricorsive bloccate. Nell’automazione di processi critici, una CPU bloccata che continua a funzionare per 2,5 secondi prima dell’intervento può causare gravi rischi operativi e per la sicurezza. Mantenere il limite del watchdog leggermente al di sopra del tempo di scansione effettivo nel caso peggiore, con un margine di sicurezza ragionevole.

D3: In base all’esperienza sul campo, qual è il modo migliore per individuare il blocco specifico che causa un picco del tempo di scansione?
Risposta: utilizzare gli strumenti diagnostici integrati in PAC Machine Edition insieme a timer di esecuzione personalizzati. Inserire letture del timestamp di sistema prima e dopo i blocchi funzione sospetti, per registrare le durate massime di esecuzione nei registri di tracciamento. Confrontare queste letture con i registri dello stato della macchina per scoprire quali eventi produttivi, come cambi lotto, generazione di report o interrogazioni HMI, attivano il carico di scansione massimo.

Approfondimenti dell’autore e opinione dell’esperto

"Nei nostri anni di supporto alle apparecchiature per l’automazione industriale presso Ubest Automation Limited, vediamo spesso i team sul campo cercare di risolvere i guasti del watchdog del PLC aumentando arbitrariamente le impostazioni del timer o acquistando nuovo hardware. Su piattaforme come PACSystems RX3i, i picchi del tempo di scansione sono quasi sempre riconducibili a una gestione inefficiente dei dati o a comunicazioni non limitate. Adottare un approccio disciplinato che privilegi il software consente di ridurre significativamente i tempi di fermo e di prolungare la vita utile dell’hardware di controllo esistente."
— Team di ingegneria di Ubest Automation Limited

Cerchi hardware GE Fanuc affidabile e supporto specializzato?

Che si tratti di eseguire il troubleshooting di sistemi legacy o di acquistare parti di ricambio per l’automazione di fabbrica, Ubest Automation Limited fornisce componenti PLC originali e testati, moduli DCS e soluzioni di controllo industriale.

Scopri i componenti originali GE Fanuc e PACSystems presso Ubest Automation Limited.