Un laptop collegato allo stesso switch gestito di un encoder Allen-Bradley 842E non rileverà automaticamente il traffico ciclico dell’encoder. Normalmente, uno switch inoltra i frame unicast solo verso la porta di destinazione. Pertanto, l’analizzatore può mostrare quasi nulla mentre il controller segnala un timeout I/O.

Una cattura utile inizia con un’ipotesi di guasto verificabile e un punto di cattura in grado di osservare i frame pertinenti.

Definire la domanda prima di raccogliere i pacchetti

Descrivi il sintomo in termini misurabili. Gli esempi includono un timeout della connessione durante una particolare transizione della macchina, un valore dell’encoder che smette di cambiare, riconnessioni ripetute o dati di posizione che arrivano più tardi del previsto al controller. Registra il codice di errore del controller, l’ora, gli indicatori dell’encoder e lo stato della porta dello switch.

Decidi quali evidenze confermerebbero o smentirebbero ciascuna ipotesi. Se la domanda è se i frame escono dall’encoder, esegui il mirroring della porta collegata all’encoder. Se invece vuoi verificare se raggiungono l’uplink del controller, osserva quel collegamento. La cattura di un solo lato di uno switch intermedio non consente sempre di localizzare la perdita.

L’hardware degli encoder è disponibile nella collezione Sensori, mentre gli switch gestiti e gli adattatori di rete sono raggruppati in Comunicazione e networking.

Comprendere il percorso di rete dell’842E

Rockwell Automation descrive l’842E come una famiglia di encoder assoluti EtherNet/IP con doppie porte Ethernet per topologie lineari e Device Level Ring supportate. Il catalogo e la configurazione del progetto specifici determinano la connessione dati, l’assembly, l’intervallo dei pacchetti richiesto e il comportamento diagnostico.

Documenta entrambe le porte fisiche, le impostazioni IP, la connessione al controller, la topologia, il firmware e l’eventuale attivazione del Device Level Ring. In una topologia lineare, un cavo o un dispositivo a valle può influire sul traffico che attraversa l’encoder. In una rete ad anello, un evento topologico aggiunge evidenze che devono essere correlate al guasto della connessione.

Non presumere che la porta più vicina al controller sia sempre l’unico punto di cattura utile. Disegna il percorso effettivo, incluse le porte dello switch, gli uplink, il supervisore dell’anello, i convertitori di supporto trasmissivo e gli eventuali percorsi ridondanti.

Selezionare un metodo di cattura non intrusivo

Una sessione di mirroring su uno switch gestito è generalmente il metodo meno invasivo. Configura come sorgente la porta dell’encoder, la porta del controller o l’uplink richiesto dall’ipotesi. Imposta come destinazione la porta collegata all’analizzatore e verifica se lo switch esegue il mirroring del traffico in ingresso, in uscita o in entrambe le direzioni.

Un tap di rete passivo progettato allo scopo è un’altra opzione, quando l’architettura e la procedura di fermo lo consentono. Non inserire uno switch non gestito o un normale hub da ufficio in un percorso di controllo in funzione. Questa modifica può alterare la topologia, la qualità del servizio, la gestione del multicast, la negoziazione del collegamento e la temporizzazione del guasto.

Usa un’interfaccia dedicata per l’analizzatore. Disabilita i protocolli e i servizi non necessari, quando la procedura operativa lo consente. L’analizzatore deve osservare, non annunciare dispositivi, richiedere indirizzi o diventare un altro partecipante della rete di controllo.

Verificare che il mirroring sia affidabile

Genera o identifica un frame noto e verifica che appaia sull’analizzatore. Controlla che entrambe le direzioni siano visibili quando necessario. Una sessione di mirroring può omettere gli errori del livello fisico, perdere pacchetti quando la porta di destinazione è sovraccarica o copiare una sola direzione.

Confronta la velocità della porta sorgente con la capacità della destinazione del mirroring. Eseguire il mirroring in entrambe le direzioni di un uplink gigabit molto trafficato verso una porta da un gigabit può superare la larghezza di banda della destinazione. Restringi la sorgente o la finestra di cattura invece di presumere che ogni intervallo sia avvenuto sulla rete di controllo.

Registra il modello dello switch, il firmware, la configurazione del mirroring, la porta sorgente, la porta di destinazione, il comportamento VLAN e le impostazioni dell’interfaccia di cattura. Senza questa registrazione, un altro tecnico non potrà riprodurre la misurazione.

Distinguere le classi di traffico EtherNet/IP

EtherNet/IP usa messaggi espliciti per la gestione delle connessioni, la configurazione e la diagnostica, mentre l’I/O ciclico utilizza comunemente il trasporto UDP. Gli scambi di rilevamento non dimostrano che una connessione I/O stabilita sia sana. Conserva nella cattura la configurazione e la chiusura della connessione attorno al guasto, non solo i pacchetti ciclici.

