Modbus – Um Protocolo e Diferentes Implementações

Alguns padrões de comunicação simplesmente aparecem e são adotados pelo mercado!

Não é porque eles são empurrados, de cima para baixo, por um grupo de fornecedores grandes ou por uma organização de padronização. Padrões como o Modbus aparecem e são adotados pelo mercado porque eles são bons, simples de implementar e são, como consequência, adotados por inúmeros fabricantes. Devido a isso, o Modbus tornou-se um padrão amplamente aceito nos diversos segmentos do mercado de automação.

Em 1979, a Gould-Modicon lançou para seus CLPs a rede de comunicação Modbus. Ela tinha como base o protocolo de comunicação Modbus serial. Este protocolo era apresentado em duas versões:

• Modbus serial RTU.
• e, Modbus serial ASCII.

A rede de comunicação Modbus operava sobre os padrões RS-485 (para redes multiestação) e RS-232 (para conexões entre duas estações).

A Gould-Modicon, após lançar a rede Modbus, disponibilizou publicamente as especificações do protocolo e da rede. De forma que qualquer empresa que quisesse implantar este padrão em seus equipamentos poderia fazê-lo sem ter que pagar qualquer direito de uso à Gould-Modicon.

No início dos anos 80, a Gould-Modicon lançou para seus CLPs a uma evolução da rede de comunicação Modbus, chamada Modbus Plus.

No caso da rede Modbus Plus, a Gould-Modicon não disponibilizou ao público as especificações de protocolo e da rede, transformando-a em uma rede proprietária.

A rede Modbus Plus foi descontinuada ao final dos anos 90 e, na prática, não é mais encontrada.

Como a rede ethernet se popularizou na automação industrial a partir de meados dos anos 90, a comunidade de usuários passou a usar o protocolo Modbus serial neste tipo de rede, usando um método chamado de encapsulamento.

E, finalmente em 1999, foi lançada a especificação do protocolo Modbus para redes ethernet. Esta nova versão do protocolo definiu o uso do TCP/IP para o transporte das mensagens e foi chamada de Modbus TCP.

No início dos anos 2000 a Schneider Electric, sucessora da Gould-Modicon e outros, deu suporte à criação da "The Modbus Organization". Esta organização, sem fins lucrativos, é mantida pela comunidade de usuários do protocolo com objetivo de manter e gerenciar a necessidade de evolução das especificações do protocolo, incentivar seu uso e oferecer informações necessárias para a sua correta implementação (http://www.modbus.org). Esta organização criou e incentiva um programa de testes para certificação de produtos que implementam o protocolo.

Esta iniciativa permite aos usuários evitar a compra de produtos que incorporem drivers Modbus implementados com interpretações particulares das especificações – muito comuns no passado.

As duas maiores dificuldades de uso do protocolo Modbus estão relacionadas a:

• documentação sobre a interface de comunicação, sua parametrização;
• mapa de memória do dispositivo;
• e, implementações com interpretação particularizada das especificações.

Por exemplo, para implantar um sistema composto de um supervisório e alguns dispositivos Modbus (medidores de energia, pequenos CLPs ou outros), são necessários:

• configurar os parâmetros de rede na interface de comunicação do computador e dos dispositivos;
• e, ter o mapa de memória do dispositivo listando cada variável do dispositivo com seu endereço Modbus equivalente.

As informações necessárias para executar estas tarefas deveriam fazer parte da documentação (ou de anexos) de cada dispositivo. Mas, na prática, a documentação não apresenta as informações de forma clara e padronizada e muita vezes tem que ser solicitadas ao suporte técnico do fabricante do dispositivo (não vem junto com o dispositivo).

Outro fator de confusão na implementação deste tipo de sistema são as implementações do protocolo com interpretação particularizada das especificações. O protocolo Modbus foi criado faz 30 anos, e, muitos recursos e funcionalidades comuns nos equipamentos de hoje em dia não existiam nos equipamentos naquela época. Com isto, recursos tais como: números muito grandes, números de ponto flutuante, formas de endereçamento e alocação de memória para os diferentes tipos de dados, entre outras, não foram considerados nas definições do protocolo. Com isto as empresas criaram suas próprias definições, a partir de práticas existentes ou fazendo definições particulares.

Por exemplo, existem alguns formatos para os números de ponto flutuante: meia precisão, precisão simples ou dupla, com sinal ou sem sinal.

Que forma armazenar estes números na memória dos dispositivos? Os fabricantes dos dispositivos, uma vez que a especificação do protocolo não faz qualquer definição acerca, podiam optar por algum padrão existente ou criar seu próprio padrão de armazenamento.

Esta falta de definição na especificação do protocolo cria uma dificuldade para o usuário, caso o fabricante do dispositivo não informe de forma clara na documentação qual o formato usado para armazenar os números de ponto flutuante na memória do dispositivo.

Como a questão do ponto flutuante, existem outros desvios ou implementações particularizadas que causam confusão na implantação de sistemas com o protocolo Modbus, tais como:

• endereçamento das Estações Escravo Modbus (com mais de um byte);
• modo Broadcast;
• endereço dos Registros (base 0 x base 1);
• endereço dos Bits (base 0 x base 1);
• ordem de transmissão dos bytes nos registros;
• ordem de transmissão para valores que usam mais de um registro (números de 32 ou 64 bits - inteiros ou ponto flutuante).

Vamos examinar a questão da ordem de transmissão dos bytes nos registros.

O protocolo Modbus especifica que para transmitir um registro (dois bytes) o dispositivo deve transmitir primeiro o byte de ordem superior e depois o byte de ordem inferior. Ou seja, para transmitir o valor 0x35A2 ele deve transmitir 35 no primeiro byte e A2 no segundo byte, desta forma o dispositivo que recebe o valor vai decodificar 0x35A2 e apresentar o valor decimal 13.730.

Porém alguns fabricantes não respeitam esta definição do protocolo e ao invés de transmitir 35 no primeiro byte e A2 no segundo byte, eles fazem a transmissão invertida. Primeiro é transmitido o A2 e depois é transmitido o 35, desta forma o dispositivo que recebe a mensagem vai decodificar 0xA235 e apresentar o valor decimal 41.525, que não corresponde ao valor na memória do dispositivo original.

Alguns drivers, no editor de configuração, têm uma opção que permite desfazer esta inversão. Neste caso é só habilitar esta opção e o driver faz a inversão de bytes a cada dois bytes de dados recebidos.

Se o seu driver não fizer esta inversão, você vai ter que escrever uma rotina de programa para fazê-la.

Este tipo de inversão é mais comum do que se imagina, portanto quando você estiver recebendo um valor diferente do valor de origem faça a conversão do valor na origem e no destino para o formato hexadecimal e verifique se você não está tendo uma inversão de bytes na transmissão.