Edge: Comunicação Modbus com Edge Device WCD-ED300

Este passo a passo visa apresentar uma noção básica de leitura em Modbus RTU com o Edge Device WEG WCD-ED300.

1 – Criar uma aplicação.

2 – Adicionar um Device ED300:

Atenção!

Para a criação do Device ED300 acesse o tópico do fórum:

Configurando o Edge Device WEG WCD-ED300 na Plataforma WEGnology

3 – Adicionar um dispositivo periférico:

Observação: É possível usar o próprio dispositivo adicionado anteriormente, porém, por boas práticas é recomendável adicionar o dispositivo de acordo com sua função.

Selecione um Device do tipo Periférico (Perifpheral).

Conforme a descrição, Periférico é um tipo de dispositivo que reporta seu estado “atrevés de um gateway”, tipicamente são equipamentos que não conectam com a internet sozinhos. Ou seja, precisa de um gateway ou um Edge Compute que faça a leitura de suas variáveis e então publique na Plataforma.

  • Defina o nome e descrição do Dispositivo.

  • Poderá ter seus valores publicados por “qualquer Gateway” ou por um Gateway em específico. No exemplo, iremos comunicar com nosso WCD-ED300 que foi adicionado à aplicação

  • Por fim, confirme em “Create Device”.

4 – Criar os atributos (variáveis de estado do Time Series no Device)

Agora, com o Dispositivo criado, vamos definir os atributos:

  • Em nosso exemplo, iremos ler o endereço 0 (zero) que contém a tensão Fase-Neutro.

Conforme o manual do Modbus do MMW03-CH.

Então criaremos um atributo para nosso device, com o nome de acordo com a variável lida:

Escolheremos o formato numérico “Number”.

Ao término, confirmar clicando em “Update Attributes”.

5 – Criar um workflow de Edge para a leitura Modbus.

No menu “Worflows” adicione um Workflow na seção “Edge Workflows”

Importante: verifique a versão do seu Edge Agent! (no exemplo, meu ED300 estava com a versão 1.25.0, portando ele aceitará a versão 1.19.0)

Sempre crie um workflow na Plataforma com versão inferior ou igual à do seu Edge Device. Caso contrário o sistema irá bloquear o deploy.

Como saber a versão de meu Edge Agent?

Duas formas:

A) Na plataforma, clique no seu Device WCD-ED300 e veja o último payload recebido conforme abaixo. Lá poderá ver o nome da imagem. No exemplo, estamos com a versão 1.25.0.

B) Na webpage do WCD-ED300, veja na seção “Docker Information”:

Verificada a versão, preencha os dados na tela de criação do Workflow.

6 – Desenvolvendo o Workflow

Vamos fazer um exemplo simples para ir incrementando as funcionalidades e conhecendo os nodes utilizados.

Primeiramente, iremos inserir os nodes:

  • “Timer” para que as leituras sejam realizadas ciclicamente.

- “Virtual Button” para forçar leituras manualmente quando necessitar.

- Modbus Read: Node que executa as leituras propriamente didas.

- Debug: Para podermos acompanhar o que está ocorrendo.

6.1 Node Timer:

Neste exemplo parametrizaremos para leitura a cada 10 segundos, sincronizado com o relógio mundial, seguindo o padrão “Cron timer”.

Observação: o Padrão Cron nos permite uma previsibilidade e uniformidade nas leituras, por ser sincronizado com o relógio, Por exemplo: se forem leituras a cada 10 minutos, “todas” as leituras seriam às: hh:00, hh:10 , hh:20, hh:30, hh:40: hh:50. Repetindo a cada nova hora.

6.1 Node Virtual Button:

Conforme comentado, ao estarmos “debugando”, podemos clicar nele em vez de aguardar o Timer disparar a lógica.

6.2 Node Modbus Read:

6.2.1 Address Config Ethernet

Neste momento devemos selecionar o meio físico, se for via ethernet (TCP Connection) ou via Serial RS 485 (Serial RTU Connection)

Abaixo usamos o modo TCP.

Com isto precisamos saber o endereço IP do equipamento e a porta a ser utilizada.

