Capturando tráfego EtherNet/IP de um Allen-Bradley 842E

Um laptop conectado ao mesmo switch gerenciável que um encoder Allen-Bradley 842E não verá automaticamente o tráfego cíclico do encoder. Normalmente, um switch encaminha quadros unicast apenas para a porta de destino. Por isso, o analisador pode mostrar quase nada enquanto o controlador relata um timeout de E/S.

Uma captura útil começa com uma hipótese de falha testável e um ponto de captura capaz de observar os quadros relevantes.

Defina a pergunta antes de coletar pacotes

Descreva o sintoma em termos mensuráveis. Os exemplos incluem um timeout de conexão durante uma transição específica da máquina, um valor do encoder que para de mudar, reconexões repetidas ou dados de posição que chegam mais tarde do que o esperado pelo controlador. Registre o código de falha do controlador, o horário, os indicadores do encoder e o estado da porta do switch.

Decida quais evidências sustentariam ou rejeitariam cada hipótese. Se a pergunta for se os quadros saem do encoder, espelhe a porta conectada ao encoder. Se for se eles chegam ao uplink do controlador, observe esse enlace. Capturar apenas um lado de um switch intermediário nem sempre permite localizar a perda.

Os encoders podem ser consultados na coleção de Sensores, enquanto switches gerenciáveis e adaptadores de rede estão agrupados em Comunicação e Redes.

Entenda o caminho de rede do 842E

A Rockwell Automation documenta o 842E como uma família de encoders absolutos EtherNet/IP com duas portas Ethernet para topologias lineares e Device Level Ring compatíveis. O catálogo exato e a configuração do projeto determinam a conexão de dados, a montagem, o intervalo de pacotes solicitado e o comportamento de diagnóstico.

Documente as duas portas físicas, as configurações de IP, a conexão com o controlador, a topologia, o firmware e se o Device Level Ring está ativo. Em uma topologia linear, um cabo ou dispositivo a jusante pode afetar o tráfego através do encoder. Em um anel, um evento de topologia acrescenta evidências que devem ser correlacionadas com a falha de conexão.

Não presuma que a porta mais próxima do controlador seja sempre o único ponto de captura útil. Desenhe o caminho real, incluindo portas de switch, uplinks, supervisor do anel, conversores de mídia e quaisquer rotas redundantes.

Selecione um método de captura não intrusivo

Uma sessão de espelhamento de porta em um switch gerenciável normalmente é o método menos disruptivo. Configure a origem como a porta do encoder, a porta do controlador ou o uplink necessário para a hipótese. Defina a porta conectada ao analisador como destino e confirme se o switch espelha o tráfego de entrada, de saída ou ambos.

Um tap de rede passivo desenvolvido especificamente para essa finalidade é outra opção quando a arquitetura e o procedimento de parada permitirem. Não insira um switch não gerenciável ou um hub comum de escritório em um caminho de controle em operação. Essa alteração pode modificar a topologia, a qualidade de serviço, o tratamento de multicast, a negociação do enlace e o momento da falha.

Use uma interface dedicada para o analisador. Desabilite protocolos e serviços desnecessários quando o procedimento operacional permitir. O analisador deve observar, não anunciar dispositivos, solicitar endereços nem se tornar outro participante da rede de controle.

Verifique se o espelhamento está informando a verdade

Gere ou identifique um quadro conhecido e confirme que ele aparece no analisador. Verifique se ambas as direções estão visíveis quando necessário. Uma sessão de espelhamento pode omitir erros da camada física, descartar pacotes quando a porta de destino está sobrecarregada ou copiar apenas uma direção.

Compare a velocidade da porta de origem com a capacidade do destino do espelhamento. Espelhar ambas as direções de um uplink gigabit ocupado para uma porta de um gigabit pode exceder a largura de banda do destino. Restrinja a origem ou a janela de captura em vez de presumir que toda lacuna ocorreu na rede de controle.

Registre o modelo do switch, o firmware, a configuração de espelhamento, a porta de origem, a porta de destino, o comportamento da VLAN e as configurações da interface de captura. Sem esse registro, outro engenheiro não poderá reproduzir a medição.

Separe as classes de tráfego EtherNet/IP

O EtherNet/IP usa mensagens explícitas para gerenciamento de conexões, configuração e diagnósticos, enquanto a E/S cíclica normalmente usa transporte UDP. Trocas de descoberta não comprovam que uma conexão de E/S estabelecida esteja saudável. Preserve a configuração e o encerramento da conexão ao redor da falha, não apenas os pacotes cíclicos.

