Pianificazione della capacità di EtherNet/IP per CompactLogix L35E

Il CompactLogix 1769-L35E rimane comune nelle macchine che hanno superato la durata prevista del loro piano di rete originale. I problemi di espansione iniziano solitamente quando un elenco di dispositivi viene considerato come un conteggio delle connessioni. La capacità EtherNet/IP dipende dal tipo di traffico generato da ciascun dispositivo, dalla frequenza con cui scambia dati e dalle risorse del controller già utilizzate dall'applicazione. Una verifica sicura inizia quindi dal progetto in esecuzione e dalla diagnostica, non da una regola generica sul numero di dispositivi per porta.

La pianificazione delle connessioni deve tenere conto del traffico configurato, delle frequenze di aggiornamento e dei rischi legati al ciclo di vita, non del numero di spine Ethernet.

Iniziare dal limite documentato del controller

Il Manuale dell'utente dei controller CompactLogix 1769 di Rockwell Automation documenta che l'L35E supporta 100 connessioni CIP. Si tratta di un limite di risorse, non dell'autorizzazione a collegare 100 dispositivi. Un singolo dispositivo può richiedere più di una connessione, mentre alcune comunicazioni possono condividere una connessione ottimizzata. La revisione del firmware, la configurazione dei moduli, i tag prodotti e consumati, i messaggi memorizzati nella cache e i client HMI o di supervisione influiscono tutti sul totale finale.

Il controller è inoltre un prodotto fuori produzione. Rockwell indica il 1769-L35E come fuori produzione dal 20 dicembre 2020. Ciò non rende inutilizzabile un sistema funzionante, ma cambia la decisione ingegneristica: un problema di capacità deve essere valutato insieme alla disponibilità di ricambi, al supporto del firmware, all'esposizione alla cybersecurity e al costo di un guasto non pianificato.

Creare un inventario delle connessioni a partire dal progetto

Aprire il progetto offline corrispondente al controller in esecuzione ed elencare ogni adattatore I/O configurato, azionamento, tag prodotto o consumato, percorso dei messaggi, server dati HMI, sistema di storicizzazione, gateway e connessione di programmazione. Registrare se ogni scambio è costituito da I/O ciclico, dati prodotti, un messaggio esplicito o un'interrogazione client. Non assegnare un'impronta fissa alle connessioni basandosi solo sul nome del produttore. L'autorità è la configurazione effettiva.

Per gli I/O distribuiti, verificare se il formato di comunicazione selezionato crea connessioni dirette ai moduli o una connessione ottimizzata per rack. Per le istruzioni MSG, identificare quali sono memorizzate nella cache e se più messaggi possono essere attivi contemporaneamente. Per i sistemi di supervisione, contare i percorsi di comunicazione indipendenti e verificare la strategia di interrogazione. Un foglio di calcolo dovrebbe collegare ogni connessione presunta a un oggetto del progetto o a una configurazione client verificata.

Separare il conteggio delle connessioni dal carico dei pacchetti

Un controller può rimanere al di sotto del proprio limite di connessioni e offrire comunque prestazioni di rete scadenti. Gli intervalli richiesti tra i pacchetti, la frequenza dei messaggi, le dimensioni dei pacchetti, il comportamento multicast, la configurazione degli switch e i picchi generati da più client influenzano il carico dei pacchetti. Gli RPI molto rapidi devono essere giustificati dal processo meccanico e dalla risposta di controllo richiesti; rendere ogni dispositivo più veloce non migliora la macchina.

Stabilire una baseline mentre la macchina opera normalmente in produzione. Registrare l'utilizzo delle connessioni, i contatori degli errori Ethernet, i messaggi persi o scaduti, lo stato degli I/O, la reattività dell'HMI e il comportamento del ciclo di scansione del controller. Ripetere la registrazione durante l'avvio, il download delle ricette, i picchi di allarmi, l'accesso per la manutenzione e altri picchi plausibili. Le medie possono nascondere l'intervallo breve che causa un guasto intermittente.