Inizia dagli indirizzi IP noti dell’encoder e del controller. Poi identifica la connessione pertinente invece di classificare ogni frame UDP come dato dell’encoder. Le porte EtherNet/IP comuni possono aiutare a restringere la traccia, ma endpoint, temporizzazione e contesto della connessione forniscono evidenze più solide.

Conserva le evidenze ARP, topologiche e di gestione dello switch relative all’evento. Un conflitto di indirizzi o una transizione del collegamento può apparire al di fuori del flusso I/O filtrato. Salva la cattura non filtrata e usa i filtri di visualizzazione per l’analisi, così il contesto non verrà scartato definitivamente.

Analizzare la temporizzazione e le lacune dell’RPI

L’intervallo di pacchetti richiesto definisce la frequenza di aggiornamento prevista per la connessione I/O configurata. Misura il tempo tra gli arrivi durante un periodo normale e intorno al guasto. Cerca intervalli mancanti, raffiche successive a una pausa, comportamenti di sequenza duplicati e una chiusura o riapertura della connessione.

Non considerare ogni pacchetto che arriva dopo l’RPI nominale come un guasto del controller. Confronta l’intervallo osservato con il comportamento di timeout della connessione configurato nel controller. Una variazione di pochi microsecondi e un’interruzione di più intervalli hanno significati diversi.

Rappresenta su un grafico il tempo di arrivo dei pacchetti insieme al bit di errore del controller, allo stato del task, all’evento della macchina e ai log dello switch. Se il flusso di pacchetti si interrompe prima che compaia un evento di perdita del collegamento, occorre prestare attenzione al dispositivo sorgente o al percorso a monte. Se il mirroring continua a rilevare frame dell’encoder mentre il controller va in timeout, esamina il percorso rimanente e l’elaborazione del controller.

Usare le evidenze dello switch insieme alla traccia

Leggi i contatori delle porte prima e dopo il test. Errori CRC o di controllo dei frame, transizioni del collegamento, pacchetti scartati, variazioni di velocità ed eventi dell’anello possono spiegare un’interruzione dei pacchetti. Un analizzatore collegato oltre il collegamento guasto potrebbe non ricevere mai i frame corrotti, perché lo switch li scarta.

Controlla le condizioni di cavi e connettori, le pratiche di schermatura e messa a terra, il raggio di curvatura, la contaminazione e la trazione. Sostituisci un solo componente controllato alla volta, dopo aver conservato la baseline. Sostituire contemporaneamente più cavi e impostazioni dello switch impedisce di identificare la causa.

Conferma la velocità e il duplex negoziati in base alla configurazione supportata dal dispositivo. Evita di forzare le impostazioni senza consultare i manuali dell’encoder e dello switch. Un’incompatibilità può generare errori che sembrano dipendere dal carico.

Proteggere la cattura e la rete

Limita la durata della cattura o usa un buffer circolare per evitare che il disco dell’analizzatore si riempia. Indica l’ora locale e quella dell’impianto con precisione. Le tracce dei pacchetti possono rivelare indirizzi, nomi dei dispositivi, configurazioni e comportamento del processo; conservale applicando controlli di accesso appropriati.

Rimuovi la configurazione del mirroring al termine del test e verifica che la porta di destinazione ritorni allo stato previsto. Un mirroring lasciato attivo può esporre il traffico di controllo a un dispositivo non autorizzato o consumare risorse dello switch.

Non apportare modifiche di configurazione basandoti esclusivamente su una traccia dei pacchetti. Correla le evidenze con la diagnostica del controller, gli indicatori dell’encoder, i contatori dello switch e un evento ripetibile della macchina. La cattura registra il traffico; non certifica la posizione meccanica né dimostra che l’encoder sia accurato.

Trasformare le osservazioni in una conclusione sul guasto

I frame si interrompono in entrambi i punti di cattura

Esamina l’alimentazione dell’encoder, lo stato interno, la connessione al programma a monte o il collegamento comune prima del primo punto di cattura. Verifica se il dispositivo si riavvia o se la connessione viene inibita deliberatamente.

I frame appaiono sull’encoder ma non sull’uplink

Concentrati sul percorso dello switch intermedio, sulla VLAN, sugli eventi dell’anello, sugli errori della porta, sulla congestione o sul cablaggio. Ripeti il test con contatori sincronizzati prima di sostituire l’encoder.

I frame raggiungono il percorso del controller, ma il PLC va in timeout

Esamina la connessione configurata, l’RPI, il timeout, il carico dei task del controller, gli indirizzi duplicati e verifica che i pacchetti catturati appartengano alla connessione prevista.

La cattura dei pacchetti diventa preziosa quando il posizionamento, la temporizzazione e il contesto di rete della cattura sono controllati. L’obiettivo non è ottenere un file Wireshark di grandi dimensioni, ma una quantità ridotta di evidenze che mostri dove è cambiato lo scambio ciclico e quale evento fisico o di configurazione è cambiato insieme ad esso.