Kinetix 5500 EtherNet/IP Network Switch Requirements and Topology — figure 1

Requisitos e topologia de switches de rede EtherNet/IP do Kinetix 5500

Configure servodrives Allen-Bradley Kinetix 5500 no EtherNet/IP. Abrange CIP Sync, sincronização IEEE 1588 V2, seleção de Stratix, topologia DLR e IHM.

Os eixos servo revelam rapidamente os atalhos da rede. Integrar um Kinetix 5500 (2198-xxxx-ERS3) a uma sub-rede que já transporta E/S do ControlLogix, adaptadores de segurança, tráfego do PanelView e VFDs levanta uma questão prática: um Stratix gerenciável é obrigatório e qual topologia mantém o CIP Sync dentro do orçamento? A resposta depende do Requested Packet Interval, da sincronização de tempo IEEE 1588 V2 e do jitter — não de o drive “responder a pings”.

Requisitos e topologia de switches de rede EtherNet/IP do Kinetix 5500 — figura 1

O CIP Motion não tolera jitter de tempo de permanência causado por switches não gerenciáveis, mesmo quando as conexões unicast parecem saudáveis no Studio 5000.

Requisitos do CIP Motion / CIP Sync

Parâmetro Necessidade típica do Kinetix 5500
Período de atualização 1 ms (firmware ERS3 6.xxx+); famílias mais antigas podem exigir 2 ms
Sincronização de tempo CIP Sync (IEEE 1588 V2), grandmaster + relógios transparentes
Orçamento de jitter Classe de menos de um microssegundo de ponta a ponta através da cadeia de TCs
Classe de conexão Classe 1; o Studio 5000 v28+ geralmente usa unicast por padrão para o 5500
Topologia Estrela, linear ou DLR — não faça cascatas improvisadas de switches de uso doméstico

Se algum switch no caminho não atuar como relógio transparente (ou pelo menos limitar o tempo de permanência do PTP), o drive rejeitará a sincronização, e a falha parecerá um problema do servo.

Lista de verificação de recursos do switch

  • Relógio transparente IEEE 1588 V2 com especificações rigorosas de tempo de permanência
  • QoS de hardware com prioridade estrita para DSCP crítico em termos de tempo (marcações de EtherNet/IP e PTP)
  • Snooping IGMPv2/v3 quando o multicast continuar em uso
  • Comportamento CIP validado pela ODVA / Rockwell sempre que possível (famílias Stratix 5700/5400/5410)

Switches não gerenciáveis encaminham quadros PTP sem corrigir o tempo de permanência; o jitter de múltiplos saltos pode chegar a centenas de microssegundos — fora do orçamento de movimento de 1 ms. Switches gerenciáveis de terceiros podem funcionar se o PTP TC e a QoS forem configurados corretamente, mas o risco fica sob sua responsabilidade e você perde os diagnósticos nativos do Stratix na árvore de E/S.

Topologia com poucos eixos: DLR direto a partir do EN2TR

Para um ou dois eixos, um padrão comprovado é a segregação física em vez de comprar um switch de movimento logo no primeiro dia:

Porta 1 do EN2TR -> switch da planta (HMI, E/S, VFD)
Porta 2 do EN2TR -> Porta 1 do Kinetix 5500 (DLR de 2 nós)
Drive: Topologia de rede = DLR, nó (não supervisor)
Período de atualização do eixo = 1 ms (corresponder ao RPI)

O Motion CIP Unicast nesse segmento de dois nós elimina a carga do IGMP do caminho de movimento. O comprimento do cabo ainda deve respeitar os limites do cobre; a circunferência do anel será a soma dos dois segmentos quando você expandir posteriormente a cadeia DLR.

Requisitos de Switch e Topologia de Rede EtherNet/IP do Kinetix 5500 — figura 2

Os domínios de broadcast da HMI são o inimigo silencioso dos fluxos de Motion de 1 ms em sub-redes compartilhadas.

Opções de segregação da HMI

Opção Quando se aplica
Drive direto na Porta 2 do EN2TR 1–2 eixos; nenhum custo adicional de switch
Segundo módulo ENxT Grande carga de HMI ou crescimento planejado do número de eixos
Substituição da infraestrutura não gerenciada por Stratix Muitos eixos; segurança/E/S/HMI mistas em um único domínio L2

Período de Atualização versus RPI

