Planejamento de capacidade do CompactLogix L35E EtherNet/IP
Planeje a capacidade do CompactLogix L35E EtherNet/IP com base no tráfego CIP configurado, nos diagnósticos em tempo real, nas taxas de atualização e nos riscos do ciclo de vida — sem depender de l...
O CompactLogix 1769-L35E continua sendo comum em máquinas que ultrapassaram a vida útil de seu plano de rede original. Os problemas de expansão geralmente começam quando uma lista de dispositivos é tratada como uma contagem de conexões. A capacidade do EtherNet/IP depende do tipo de tráfego que cada dispositivo gera, da frequência com que troca dados e dos recursos do controlador que a aplicação já utiliza. Portanto, uma análise segura começa pelo projeto em execução e pelos diagnósticos, não por uma regra genérica de dispositivos por porta.
O planejamento de conexões deve considerar o tráfego configurado, as taxas de atualização e os riscos do ciclo de vida, e não a quantidade de conectores Ethernet.
Comece pelo limite documentado do controlador
O Manual do usuário dos controladores 1769 CompactLogix da Rockwell Automation documenta o L35E como compatível com 100 conexões CIP. Esse é um limite de recursos, não uma autorização para conectar 100 dispositivos. Um único dispositivo pode exigir mais de uma conexão, enquanto algumas comunicações podem compartilhar uma conexão otimizada. A revisão do firmware, a configuração dos módulos, as tags produzidas e consumidas, as mensagens em cache e todos os clientes de HMI ou supervisão afetam o total final.
O controlador também é um produto descontinuado. A Rockwell informa que o 1769-L35E foi descontinuado em 20 de dezembro de 2020. Isso não torna um sistema em funcionamento inutilizável, mas muda a decisão de engenharia: um problema de capacidade deve ser avaliado juntamente com a disponibilidade de peças sobressalentes, o suporte ao firmware, a exposição à cibersegurança e o custo de uma falha não planejada.
Crie um inventário de conexões a partir do projeto
Abra o projeto off-line que corresponde ao controlador em execução e liste cada adaptador de E/S, inversor, tag produzida ou consumida, caminho de mensagem, servidor de dados da HMI, historiador, gateway e conexão de programação configurados. Registre se cada troca é uma E/S cíclica, dados produzidos, uma mensagem explícita ou uma consulta de cliente. Não atribua uma quantidade fixa de conexões com base apenas no nome do fabricante. A configuração real é a referência.
Para E/S distribuídas, verifique se o formato de comunicação selecionado cria conexões diretas com os módulos ou uma conexão otimizada do rack. Para instruções MSG, identifique quais estão em cache e se várias mensagens podem ficar ativas ao mesmo tempo. Para sistemas de supervisão, conte os caminhos de comunicação independentes e analise a estratégia de consulta. Uma planilha deve vincular cada conexão presumida a um objeto do projeto ou a uma configuração de cliente testada.
Separe a contagem de conexões da carga de pacotes
Um controlador pode permanecer abaixo do limite de conexões e ainda assim apresentar desempenho de rede insatisfatório. Os intervalos solicitados entre pacotes, a frequência das mensagens, o tamanho dos pacotes, o comportamento multicast, a configuração do switch e os picos de vários clientes influenciam a carga de pacotes. RPIs muito rápidos devem ser justificados pelo processo mecânico e pela resposta de controle necessária; tornar todos os dispositivos mais rápidos não melhora a máquina.
Estabeleça uma linha de base enquanto a máquina estiver produzindo normalmente. Registre o uso de conexões, os contadores de erros Ethernet, as mensagens perdidas ou expiradas, o status das E/S, a capacidade de resposta da HMI e o comportamento da varredura do controlador. Repita a captura durante a inicialização, downloads de receitas, picos de alarmes, acesso de manutenção e outros picos plausíveis. As médias podem ocultar o curto intervalo que causa uma falha intermitente.
Switches gerenciáveis, uma topologia documentada e medições repetíveis tornam as falhas intermitentes de capacidade diagnosticáveis.
Não use um 1769-AENTR como uma segunda porta do L35E
Um 1769-AENTR é um adaptador EtherNet/IP para um conjunto remoto de E/S Compact controlado pela rede. Ele não é uma interface Ethernet de expansão que aumenta o conjunto de comunicações do controlador L35E, nem pode ser conectado como uma segunda porta do controlador para transferir o tráfego da HMI ou de mensagens para longe da interface integrada. Projetar com base nessa suposição cria uma topologia incapaz de executar a função alegada.
Se as E/S remotas forem apropriadas, um adaptador poderá concentrar E/S físicas em outro local, mas a conexão de E/S resultante ainda terminará no controlador. Se a aplicação exigir maior capacidade de comunicação, funções de segurança modernas ou suporte por um ciclo de vida mais longo, a solução poderá ser migrar para uma família de controladores mais nova, em vez de adicionar outro adaptador.
Reduza a carga evitável sem ocultar o problema
A otimização deve preservar os requisitos do processo. Remova caminhos abandonados e clientes não utilizados. Consolide as conexões de E/S quando a plataforma e os tipos de módulos permitirem. Coloque em cache apenas as conexões MSG que precisem de execução rápida e repetida, e sequencie as mensagens não críticas para que não sejam abertas todas ao mesmo tempo. Aumente um RPI ou o intervalo de consulta somente depois de confirmar que o tempo de detecção, os intertravamentos, os alarmes e a qualidade do controle continuam aceitáveis.
Use switches industriais gerenciáveis e documente as configurações de VLAN, multicast e IGMP quando aplicável. Um switch pode controlar inundações desnecessárias e melhorar a observabilidade, mas não pode criar recursos de conexão no controlador. Da mesma forma, adicionar um switch não gerenciável altera a quantidade de portas, não a capacidade do controlador.
Diagnostique metodicamente uma suspeita de falha de capacidade
Primeiro, confirme o projeto em execução, o número de catálogo do controlador, a revisão do firmware e a topologia da rede. Em seguida, compare as conexões configuradas com os diagnósticos ativos. Procure módulos de E/S que alternem entre os estados de execução e falha, instruções MSG que expirem sob carga máxima ou valores da HMI que fiquem desatualizados enquanto a lógica do controlador continua sendo executada.
Altere uma variável por vez. Desconecte um cliente não essencial aprovado, suspenda um serviço de consulta não crítico ou sequencie temporariamente as mensagens durante uma janela de manutenção controlada. Se o sintoma mudar, meça a carga antes e depois, em vez de declarar sucesso com base em apenas uma hora tranquila. Nunca aumente excessivamente os tempos limite nem suprima os alarmes de comunicação apenas para ocultar o congestionamento.
Coloque as expansões em operação com testes de falha
Antes de adicionar um dispositivo, defina o tipo de conexão, o requisito de atualização, o responsável e a resposta à falha. Teste a produção normal e a pior demanda simultânea plausível. Interrompa o novo dispositivo, restaure-o, desligue e religue sua alimentação de rede e confirme que o controlador, a HMI e os alarmes distinguem dados inválidos ou desatualizados de um estado de processo válido. Verifique se a recuperação não reinicia o equipamento inesperadamente.
Mantenha o inventário, os instantâneos de diagnóstico, a configuração do switch e os resultados de aceitação junto ao backup dos controles. Para opções atuais de hardware, consulte sistemas PLC e PAC; para switches gerenciáveis e componentes de rede, use a coleção de comunicação e redes. A conclusão editorial é simples: uma expansão do L35E só é defensável quando sua carga máxima medida, seu comportamento em caso de falha e seu plano de ciclo de vida estão todos documentados.