Procedimento de Aquisição no CLP

Neste tópico discute-se o algoritmo de coleta de eventos sob o ponto de vista do CLP ou dispositivo escravo. O objetivo é deixar claro ao desenvolvedor o que é preciso ser implementado no software residente do CLP (ladder).

O dispositivo deve iniciar a inserção dos eventos no sentido crescente, a partir do endereço base da tabela, ou seja, do buffer circular. A cada novo evento inserido, o Ponteiro de Gravação deve ser incrementado, passando a apontar para a próximo posição disponível do buffer.

O Driver realiza a leitura do evento mais antigo para o mais recente. O endereço do início da leitura é calculado pelo Driver através do valor do Ponteiro de Gravação e do Status da Tabela.

Se o número de eventos disponíveis for maior que o máximo permitido em um único frame de comunicação do protocolo, o Driver realiza múltiplas leituras em bloco, atualizando após a conclusão do processo o valor do Status da Aquisição com o número total de eventos lidos.

Ao detectar um valor não nulo escrito pelo Driver no Status da Aquisição, o aplicativo do dispositivo ou CLP deve imediatamente subtrair o valor do Status da Aquisição do valor do Status da Tabela e em seguida zerar o Status da Aquisição. Com o Status da Aquisição novamente zerado, o Driver pode iniciar nova aquisição a qualquer momento.

O CLP pode inserir novos eventos na tabela durante o processo de aquisição pelo CLP, desde que não ocorra overflow do buffer circular, ou seja, desde que o ponteiro de escrita não ultrapasse o de leitura, incrementando o Status da Tabela.

O procedimento de coleta ou download de eventos é concluído quando o Status da Tabela for zerado. Os eventos coletados são então disponibilizados à aplicação por meio de Tags reportados a evento, procedimento visto no tópico a seguir.

A seguir é apresentado um pequeno fluxograma, em formato de Diagrama de Atividade UML, com sugestão de implementação para a lógica do CLP. Note que são possíveis algumas variações, como por exemplo descartar o evento mais antigo em caso de overflow, que podem ser avaliadas pelo desenvolvedor, dependendo do contexto.

Diagrama de Atividade UML (CLP)

Estampa de Tempo

Conforme já mencionado, cada evento é composto por uma estrutura contendo um ou mais elementos de dados (geralmente, porém não necessariamente, representados por Tipos de Dados Definidos pelo Usuário).

Se forem usadas estruturas (tipos de dados definidos pelo usuário), é possível associar a cada evento uma estampa de tempo (timestamp) fornecida pelo CLP. Neste caso, o valor do campo Timestamp deve ser fornecido em um campo da estrutura, na memória do CLP, na ordem em que é declarado no arquivo de configuração, e seu valor não é mostrado em nenhum Elemento de Bloco, sendo retornado apenas na propriedade Timestamp do Tag associado.

Conforme explicado no tópico Tipos de Dados Definidos pelo Usuário, qualquer tipo de dados de data e hora suportado pelo Driver pode ser usado. O tipo de dados GenTime, entretanto, foi criado especialmente para uso com o Elipse Modbus SOE, devido à facilidade de definição no software residente (ladder) do CLP.

Caso não seja necessária uma precisão de milissegundos, outra opção a considerar é o tipo de dados UTC32 do Driver, representado como um inteiro de apenas 32 bits (quatro bytes) com os segundos desde 1/1/1970, sem a representação dos milissegundos, considerados como 0 (zero).

No tópico seguinte, Procedimento de Aquisição na Aplicação, descreve-se como configurar o supervisório para a coleta dos eventos acumulados no CLP ou dispositivo escravo programável.