Geralmente, por padrão, a porta para Modbus TCP é a 502. Mas nada impede do equipamento ter outra porta, é preciso ter os dados dele.

6.2.2 Address Config – Serial RTU

Neste caso, é preciso saber como estão configurados os parâmetros de comunicação da serial do seu dispositivo:

  • no exemplo, nosso Multimedidor MMW03-CH está configurado para:

velocidade 57600

Unit ID : 1

Sem paridade:

Os outros dados foram extraídos do manual do Moltimedidor: como 1 stop bit e 8 bits de dados.

Então, no node teremos que digitar igualmente os dados:

Importante: O WCD-ED300 segue o padrão Linux e a porta RS485 fica: /dev/ttymxc6

6.2.3 Conversão dos valores, timeout e endianness

  • Particularmente prefiro mostrar “unsigned” ou seja, “sem sinal”.

Assim os valores das words que virão no Modbus (16 bits) aparecerão “como são” de 0 a 65535, mais fácil de “debugar”.

Mas se os valores já são em 16 bits “com sinal” é melhor ajustar a opção para “signed”.

- Timeout: configure o tempo de timeout “em milissegundos”.

-Endianness: Existem equipamentos que é necessário “inverter as Words”.**

Existem as duas opções “big” ou “little”.

Utilize a opção que de adequa ao seu dispositivo.

Dica: quando vier um valor absurdo na leitura, por exemplo, um Floating Point em 32 bits que aparece num expoente negativo “-56” é bem provável que esteja invertido o endianess, mude de little para big ou vice-versa.

6.2.3 Leitura de Holding Registers

Agora vamos configurar os endereços na tabela Modbus que nosso equipamento disponibiliza.

O node permite ler os diversos tipos de variáveis Modbus, vamos focar nos Holdings Registes.

Novamente é preciso conhecer bem o equipamento que se deseja ler.

Em nosso Multimedidor MMW03-CH, pela tabela Modbus temos que:

  • a tensão Fase R – Neutro está na área de Holding Register

  • o endereço desta variável é o zero (0).

  • Importante: esta variável está no formato “IEEE Floating Point” em 32 bits.

Ou seja, sempre preciso ler “duas” words, caso tente ler algum número ímpar, ocorrerá erro de endereço inválido, pois tentará ler “meia variável”.

  • anotamos o endereço inicial (Address Template): 0

  • anotamos a quantidade de “Words” (Length Template): 4 (poderia ser 2, vamos ler um pouco mais só por exemplo)

  • “criamos um nome” (Result Key): usamos “holdings”. Será a variável criada com o resultado do que for lido.

A Interface permite que se faça a leitura de mais “poolings” de leitura, por exemplo, poderíamos ler “Input Registers” “coils”.

Mas como o exemplo só será leitura de alguns Holdings Registers, não clicaremos nesta parte, senão abrirá sucessivas configurações.

Agora, por fim, criamos a variável final do node.

  • em Result Key iremos criar a variável que conterá todos os “poolings” de leitura. Chamamos agora de “mbData”.

Neste momento já poderemos testar uma leitura Modbus.

Basta fazer o “deploy” e entrar no modo de debug.

Depois de dar os comandos de “save” e “Deploy” a janela mostrará se o ED300 estiver online um icone em azul escuro. Clique nele e entrará no modo “debug”.

6.2.4 Realizando o Debug da Leitura de Holding Registers

Pelo programado no timer, a cada 10 segundos será executada uma leitura Modbus.

Observe na área de debug ao lado e localize a variável que foi criada “mbData”.

No exemplo abaixo, ao abrir esta variável, nos deparamos com o erro de “Timeout”.

Erro de Timeout é um erro muito básico, geralmente é algo bem simples, pode ser um cabo rompido, polaridade invertida, parâmetros da serial errados.

No caso… estava invertido o cabo A com o B no Modbus RTU…

Após corrigida a ligação elétrica, obtivemos o payload correto:

Agora no vetor “mbData.holdings” temos os valores lidos, as 4 Words Modbus.

Como o Multimedidor tem suas variáveis em formato IEEE Floating Point, os valores lidos ficam difíceis de interpretar, visto que chegam separados em duas Words: 17248 e 6554.