Lo switching gestito, una topologia documentata e misurazioni ripetibili rendono diagnosticabili i guasti intermittenti di capacità.

Non utilizzare un 1769-AENTR come seconda porta dell'L35E

Un 1769-AENTR è un adattatore EtherNet/IP per un gruppo remoto di Compact I/O controllato attraverso la rete. Non è un'interfaccia Ethernet di espansione che aumenta il pool di comunicazione del controller L35E e non può essere collegato come seconda porta del controller per spostare il traffico HMI o dei messaggi lontano dall'interfaccia integrata. Progettare partendo da questa ipotesi crea una topologia che non può svolgere la funzione dichiarata.

Se gli I/O remoti sono appropriati, un adattatore può concentrare gli I/O fisici in un'altra posizione, ma la connessione I/O risultante termina comunque sul controller. Se l'applicazione richiede una maggiore capacità di comunicazione, moderne funzioni di sicurezza o un supporto più lungo del ciclo di vita, la soluzione potrebbe essere la migrazione a una famiglia di controller più recente anziché l'aggiunta di un altro adattatore.

Ridurre il carico evitabile senza nascondere il problema

L'ottimizzazione dovrebbe preservare i requisiti del processo. Rimuovere i percorsi abbandonati e i client inutilizzati. Consolidare le connessioni I/O quando la piattaforma e i tipi di modulo lo consentono. Memorizzare nella cache solo le connessioni MSG che richiedono un'esecuzione ripetuta rapida e sequenziare i messaggi non critici affinché non si aprano tutti contemporaneamente. Aumentare un RPI o l'intervallo di interrogazione solo dopo aver confermato che i tempi di rilevamento, gli interblocchi, gli allarmi e la qualità del controllo rimangano accettabili.

Utilizzare switch industriali gestiti e documentare le impostazioni VLAN, multicast e IGMP, ove applicabili. Uno switch può controllare l'inoltro non necessario e migliorare la visibilità, ma non può creare risorse di connessione nel controller. Allo stesso modo, l'aggiunta di uno switch non gestito modifica il numero di porte, non la capacità del controller.

Diagnosticare metodicamente un sospetto guasto di capacità

Innanzitutto, confermare il progetto in esecuzione, il codice catalogo del controller, la revisione del firmware e la topologia di rete. Confrontare quindi le connessioni configurate con la diagnostica in tempo reale. Cercare moduli I/O che alternano lo stato di funzionamento a quello di guasto, istruzioni MSG che scadono durante i picchi di carico o valori HMI che diventano obsoleti mentre la logica del controller continua a essere eseguita.

Modificare una sola variabile alla volta. Disconnettere un client non essenziale autorizzato, sospendere un servizio di interrogazione non critico o sequenziare temporaneamente i messaggi durante una finestra di manutenzione controllata. Se il sintomo cambia, misurare il carico prima e dopo anziché dichiarare il successo sulla base di una sola ora senza problemi. Non estendere mai i timeout né sopprimere gli allarmi di comunicazione soltanto per nascondere la congestione.

Mettere in servizio le espansioni con test di guasto

Prima di aggiungere un dispositivo, definire il tipo di connessione, il requisito di aggiornamento, il responsabile e la risposta al guasto. Testare la produzione normale e la peggiore richiesta simultanea plausibile. Interrompere il nuovo dispositivo, ripristinarlo, riavviare la sua alimentazione di rete e confermare che il controller, l'HMI e gli allarmi distinguano i dati errati o obsoleti da uno stato di processo valido. Verificare che il ripristino non riavvii inaspettatamente le apparecchiature.

Conservare l'inventario, le istantanee diagnostiche, la configurazione degli switch e i risultati dell'accettazione insieme al backup del sistema di controllo. Per le opzioni hardware attuali, consultare sistemi PLC e PAC; per gli switch gestiti e i componenti di rete, utilizzare la collezione per comunicazione e networking. La posizione editoriale è semplice: un'espansione dell'L35E è difendibile solo quando il carico di picco misurato, il comportamento in caso di guasto e il piano del ciclo di vita sono tutti documentati.