Perché RSLogix 500 rallenta durante la modifica online

La modifica online lenta in RSLogix 500 viene spesso attribuita a un processore SLC obsoleto, ma il ritardo visibile può avere origine in diversi punti: la workstation di progettazione, le comunicazioni RSLinx, una rete instradata o rumorosa, un’incoerenza nel file di progetto, la memoria disponibile del controller oppure il lavoro richiesto al processore per mantenere una modifica online. Sostituire l’hardware prima di separare questi livelli può lasciare irrisolto il guasto reale.

Misurare dove si verifica il ritardo—aggiornamento della schermata, esplorazione, caricamento, verifica, accettazione, test o assemblaggio—prima di modificare il controller o la rete.

Definire con precisione il sintomo

“Online lento” può descrivere guasti molto diversi. Annotare se il ritardo compare durante l’apertura di una tabella dati, lo scorrimento della logica ladder, la ricerca nel progetto, la modifica di un rung, la verifica della sintassi, l’accettazione di una modifica, il test delle modifiche, l’assemblaggio delle modifiche o il salvataggio del file. Notare se il processore rimane reattivo e se, nello stesso momento, cambiano il tempo di scansione della produzione, gli errori di comunicazione o gli aggiornamenti dell’HMI.

Cronometrare diverse azioni ripetibili invece di affidarsi alle impressioni. Confrontare la navigazione offline con quella online nello stesso progetto. Confrontare una semplice lettura di una tabella dati con un caricamento. Se il progetto offline è già lento, è opportuno occuparsi prima della workstation o del database del progetto.

Stabilire una baseline sicura

Caricare e preservare il programma in esecuzione, quindi confrontarlo con il file sorgente previsto. Annotare catalogo del processore, serie, firmware, dimensione della memoria, modalità operativa, versione di RSLogix 500, versione di RSLinx, driver di comunicazione, percorso, sistema operativo della workstation e risorse libere su disco e in memoria. Mantenere la macchina in condizioni tali da poter annullare una modifica in sicurezza.

Il Manuale utente dell’hardware modulare SLC 500 di Rockwell Automation è il riferimento principale per le configurazioni supportate di processori e comunicazioni. Il Manuale di riferimento del set di istruzioni SLC 500 documenta il comportamento delle istruzioni, i file dati, le informazioni di stato e gli errori aritmetici che possono diventare rilevanti quando una modifica proposta cambia l’esecuzione o l’uso della memoria.

Separare il ritardo della workstation da quello delle comunicazioni

Chiudere le applicazioni non correlate, disabilitare i componenti aggiuntivi del progetto non necessari e osservare CPU, pressione sulla memoria, attività del disco e reattività del display durante la riproduzione del ritardo. Database di riferimenti incrociati di grandi dimensioni, numerose tabelle dati aperte, stato ladder animato, scansioni antivirus, grafica del desktop remoto e un’unità di sistema quasi piena possono far sembrare lento l’editor senza modificare la scansione del controller.

Seguire la politica di manutenzione approvata prima di modificare il software di sicurezza. Un’esclusione diagnostica o un test temporaneo offline devono essere controllati e annullati al termine. Non indebolire permanentemente la protezione dell’endpoint solo per rendere più reattivo uno strumento datato.

Testare quindi le comunicazioni. Osservare la diagnostica del driver RSLinx e confrontare un percorso locale diretto con il normale percorso instradato quando esiste un’alternativa sicura e supportata. Verificare la presenza di tentativi ripetuti, visibilità instabile dei nodi, indirizzi duplicati, errori di duplex o dello switch su Ethernet e guasti del livello fisico sulle reti seriali, DH-485 o DH+. Un’esplorazione che alla fine riesce non dimostra che il percorso di programmazione sia integro.

Verificare la coerenza del progetto e della sessione

Una sessione online è più sicura quando il file aperto corrisponde effettivamente al controller in esecuzione. Se il software deve correlare al controller un progetto obsoleto o strutturalmente diverso, la navigazione e la verifica possono diventare confuse anche quando la connessione è stabile. Caricare in una copia controllata, confrontare i file e risolvere le differenze inspiegate prima di modificare la logica di produzione.

