Reconexão do driver OPC UA após atualização de programa no CLP.

1. Introdução

Ao enviar uma atualização de programa para o CLP, é comum que o servidor OPC UA do próprio CLP reinicie as sessões de comunicação — um comportamento esperado dessa operação. O esperado é que o driver OPC UA do E3 detecte a queda e reconecte automaticamente. Em alguns cenários, porém, o driver não consegue reconectar sozinho, e só a reinicialização do domínio do E3 restabelece a comunicação. Isso costuma acontecer quando a reconstrução da assinatura (subscription) demora mais do que os tempos configurados no driver: a sessão expira no meio da reconexão e o driver recomeça do zero, num ciclo que não se fecha. Este artigo mostra por que isso ocorre e como ajustar as propriedades do driver (MaxNodesPerClientCall, TimeoutSession, TimeoutCall e PublishLimit) para que a reconexão se complete automaticamente.

2. Por que o driver não reconecta sozinho

Quando o servidor OPC UA do CLP reinicia as sessões, o driver tenta se reconectar e recriar a assinatura, registrando novamente todos os itens monitorados. Se esse registro é feito em uma única chamada com muitos itens, ele pode levar mais tempo do que os timeouts do driver permitem.

Neste exemplo, o log do E3 registrou exatamente isso — a reconexão ficou presa por ~39 segundos tentando registrar 284 itens de uma só vez:

Log do E3

Warning W00550: Thread E3UaClient.UaClient is performing a lengthy operation
(38.801 seconds elapsed ...)
  CE3UaConnection::Update(Connected, NeedUpdate=TRUE, SessionCfg=TRUE)
  CUaClientSession::CreateMonitoredItems(Subscription=..., Count=284)

Como essa chamada (CreateMonitoredItems) demorou mais que o timeout de chamada e que o keep-alive da sessão, a sessão caía antes de a reconexão terminar, e o driver recomeçava o processo — um laço que só foi quebrado ao reiniciar o domínio.

Havia ainda uma segunda condição, presente no log inteiro: o CLP rejeitava continuamente as requisições de publish com a mensagem “The server has reached the maximum number of queued publish requests” (dezenas de milhares de ocorrências). Ou seja, o E3 enviava mais requisições de publish do que aquele CLP conseguia enfileirar — resultado de muitas assinaturas disputando o mesmo equipamento.

Não houve travamento geral, falta de memória nem perda de licença do lado do E3. O gargalo estava no volume de itens/requisições por chamada contra a capacidade do CLP, combinado com timeouts curtos para o tempo real de reconexão.

3. As propriedades envolvidas

Todas são propriedades do objeto driver OPC UA (UaDriver). Os três tempos são sempre expressos em milissegundos.

Propriedade	O que faz
`MaxNodesPerClientCall`	Limita quantos nós o E3 registra por chamada OPC UA. Em `0`, não há limite e todos os itens vão numa única chamada. Deve ser ajustada para o menor limite informado pelo servidor (ex.: `MaxMonitoredItemsPerCall`); assim o E3 particiona o registro em vários lotes, evitando chamadas longas e o erro `Bad_TooManyOperations`.
`TimeoutSession`	Keep-alive da sessão. Se a reconexão/reassinatura demora mais que este valor, a sessão expira antes de concluir.
`TimeoutCall`	Tempo máximo de uma chamada (RPC) ao servidor. Foi o tempo excedido pela chamada de ~39 s.
`TimeoutConnection`	Tempo para estabelecer a conexão. Neste caso não era o gargalo.
`PublishLimit`	Limita as requisições de publish pendentes da assinatura. Um valor baixo reduz o excesso de publish que satura o CLP.

4. Como ajustar

Pelo E3 Studio

No Organizer, selecione o objeto do driver OPC UA (ex.: DriverUA3).
No painel de Propriedades, localize as propriedades abaixo e ajuste os valores.
Salve o projeto e reinicie o domínio uma vez para aplicar (a partir daí, a reconexão passa a ser automática).

Estes foram os valores do projeto exemplo (atuais × sugeridos) que resolveram o caso — adapte ao seu equipamento:

Propriedade	Atual	Sugerido	Motivo
`MaxNodesPerClientCall`	0	50–100	O log mostrou `CreateMonitoredItems(Count=284)` — 284 itens numa única chamada. Dividir o registro em lotes que o CLP processa dentro do tempo. Foi o ajuste que já havia resolvido no passado.
`TimeoutSession`	20 s (20000 ms)	120 s (120000 ms)	A reassinatura levou ~39 s, maior que os 20 s; a sessão caía antes de reconectar.
`TimeoutCall`	30 s (30000 ms)	60 s (60000 ms)	Foi excedido pela chamada de 38,8 s; dá folga durante a reconexão.
`TimeoutConnection`	10 s (10000 ms)	manter	Não foi o gargalo.
`PublishLimit`	0	valor baixo (ex.: 2–5)	Reduz o excesso de publish que satura o CLP.

Atenção às unidades

No painel do Studio, TimeoutSession, TimeoutCall e TimeoutConnection são informados em milissegundos — 120 s equivalem a 120000.

5. Resultado

Com o MaxNodesPerClientCall limitando os itens por chamada e os timeouts folgados, a reconstrução da assinatura passa a caber dentro do tempo de sessão, e o driver reconecta automaticamente após o CLP reiniciar as sessões — sem necessidade de reiniciar o domínio.

6. Observações e boas práticas

MaxNodesPerClientCall = menor limite do servidor. Muitos CLPs, por restrição de memória, limitam quantos itens processam por chamada. Configure a propriedade com o menor valor informado pelo servidor (limites como MaxNodesPerRead, MaxMonitoredItemsPerCall) para evitar o erro Bad_TooManyOperations.
Timeouts sempre em milissegundos e sempre relativos ao desempenho real de comunicação (servidor, rede e máquinas). Meça o tempo de reconexão observado e deixe folga sobre ele.
Menos assinaturas por equipamento. Várias assinaturas disputando o mesmo CLP aumentam o volume de publish e podem saturar a fila do servidor. Consolidar assinaturas e/ou reduzir o PublishLimit alivia o equipamento.
A reinicialização das sessões pelo CLP é normal durante o download de programa; o objetivo do ajuste é garantir que o driver reconecte dentro da janela de tempo, não evitar a queda.