PanelView Plus con CompactLogix L32E e SLC 5/04

Un progetto HMI di generazioni miste diventa difficile quando un’unica applicazione PanelView Plus deve scambiare dati sia con un CompactLogix 1769-L32E su EtherNet/IP sia con un SLC 5/04 che dipende ancora da DH+ o DF1. La prima correzione riguarda la terminologia: l’L32E è un controller CompactLogix, non un controller ControlLogix. La seconda riguarda l’architettura. FactoryTalk View Machine Edition dovrebbe trattare ogni percorso verso il controller come un contratto di comunicazione separato e verificabile, invece di nascondere entrambi i processori dietro un’unica scorciatoia ambigua.

Un HMI ibrido dovrebbe esporre due percorsi espliciti verso i controller, così un tecnico può distinguere un guasto EtherNet/IP da un guasto della rete legacy.

Inizia con un inventario, non con un bridge

Registra il numero di catalogo esatto del PanelView Plus, la revisione del firmware, la versione di FactoryTalk View ME, i numeri di catalogo dei controller, la configurazione dei canali SLC e ogni modulo di comunicazione installato. Un 1769-L32E dispone di una porta Ethernet integrata. Un SLC 5/04 fornisce DH+ sul Canale 1 e può utilizzare il Canale 0 per i protocolli seriali; non diventa un controller EtherNet/IP solo perché è installato un gateway. Questa distinzione determina quale dispositivo gestisce il routing, la diagnostica e il ripristino.

Separa inoltre i percorsi di progettazione da quelli di runtime. Il computer di engineering può esplorare un controller tramite un’interfaccia, mentre il terminale ne utilizza un’altra dopo il download del file di runtime. Il Manuale utente dei dispositivi di rete EtherNet/IP di Rockwell spiega che FactoryTalk Linx fornisce il servizio di comunicazione di runtime utilizzato da PanelView Plus e FactoryTalk View. Una ricerca riuscita dal laptop non dimostra quindi che il percorso di runtime del terminale sia corretto.

Configura direttamente il percorso CompactLogix

Assegna all’L32E un indirizzo statico documentato sulla sottorete di controllo e crea una scorciatoia dedicata per il dispositivo FactoryTalk Linx, ad esempio CLX_L32E. Seleziona il controller nella scheda Design, quindi copia o ricrea il percorso nella scheda Runtime. Verifica che la scorciatoia punti al controller stesso e non soltanto a un driver Ethernet. Terminale, controller e workstation di engineering devono avere impostazioni IP compatibili, ma non devono condividere gli indirizzi. Controlla le maschere di sottorete e qualsiasi confine VLAN instradato prima di attribuire la colpa all’applicazione HMI.

Quando possibile, usa tag con ambito del controller e mantieni un prefisso chiaro che ne indichi la proprietà nei riferimenti HMI. Un allarme o un comando denominato in base al controller di origine è più facile da diagnosticare durante una migrazione. Per i comandi, usa stati di richiesta, conferma, timeout e consenso invece di una scrittura HMI momentanea che presupponga che la rete non si interrompa mai. Il PLC deve gestire la decisione finale sull’interblocco; il PanelView è un’interfaccia operatore, non un controller di sicurezza.

Scegli una strategia onesta per l’accesso allo SLC 5/04

Il percorso verso lo SLC dipende dall’hardware installato e dalla velocità dati richiesta. Un’interfaccia seriale-Ethernet può esporre i dati del Canale 0, ma i limiti di connessione e throughput devono essere verificati rispetto al manuale dell’interfaccia esatta. Un gateway può essere utile per un numero ridotto di valori HMI, ma non deve essere considerato equivalente a EtherNet/IP nativo. Interrogare troppi file di interi attraverso un collo di bottiglia seriale genera visualizzazioni lente, valori obsoleti e allarmi di comunicazione intempestivi.

