Prezados temos o Servidor OPC Server do E3 disponibilizando dados para um OPC Client, percebemos que existe uma falta de sincronismo entre o horário do servidor (Sistema Operacional) e o horário fornecido no timestamp da tag. E a diferença aumenta conforme o tempo em que o domínio é executado.
Ola @joseluisjanuario,
Conforme conversado, segue orientações para resolução do problema:
1° A diferença de TimeStamp que ia se alongando era devido a fila de solicitações pendentes do IOServer (driver) com o E3Run(E3), que devido a travamentos ocasionados por escritas do “driver leste”, ocupava o E3Run, impedindo dele processar as informações dos outros IOServer’s, conforme abaixo:
Legenda:
I: IOServer que informa o erro de escrita
II: E3Run informa que está travado em uma operação de driver
III: E3Run se recupera do travamento
I. 18/02/2020 10:40:49.317 IOSERVER (D:\Supervisorio\Converte\Driver_com\Modicon\modbus32_Leste.dll) MaskWriteElm(size=61,index=0,0,1,113,900,‘0’) = 8004F307
II. 18/02/2020 10:41:23.148 SYSTEM Warning W00550: Thread E3Run.E3Runtime {3768} is performing a lengthy operation (33.829 seconds elapsed). Currently at:
Thread E3Runtime
DispatchMessage(2034,28902800,0,0000000000140DE2)
KernelProc(30)
Timer 0000000017AEE6D0
CIOManager::OnTimer
[IODriver(CLP.Modbus.Leste;0F68)]IOCallback
[IODriver(CLP.Modbus.Leste;0F68)]SyncWriteMask(0000006F,1)
III. 18/02/2020 10:41:25.199 SYSTEM Info I00590: Thread E3Run.E3Runtime {3768} finished a lengthy operation after 35.880 seconds
Para solucionar o caso, configuramos o driver leste para não precisar esperar por uma resposta da escrita de forma imediata, mas sim na próxima leitura:
2° A aplicação também continha associações “fixas” para habilitar a leitura das tags, sendo que estas já estavam habilitadas, neste caso, recomendo a remover as associações e apenas deixar configurado na propriedade das tags o “AllowRead” = True, exemplo da associação encontrada:
3° Pode-se também configurar todos os driver para utilizar uma mesma dll de driver, desta forma, fica mais fácil fazer o controle de versão do driver em uso. Inclusive em caso futuro, utilizar o agrupamento de driver (“Pool”), conforme imagem exemplo abaixo:
4° Como informações adicionais, conversamos de ajustar melhor o TimeOut do driver, que estava muito alto em alguns casos, por exemplo 30 segundos, e que neste caso, se um tag ficar sem responder a solicitação, o driver fica “travado” por 30 segundos aguardando a resposta. Então para melhorar esta velocidade de identificação de perda de pacotes, e também de acordo com uma observação pontual de um driver, entendemos que pode-se utilizar o TimeOut de 1 segundo de forma genérica, ou também analisar driver a driver, a ajustar conforme o trafego dos pacotes:
@LucasSantos Olá Lucas!
Tenho uma dúvida referente a IOQueue: Quando tenho diferentes prjs e pelo menos um driver para cada prj, a IOQueue é referente a cada driver especificamente ou é um processo geral de todo o domínio do E3?