Em um eixo Kinetix 5500, o Período de Atualização (propriedades de Motion) e o RPI (propriedades da conexão) são parâmetros relacionados, mas não idênticos. Defina ambos como 1 ms para o firmware ERS3 que ofereça suporte a esse valor e mantenha-os compatibilizados. Uma incompatibilidade é uma causa frequente de “Conexão não estabelecida” durante o comissionamento. As taxas de anúncio PTP no ENxT devem permanecer nos valores recomendados pela Rockwell, a menos que um documento de arquitetura validado indique o contrário.

À medida que a quantidade de eixos ultrapassa aproximadamente oito a dez drives em uma infraestrutura compartilhada não gerenciada, o jitter cumulativo geralmente exige uma atualização para uma classe Stratix, mesmo que as conexões unicast tenham parecido aceitáveis com um ou dois eixos. Planeje esse ponto de inflexão durante o primeiro retrofit, em vez de esperar até a terceira falha de sincronização inexplicada.

Verificações de comissionamento

  1. Confirme se o grandmaster é o ENxT pretendido; leia o estado do PTP no Stratix, se presente
  2. Compatibilize o Período de Atualização e o RPI; incompatibilidades geram falhas de conexão
  3. Verifique as listas de NS/conexões comparando-as com os contadores do switch quando houver divergência
  4. Teste intensivamente a navegação da HMI enquanto os eixos estiverem em movimento — observe a ocorrência de falhas de sincronização
  5. Documente os diagramas de topologia; switches de escritório “temporários” tornam-se uma dívida permanente
  6. Registre uma linha de base do erro de seguimento do eixo antes e depois do estresse da HMI

A reserva de hardware de Motion e Logix deve seguir as mesmas regras de PLC/PAC aplicadas aos controladores discretos, para que uma falha no EN2TR não deixe uma célula de produção parada.

Sobre o autor

Mark Townsend | Engenheiro Sênior de Automação – Sistemas Allen-Bradley

Mark Townsend é engenheiro sênior de automação, com mais de 18 anos de experiência em plataformas Allen-Bradley, abrangendo ControlLogix, CompactLogix e o legado SLC-500. Seu trabalho diário envolve lógica no RSLogix / Studio 5000 e a inicialização de IHMs no FactoryTalk View em frotas antigas e heterogêneas.

Requisitos e topologia de switches de rede EtherNet/IP do Kinetix 5500

Configure servodrives Allen-Bradley Kinetix 5500 no EtherNet/IP. Abrange CIP Sync, sincronização IEEE 1588 V2, seleção de Stratix, topologia DLR e IHM.

Os eixos servo revelam rapidamente os atalhos da rede. Integrar um Kinetix 5500 (2198-xxxx-ERS3) a uma sub-rede que já transporta E/S do ControlLogix, adaptadores de segurança, tráfego do PanelView e VFDs levanta uma questão prática: um Stratix gerenciável é obrigatório e qual topologia mantém o CIP Sync dentro do orçamento? A resposta depende do Requested Packet Interval, da sincronização de tempo IEEE 1588 V2 e do jitter — não de o drive “responder a pings”.

Requisitos e topologia de switches de rede EtherNet/IP do Kinetix 5500 — figura 1

O CIP Motion não tolera jitter de tempo de permanência causado por switches não gerenciáveis, mesmo quando as conexões unicast parecem saudáveis no Studio 5000.

Requisitos do CIP Motion / CIP Sync

Parâmetro Necessidade típica do Kinetix 5500
Período de atualização 1 ms (firmware ERS3 6.xxx+); famílias mais antigas podem exigir 2 ms
Sincronização de tempo CIP Sync (IEEE 1588 V2), grandmaster + relógios transparentes
Orçamento de jitter Classe de menos de um microssegundo de ponta a ponta através da cadeia de TCs
Classe de conexão Classe 1; o Studio 5000 v28+ geralmente usa unicast por padrão para o 5500
Topologia Estrela, linear ou DLR — não faça cascatas improvisadas de switches de uso doméstico

Se algum switch no caminho não atuar como relógio transparente (ou pelo menos limitar o tempo de permanência do PTP), o drive rejeitará a sincronização, e a falha parecerá um problema do servo.

Lista de verificação de recursos do switch

  • Relógio transparente IEEE 1588 V2 com especificações rigorosas de tempo de permanência
  • QoS de hardware com prioridade estrita para DSCP crítico em termos de tempo (marcações de EtherNet/IP e PTP)
  • Snooping IGMPv2/v3 quando o multicast continuar em uso
  • Comportamento CIP validado pela ODVA / Rockwell sempre que possível (famílias Stratix 5700/5400/5410)