Se DH+ deve rimanere, un gateway basato su 1756-DHRIO può instradare il traffico tra Ethernet e DH+ quando è configurato correttamente in uno chassis ControlLogix. È lo chassis a fungere da gateway; ciò non trasforma il 1769-L32E in un controller ControlLogix. Conferma i numeri di nodo DH+ in ottale, la modalità del canale, la velocità di trasmissione, la terminazione e il percorso completo. Evita di pubblicare un percorso di messaggistica universale, perché i numeri di slot e la topologia dipendono dal sito. Un percorso copiato da un’altra macchina può raggiungere il nodo sbagliato o smettere di funzionare dopo una modifica dello chassis.

Può essere appropriato anche un gateway di protocollo industriale di terze parti, ma solo dopo aver verificato i servizi supportati, i limiti relativi ai client simultanei, i tempi seriali, la classificazione ambientale e il supporto del fornitore. La decisione dovrebbe basarsi sul traffico HMI misurato e sul rischio legato al ciclo di vita, non sul fatto che il dispositivo compaia in una finestra di esplorazione.

Le scorciatoie separate preservano l’identità del controller e rendono la diagnostica di runtime molto più utile.

Metti in servizio le scorciatoie come sistemi indipendenti

Crea una scorciatoia per l’L32E e un’altra per il percorso SLC. Non riutilizzare mai il nome di una scorciatoia durante una migrazione solo per evitare di modificare i tag. Conferma le schede Design e Runtime, salva la configurazione di comunicazione, crea il file di runtime per il firmware del terminale previsto e scaricalo includendo le impostazioni di comunicazione corrette.

Per prima cosa verifica i valori in sola lettura. Usa un valore che cambi in modo prevedibile, un heartbeat generato da ciascun controller e un timestamp HMI che renda evidente la presenza di dati obsoleti. Poi verifica gli handshake dei comandi con la macchina in condizioni sicure. Disconnetti separatamente ciascun percorso di rete e conferma che l’HMI identifichi il controller guasto senza bloccarsi né presentare come attuali vecchi valori. Ripristina il collegamento e misura il tempo di recupero.

Diagnostica per livelli

Se entrambe le scorciatoie non funzionano, inizia dall’indirizzamento del terminale, dallo stato delle porte dello switch, dall’accesso VLAN e dalla configurazione di runtime. Se non funziona solo l’L32E, verifica la raggiungibilità IP, la modalità del controller, lo stato della porta integrata e la destinazione della scorciatoia. Se non funziona solo lo SLC, suddividi il percorso in Ethernet-gateway, configurazione del gateway, cablaggio seriale o DH+ e impostazioni dei canali SLC. I contatori degli errori e gli indicatori di collegamento sono più utili che scaricare ripetutamente lo stesso file HMI.

Il lavoro su DH+ richiede particolare rigore. Numeri di nodo duplicati, velocità di trasmissione errate, terminazione mancante, cavo trunk danneggiato o un canale DHRIO configurato in modo non corretto possono creare sintomi intermittenti che sembrano un difetto dell’HMI. Acquisisci la mappa dei nodi funzionante e la topologia fisica prima di modificare qualsiasi cosa. Per EtherNet/IP, monitora l’utilizzo delle connessioni e la velocità dei pacchetti invece di presumere che si applichi il modello di una rete aziendale poco caricata.

Progetta l’uscita dalla migrazione

Un bridge è spesso un componente temporaneo, ma i sistemi temporanei possono restare in servizio per anni. Documenta alimentazione, cavi, firmware, backup delle configurazioni, strategia per i ricambi e responsabile di ogni scorciatoia. Mantieni stabile il contratto dati dello SLC durante la messa in servizio della nuova logica, quindi dismetti i percorsi legacy in fasi controllate. La pianificazione delle sostituzioni deve essere collegata all’inventario dei sistemi PLC e PAC del punto vendita e al piano del ciclo di vita dei suoi display HMI.

L’obiettivo ingegneristico non è semplicemente fare in modo che i tag siano esplorabili. È creare una progettazione della comunicazione i cui guasti siano visibili, circoscritti e ripristinabili. Identità separate dei controller, percorsi di runtime espliciti, traffico misurato e comportamento di perdita della comunicazione verificato forniscono questa base.