Annullare le aree di modifica abbandonate e verificare che un’altra workstation non possieda una sessione di modifica. Annotare eventuali forzature, modifiche online e logiche temporanee di manutenzione già presenti. Più modifiche irrisolte aumentano il rischio e rendono più difficile stabilire se il ritardo appartenga alla nuova modifica o allo stato esistente.

Comprendere il costo lato controller

La modifica online non equivale alla sostituzione offline di un file. Il controller e il software devono mantenere la logica originale e quella modificata durante la sequenza di modifica, fino all’assemblaggio o all’annullamento della modifica. Di conseguenza, contano sia la memoria disponibile sia le capacità del processore. Un controller vicino al limite di memoria può avere meno spazio per le strutture temporanee richieste da una modifica sostanziale.

Mantenere piccola la prima modifica diagnostica. Non combinare una modifica della logica con nuovi file dati, tabelle dati ampliate, modifiche alle comunicazioni e pulizia della documentazione. Alcune modifiche strutturali richiedono una modifica offline e un download anziché una soluzione alternativa online. Se una modifica non può essere espressa entro i limiti supportati dalla piattaforma per le modifiche online, programmare il fermo corretto.

Monitorare il tempo di scansione del processore e la scansione massima, lo stato delle comunicazioni, gli indicatori di guasto maggiori e minori e la temporizzazione del processo prima, durante e dopo la modifica. Una risposta rapida dell’editor non giustifica una modifica che introduce variazioni eccessive della scansione o altera una sequenza critica dal punto di vista temporale.

Utilizzare una sequenza di modifica controllata

Per prima cosa, creare la modifica più piccola possibile che dimostri il percorso di modifica senza influire sull’apparecchiatura. Verificarla, accettarla e osservare il processore e l’applicazione secondo la procedura del sito. Testare la modifica solo quando il processo si trova nello stato sicuro definito. Confermare la logica prevista e tutte le uscite interessate prima di assemblarla.

Dopo l’assemblaggio, confrontare o caricare nuovamente il progetto e salvare il file sorgente risultante con data e ora, motivazione della modifica, approvatore e riferimento per il ripristino. Se le prestazioni peggiorano in una fase specifica, fermarsi e preservare queste evidenze. Accettare ripetutamente modifiche sempre più grandi non è un metodo valido per diagnosticare un ritardo sconosciuto.

Interpretare i modelli più comuni

Se lo scorrimento e le ricerche offline sono lenti mentre gli aggiornamenti dei dati del controller sono normali, concentrarsi sulla workstation e sul database del progetto. Se tutte le letture online si interrompono e aumentano i tentativi del driver, concentrarsi sul percorso di comunicazione. Se le modifiche piccole funzionano ma quelle più grandi falliscono o si bloccano, esaminare la memoria, la struttura del progetto e i limiti supportati per le modifiche. Se l’editor rimane reattivo ma il tempo di scansione del processo aumenta, analizzare la modifica alla logica.

Se il rallentamento compare solo dopo molte ore, riavviare la sessione di progettazione in modo controllato e verificare la crescita del consumo di risorse invece di riavviare il controller. Se un’altra workstation funziona normalmente attraverso lo stesso percorso di rete, confrontare revisioni software, driver, controlli di sicurezza e file di progetto prima di dichiarare guasto il PLC.

Decidere quando interrompere la modifica online

Fermarsi quando non è possibile abbinare con sicurezza il progetto in esecuzione, le comunicazioni sono instabili, il controller è vicino a un limite di risorse, la modifica richiede cambiamenti strutturali oppure il processo non può tollerare il test. Pianificare una verifica offline e un download controllato con backup e ripristino invece di forzare una riparazione durante il funzionamento.

Le piattaforme legacy e le opzioni di migrazione possono essere consultate nella collezione Allen-Bradley e nella collezione di sistemi PLC e PAC. La migrazione dovrebbe basarsi su evidenze relative a rischi del ciclo di vita, prestazioni, parti di ricambio e ripristino, non su una singola sessione di modifica lenta.

Prospettiva ingegneristica

La domanda utile non è “Perché RSLogix è lento?”, ma “Quale confine diventa lento, durante quale azione ripetibile e quali evidenze cambiano insieme?”. Quando gli effetti della workstation, delle comunicazioni, del progetto, del controller e del processo vengono misurati separatamente, il team può correggere il vincolo reale proteggendo al contempo la macchina in funzione.