Switches não gerenciáveis encaminham quadros PTP sem corrigir o tempo de permanência; o jitter de múltiplos saltos pode chegar a centenas de microssegundos — fora do orçamento de movimento de 1 ms. Switches gerenciáveis de terceiros podem funcionar se o PTP TC e a QoS forem configurados corretamente, mas o risco fica sob sua responsabilidade e você perde os diagnósticos nativos do Stratix na árvore de E/S.

Topologia com poucos eixos: DLR direto a partir do EN2TR

Para um ou dois eixos, um padrão comprovado é a segregação física em vez de comprar um switch de movimento logo no primeiro dia:

Porta 1 do EN2TR -> switch da planta (HMI, E/S, VFD)
Porta 2 do EN2TR -> Porta 1 do Kinetix 5500 (DLR de 2 nós)
Drive: Topologia de rede = DLR, nó (não supervisor)
Período de atualização do eixo = 1 ms (corresponder ao RPI)

O Motion CIP Unicast nesse segmento de dois nós elimina a carga do IGMP do caminho de movimento. O comprimento do cabo ainda deve respeitar os limites do cobre; a circunferência do anel será a soma dos dois segmentos quando você expandir posteriormente a cadeia DLR.

Requisitos de Switch e Topologia de Rede EtherNet/IP do Kinetix 5500 — figura 2

Os domínios de broadcast da HMI são o inimigo silencioso dos fluxos de Motion de 1 ms em sub-redes compartilhadas.

Opções de segregação da HMI

Opção Quando se aplica
Drive direto na Porta 2 do EN2TR 1–2 eixos; nenhum custo adicional de switch
Segundo módulo ENxT Grande carga de HMI ou crescimento planejado do número de eixos
Substituição da infraestrutura não gerenciada por Stratix Muitos eixos; segurança/E/S/HMI mistas em um único domínio L2

Período de Atualização versus RPI

Em um eixo Kinetix 5500, o Período de Atualização (propriedades de Motion) e o RPI (propriedades da conexão) são parâmetros relacionados, mas não idênticos. Defina ambos como 1 ms para o firmware ERS3 que ofereça suporte a esse valor e mantenha-os compatibilizados. Uma incompatibilidade é uma causa frequente de “Conexão não estabelecida” durante o comissionamento. As taxas de anúncio PTP no ENxT devem permanecer nos valores recomendados pela Rockwell, a menos que um documento de arquitetura validado indique o contrário.

À medida que a quantidade de eixos ultrapassa aproximadamente oito a dez drives em uma infraestrutura compartilhada não gerenciada, o jitter cumulativo geralmente exige uma atualização para uma classe Stratix, mesmo que as conexões unicast tenham parecido aceitáveis com um ou dois eixos. Planeje esse ponto de inflexão durante o primeiro retrofit, em vez de esperar até a terceira falha de sincronização inexplicada.

Verificações de comissionamento

  1. Confirme se o grandmaster é o ENxT pretendido; leia o estado do PTP no Stratix, se presente
  2. Compatibilize o Período de Atualização e o RPI; incompatibilidades geram falhas de conexão
  3. Verifique as listas de NS/conexões comparando-as com os contadores do switch quando houver divergência
  4. Teste intensivamente a navegação da HMI enquanto os eixos estiverem em movimento — observe a ocorrência de falhas de sincronização
  5. Documente os diagramas de topologia; switches de escritório “temporários” tornam-se uma dívida permanente
  6. Registre uma linha de base do erro de seguimento do eixo antes e depois do estresse da HMI

A reserva de hardware de Motion e Logix deve seguir as mesmas regras de PLC/PAC aplicadas aos controladores discretos, para que uma falha no EN2TR não deixe uma célula de produção parada.

Sobre o autor

Mark Townsend | Engenheiro Sênior de Automação – Sistemas Allen-Bradley

Mark Townsend é engenheiro sênior de automação, com mais de 18 anos de experiência em plataformas Allen-Bradley, abrangendo ControlLogix, CompactLogix e o legado SLC-500. Seu trabalho diário envolve lógica no RSLogix / Studio 5000 e a inicialização de IHMs no FactoryTalk View em frotas antigas e heterogêneas.

Deixe um comentário

Por favor, note que os comentários precisam ser aprovados antes de serem publicados.