{"id":17888,"date":"2026-08-05T09:36:14","date_gmt":"2026-08-05T12:36:14","guid":{"rendered":"https:\/\/kb.elipse.com.br\/?p=17888"},"modified":"2026-08-05T14:14:33","modified_gmt":"2026-08-05T17:14:33","slug":"reconexao-do-driver-opc-ua-apos-atualizacao-de-programa-no-clp","status":"publish","type":"post","link":"https:\/\/kb.elipse.com.br\/en\/reconexao-do-driver-opc-ua-apos-atualizacao-de-programa-no-clp\/","title":{"rendered":"Reconex\u00e3o do driver OPC UA ap\u00f3s atualiza\u00e7\u00e3o de programa no CLP."},"content":{"rendered":"
\n
\n

1.<\/span> Introdu\u00e7\u00e3o<\/h2>\n<\/div>\n<\/div>\n
\n
Ao enviar uma atualiza\u00e7\u00e3o de programa para o CLP, \u00e9 comum que o servidor OPC UA do pr\u00f3prio CLP reinicie as sess\u00f5es de comunica\u00e7\u00e3o<\/strong> \u2014 um comportamento esperado dessa opera\u00e7\u00e3o. O esperado \u00e9 que o driver OPC UA do E3 detecte a queda e reconecte automaticamente<\/strong>. Em alguns cen\u00e1rios, por\u00e9m, o driver n\u00e3o consegue reconectar sozinho<\/strong>, e s\u00f3 a reinicializa\u00e7\u00e3o do dom\u00ednio do E3 restabelece a comunica\u00e7\u00e3o. Isso costuma acontecer quando a reconstru\u00e7\u00e3o da assinatura (subscription<\/em>) demora mais do que os tempos configurados no driver<\/strong>: a sess\u00e3o expira no meio da reconex\u00e3o e o driver recome\u00e7a do zero, num ciclo que n\u00e3o se fecha. Este artigo mostra por que isso ocorre e como ajustar as propriedades do driver (MaxNodesPerClientCall<\/code>, TimeoutSession<\/code>, TimeoutCall<\/code> e PublishLimit<\/code>) para que a reconex\u00e3o se complete automaticamente.<\/section>\n
\n

2.<\/span> Por que o driver n\u00e3o reconecta sozinho<\/h2>\n

Quando o servidor OPC UA do CLP reinicia as sess\u00f5es, o driver tenta se reconectar e recriar a assinatura<\/strong>, registrando novamente todos os itens monitorados. Se esse registro \u00e9 feito em uma \u00fanica chamada com muitos itens<\/strong>, ele pode levar mais tempo do que os timeouts do driver permitem.<\/p>\n

Neste exemplo, o log do E3 registrou exatamente isso \u2014 a reconex\u00e3o ficou presa por ~39 segundos<\/strong> tentando registrar 284 itens de uma s\u00f3 vez<\/strong>:<\/p>\n

\n
<\/i><\/i><\/i> Log do E3<\/div>\n
Warning W00550: Thread E3UaClient.UaClient is performing a lengthy operation<\/span>\r\n(38.801 seconds elapsed ...)<\/span>\r\n  CE3UaConnection::Update(Connected, NeedUpdate=TRUE, SessionCfg=TRUE)\r\n  CUaClientSession::CreateMonitoredItems(Subscription=..., Count=284)<\/pre>\n<\/div>\n
Como essa chamada (CreateMonitoredItems<\/code>) demorou mais que o timeout de chamada<\/strong> e que o keep-alive da sess\u00e3o<\/strong>, a sess\u00e3o ca\u00eda antes de a reconex\u00e3o terminar, e o driver recome\u00e7ava o processo \u2014 um la\u00e7o que s\u00f3 foi quebrado ao reiniciar o dom\u00ednio.<\/p>\n
Havia ainda uma segunda condi\u00e7\u00e3o, presente no log inteiro: o CLP rejeitava continuamente as requisi\u00e7\u00f5es de publish<\/em><\/strong> com a mensagem “The server has reached the maximum number of queued publish requests”<\/em> (dezenas de milhares de ocorr\u00eancias). Ou seja, o E3 enviava mais requisi\u00e7\u00f5es de publish<\/em> do que aquele CLP conseguia enfileirar \u2014 resultado de muitas assinaturas disputando o mesmo equipamento<\/strong>.<\/p>\n
\n
N\u00e3o houve travamento geral, falta de mem\u00f3ria nem perda de licen\u00e7a do lado do E3. O gargalo estava no volume de itens\/requisi\u00e7\u00f5es por chamada<\/strong> contra a capacidade do CLP, combinado com timeouts curtos para o tempo real de reconex\u00e3o.<\/p>\n<\/div>\n<\/section>\n
\n
3.<\/span> As propriedades envolvidas<\/h2>\n
Todas s\u00e3o propriedades do objeto driver OPC UA (UaDriver<\/code>)<\/strong>. Os tr\u00eas tempos s\u00e3o sempre expressos em milissegundos<\/strong>.<\/p>\n
\n\n\n\n\n\n\n\n\n\n
Propriedade<\/th>\nO que faz<\/th>\n<\/tr>\n<\/thead>\n
MaxNodesPerClientCall<\/code><\/td>\nLimita quantos n\u00f3s o E3 registra por chamada<\/strong> OPC UA. Em 0<\/code>, n\u00e3o h\u00e1 limite e todos os itens v\u00e3o numa \u00fanica chamada. Deve ser ajustada para o menor limite informado pelo servidor<\/strong> (ex.: MaxMonitoredItemsPerCall<\/code>); assim o E3 particiona o registro em v\u00e1rios lotes, evitando chamadas longas e o erro Bad_TooManyOperations<\/code>.<\/td>\n<\/tr>\n
TimeoutSession<\/code><\/td>\nKeep-alive da sess\u00e3o. Se a reconex\u00e3o\/reassinatura demora mais que este valor, a sess\u00e3o expira antes de concluir.<\/td>\n<\/tr>\n
TimeoutCall<\/code><\/td>\nTempo m\u00e1ximo de uma chamada (RPC) ao servidor. Foi o tempo excedido pela chamada de ~39 s.<\/td>\n<\/tr>\n
TimeoutConnection<\/code><\/td>\nTempo para estabelecer a conex\u00e3o. Neste caso n\u00e3o era o gargalo.<\/td>\n<\/tr>\n
PublishLimit<\/code><\/td>\nLimita as requisi\u00e7\u00f5es de publish<\/em> pendentes da assinatura. Um valor baixo reduz o excesso de publish<\/em> que satura o CLP.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/section>\n
\n
4.<\/span> Como ajustar<\/h2>\n
Pelo E3 Studio<\/h3>\n
    \n
  1. No Organizer<\/strong>, selecione o objeto do driver OPC UA (ex.: DriverUA3<\/code>).<\/li>\n
  2. No painel de Propriedades<\/strong>, localize as propriedades abaixo e ajuste os valores.<\/li>\n
  3. Salve o projeto e reinicie o dom\u00ednio uma vez para aplicar (a partir da\u00ed, a reconex\u00e3o passa a ser autom\u00e1tica).<\/li>\n<\/ol>\n
    Estes foram os valores do projeto exemplo (atuais \u00d7 sugeridos) que resolveram o caso \u2014 adapte ao seu equipamento:<\/p>\n
    \n\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n
     
    Propriedade<\/th>\nAtual<\/th>\nSugerido<\/th>\nMotivo<\/th>\n<\/tr>\n<\/thead>\n
    MaxNodesPerClientCall<\/code><\/td>\n0<\/td>\n50\u2013100<\/td>\nO log mostrou CreateMonitoredItems(Count=284)<\/code> \u2014 284 itens numa \u00fanica chamada. Dividir o registro em lotes que o CLP processa dentro do tempo. Foi o ajuste que j\u00e1 havia resolvido no passado.<\/td>\n<\/tr>\n
    TimeoutSession<\/code><\/td>\n20 s (20000 ms)<\/td>\n120 s (120000 ms)<\/td>\nA reassinatura levou ~39 s, maior que os 20 s; a sess\u00e3o ca\u00eda antes de reconectar.<\/td>\n<\/tr>\n
    TimeoutCall<\/code><\/td>\n30 s (30000 ms)<\/td>\n60 s (60000 ms)<\/td>\nFoi excedido pela chamada de 38,8 s; d\u00e1 folga durante a reconex\u00e3o.<\/td>\n<\/tr>\n
    TimeoutConnection<\/code><\/td>\n10 s (10000 ms)<\/td>\nmanter<\/td>\nN\u00e3o foi o gargalo.<\/td>\n<\/tr>\n
    PublishLimit<\/code><\/td>\n0<\/td>\nvalor baixo (ex.: 2\u20135)<\/td>\nReduz o excesso de publish<\/em> que satura o CLP.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    Aten\u00e7\u00e3o \u00e0s unidades<\/p>\n<\/section>\n<\/div>\n
    \n
    No painel do Studio, TimeoutSession<\/code>, TimeoutCall<\/code> e TimeoutConnection<\/code> s\u00e3o informados em milissegundos<\/strong> \u2014 120 s equivalem a 120000<\/code>.<\/p>\n<\/div>\n
    \n
    5.<\/span> Resultado<\/h2>\n
    Com o MaxNodesPerClientCall<\/code> limitando os itens por chamada e os timeouts folgados, a reconstru\u00e7\u00e3o da assinatura passa a caber dentro do tempo de sess\u00e3o, e o driver reconecta automaticamente<\/strong> ap\u00f3s o CLP reiniciar as sess\u00f5es \u2014 sem necessidade de reiniciar o dom\u00ednio.<\/p>\n<\/section>\n
    \n
    6.<\/span> Observa\u00e7\u00f5es e boas pr\u00e1ticas<\/h2>\n