Algoritmo de Leitura de SOE Genérico da Elipse Software

O protocolo Modbus não define um método padrão de leitura de eventos do equipamento. Por este motivo, é comum fabricantes criarem seus próprios algoritmos de leitura de eventos em equipamentos com suporte ao protocolo Modbus.

O algoritmo de Sequenciamento de Eventos (SOE, Sequencing of Events) genérico deste Driver (Elipse Modbus SOE) foi desenvolvido pela Elipse Software com o objetivo de prover uma alternativa padrão para a leitura de eventos de controladores programáveis que não contem com este recurso de forma nativa, desde que estes atendam a alguns requisitos básicos de espaço de memória e recursos de programação, permitindo criar as tabelas e registros de controle descritos a seguir.

Este algoritmo permite armazenar e ler eventos de praticamente qualquer controlador programável, de forma otimizada, valendo-se de recursos já implementados e validados no Driver Modbus.

A leitura de eventos no Driver Modbus segue o procedimento padrão, definido pela Elipse Software, lendo eventos de tabelas montadas na memória do CLP ou de dispositivos escravos pelo seu software residente ou aplicativo (ladder).

Para utilizar este algoritmo é preciso definir Tags com a função especial Gen SOE do Driver, o que pode ser realizado tanto através da antiga configuração numérica (parâmetros N e B) como pelo novo método de configuração por Strings (campos Dispositivo e Item). A configuração dos Tags é descrita mais adiante no tópico Procedimento de Aquisição na Aplicação.

Durante o processo de leitura de eventos, a função especial Gen SOE usa sempre a função Modbus 03 (Read Holding Register) para leitura de registros do equipamento. Já para a escrita na atualização dos registros de controle, é usada por padrão a função 16 (Write Multiple Registers). Na configuração numérica é possível selecionar a função de escrita 06 (Write Single Registers), para o caso raro de equipamentos que não suportem a função 16 (o contrário é mais comum), através do campo Write da operação, na aba Operations.

O software residente do CLP (ladder ou equivalente) deve manter atualizados os registradores de controle que fornecem informações ao Driver, como o número de eventos disponíveis para a leitura e o endereço do último registro a ler.

O equipamento pode manter mais de uma tabela de eventos, em diferentes endereços de memória, contendo tipos de dados diferentes. Cada tabela deve ser precedida pelos seus respectivos registradores de controle, em endereços adjacentes. A tabela em si é constituída por um buffer circular em endereços contíguos, acumulando os eventos ou dados a serem coletados pelo Driver a cada procedimento de coleta (download de eventos).

O usuário pode definir formatos distintos de dados (eventos) para cada uma das tabelas definidas, os quais são geralmente definidos como uma estrutura de dados, podendo conter o campo de estampa de tempo do evento (timestamp). Os eventos podem também ser definidos usando um tipo de dados nativo do Driver. Neste caso, não é possível definir um campo Timestamp no CLP (o timestamp vem com a data da leitura), e o evento tem somente um campo, podendo ser representado por um Tag simples (Tag PLC no Elipse SCADA).

Os tópicos a seguir descrevem de forma detalhada o algoritmo, sua implementação no software do CLP (ladder) e como realizar sua leitura usando os Tags do Driver:

·Tabela de Eventos

·Procedimento de Aquisição no CLP

·Procedimento de Aquisição na Aplicação