Comece pelos endereços IP conhecidos do encoder e do controlador. Em seguida, identifique a conexão relevante em vez de classificar todo quadro UDP como dado do encoder. As portas comuns do EtherNet/IP podem ajudar a restringir o rastreamento, mas os endpoints, o tempo e o contexto da conexão fornecem evidências mais fortes.

Mantenha as evidências de ARP, topologia e gerenciamento do switch ao redor do evento. Um conflito de endereço ou uma transição de enlace pode aparecer fora do fluxo de E/S filtrado. Salve a captura sem filtros e use filtros de exibição para a análise, para que o contexto não seja descartado permanentemente.

Analise o tempo do RPI e as lacunas

O intervalo de pacotes solicitado define a cadência de atualização esperada para a conexão de E/S configurada. Meça o tempo entre chegadas durante um período saudável e ao redor da falha. Procure intervalos ausentes, rajadas após uma pausa, comportamento de sequência duplicada e um encerramento ou reabertura da conexão.

Não trate todo pacote posterior ao RPI nominal como uma falha do controlador. Compare a lacuna observada com o comportamento de timeout da conexão configurado no controlador. Uma variação de alguns microssegundos e uma interrupção de vários intervalos têm significados diferentes.

Faça um gráfico do horário de chegada dos pacotes junto com o bit de falha do controlador, o estado da tarefa, o evento da máquina e os logs do switch. Se o fluxo de pacotes parar antes que apareça um evento de enlace desativado, o dispositivo de origem ou o caminho a montante merece atenção. Se o espelhamento continuar vendo quadros do encoder enquanto o controlador entra em timeout, investigue o restante do caminho e o processamento do controlador.

Use as evidências do switch com o rastreamento

Leia os contadores das portas antes e depois do teste. Erros de CRC ou de verificação de quadros, transições de enlace, pacotes descartados, alterações de velocidade e eventos do anel podem explicar uma lacuna de pacotes. Um analisador conectado acima do enlace com falha talvez nunca receba quadros corrompidos, pois o switch os descarta.

Verifique as condições dos cabos e conectores, as práticas de blindagem e aterramento, o raio de curvatura, a contaminação e a tração. Troque apenas um componente controlado depois de preservar a linha de base. Substituir vários cabos e configurações do switch ao mesmo tempo elimina a possibilidade de identificar a causa.

Confirme a velocidade e o duplex negociados de acordo com a configuração compatível do dispositivo. Evite forçar configurações sem consultar os manuais do encoder e do switch. Uma incompatibilidade pode gerar erros que parecem depender da carga.

Proteja a captura e a rede

Limite a duração da captura ou use um buffer circular para evitar que o disco do analisador fique cheio. Registre o horário local e o horário da planta com precisão. Os rastreamentos de pacotes podem revelar endereços, nomes de dispositivos, configurações e comportamento do processo; portanto, armazene-os sob controles de acesso apropriados.

Remova a configuração de espelhamento após o teste e verifique se a porta de destino voltou ao estado pretendido. Um espelhamento abandonado pode expor tráfego de controle a um dispositivo não autorizado ou consumir recursos do switch.

Nunca faça alterações de configuração com base apenas em um rastreamento de pacotes. Correlacione as evidências com os diagnósticos do controlador, os indicadores do encoder, os contadores do switch e um evento reproduzível da máquina. A captura registra o tráfego; ela não certifica a posição mecânica nem comprova que o encoder seja preciso.

Transforme as observações em uma conclusão sobre a falha

Os quadros param nos dois pontos de captura

Investigue a alimentação do encoder, o estado interno, a conexão do programa a montante ou o enlace comum antes do primeiro ponto de captura. Verifique se o dispositivo reinicia ou se a conexão está sendo inibida deliberadamente.

Os quadros aparecem no encoder, mas não no uplink

Concentre-se no caminho do switch intermediário, na VLAN, em eventos do anel, em erros da porta, no congestionamento ou no cabeamento. Repita o teste com contadores sincronizados antes de trocar o encoder.

Os quadros chegam ao caminho do controlador, mas o PLC entra em timeout

Revise a conexão configurada, o RPI, o timeout, a carga das tarefas do controlador, o endereçamento duplicado e se os pacotes capturados pertencem à conexão esperada.

A captura de pacotes se torna valiosa quando o posicionamento da captura, o tempo e o contexto da rede são controlados. O objetivo não é gerar um arquivo grande do Wireshark. É obter um pequeno conjunto de evidências que mostre onde a troca cíclica mudou e qual evento físico ou de configuração mudou junto com ela.