Para isto, será utilizado um node para criarmos um simples script que converterá estes números em um número real.

Este script se encontra na Documentação da Plataforma, referente aos nodes de Modbus Read:

6.2.4 Trabalhando com os dados lidos, conversão IEEE Floating Point

Adaptando o script da documentação para nosso exemplo, temos:

const modbus = payload.mbData.holdings
const buffer = new ArrayBuffer(20)
const view = new DataView(buffer)

// Abaixo estamos transferindo cada WORD lida para a View
// A primeira variável vem dos registros 0 e 1 do Modbus
view.setInt16(0, modbus[0], false)
view.setInt16(1, modbus[1], false)

// A segunda variável vem dos registros 2 e 3 do Modbus
view.setInt16(0, modbus[2], false)
view.setInt16(1, modbus[3], false)

// Abaixo criamos um objeto "state" formando com a variável final
// Juntando as duas WORDS em um número Floating Point 32bits

payload.state = {
                 varLeitura: view.getFloat32(0, false),
                // as próximas variáveis juntando as próximas duas WORDS...
                 varLeitura2: view.getFloat32(4, false),
}
// Observação: note acima, que para a segunda variável F32 
// o endereço "saltou" 4 posições da View

Após este script, teremos uma variável “payload.state.varLeitura” contendo o valor convertido.

Conferindo com o Multimedidor:

Ia me esquecendo, o próprio ED300 possui uma tela para testes caso seja Modbus RTU.

Na webpage dele, em “administration” / “Communication tests”
Este teste elimina muitos erros básicos como comentei antes, baudrate errado, cabos rompidos, invertidos, etc.


Informação Importante!

O Próximo passo será postar este valor no atributo do Device utilizando o bloco “device State”.

Porém cuidado! Este Workflow está executando a cada 10 segundos.

Caso seja utilizada a mesma sequência desta lógica, será gasta uma quantidade grande de payloads.

Para otimizar, são criadas lógicas intermediárias, onde se extrai valores máximos, médios e mínimos que depois são postados em períodos maiores, por exemplo, consumindo um payload a cada 10 minutos.

3 Curtidas

Poderia me informar como deve ser feita a configuração do Time Payload Path do bloco Device:State? Gostaria de utilizar essa configuração para publicar a cada 10 minutos por exemplo

Boa questão, Lucas!

Existem algumas formas de se ajustar o timer.
Uma delas, a mais simples, é a “Simple Interval”.
Conforme abaixo, ele vai disparar a lógica, o workflow, a cada 5 minutos.

image
Porém neste formato, os horários, apesar de espaçados em 5 minutos, podem ser aleatórios, por exemplo, se iniciar a lógica às 10:03 depois rodará às 10:08, depois Às 10:13

Muitas vezes, se necessita que estes disparos sejam sincronizados com o relógio mundial.
Pode exemplo: Às 10:00 , 10:05. 10:15…

Para isto, temos a opção “Advanced”, que usa o formato “CRON”
no print abaixo, copiei o próprio exemplo da plataforma:

image

Existe uma agenda mais completa ainda para disparos diários onde se escolhe o horário e dia de semana desejado:

image

Pessoal, hoje verifiquei que algumas figuras ficaram repetidas.
Revisei o post e agora estão OK.

@Alexandre, estou usando a versão Sandbox e não encontrei esse nó, poderia confirmar em quais versões ele existe? Obrigado.

Olá, Rafael!

No Post usamos os nós:
- Timer para que as leituras sejam realizadas ciclicamente.

- “Virtual Button” para forçar leituras manualmente quando necessitar.

- Modbus Read: Node que executa as leituras propriamente didas.

- Debug: Para podermos acompanhar o que está ocorrendo.

- Function Para rodarmos um JavaScript onde fazemos as conversões de WORD para IEEE FLoatingPoint

A versão SandBox (Free) possui todos os blocos liberados!!

Um dos limitantes de nossa vesão Free é o histórico de dados, que reduz para 30 dias. Algumas quantidades de devices e usuários, por exemplo também reduzimos.

Mas as funcionalidades dos nodes estão 100% liberadas para vocês testarem e fazerem suas PoCs e validações!