Início - Aquisição de Dados - Endereçamento MODBUS RTU descomplicado (Parte 2)

Endereçamento MODBUS RTU descomplicado (Parte 2)

Leandro Roisenberg

Function Codes, Espaços de Registradores e o Mito de um Único Endereço no Endereçamento MODBUS RTU

Engenheiros que trabalham com endereçamento MODBUS RTU frequentemente assumem que um endereço de registrador identifica de forma exclusiva um ponto de dado dentro de um dispositivo. Este artigo aprofunda os fundamentos explicados em Descomplicando o endereçamento MODBUS RTU. Na prática, essa suposição gera confusão, sistemas SCADA mal configurados e longas sessões de diagnóstico.

A causa raiz é simples: o MODBUS não utiliza um único espaço de endereçamento plano. Em vez disso, ele define múltiplos espaços de registradores independentes, e o tipo de registrador é selecionado implicitamente pelo Function Code. Formatos de endereço lógico como 4XXXX ou 3XXXXX são convenções humanas sobrepostas ao protocolo e não existem no nível de comunicação.

Este artigo explora como o MODBUS realmente endereça dados e por que o Function Code pode ser considerado um “endereço sênior” ou seletor de namespace.

Endereçamento MODBUS RTU: não existe um único espaço de endereçamento

No nível do protocolo, o MODBUS define quatro modelos de dados distintos:

  • Coils (saídas discretas)
  • Entradas discretas
  • Registradores de entrada
  • Registradores de retenção (holding registers)

Cada um desses representa um espaço de endereçamento independente, com endereços variando de 0 a 65535.

Endereçamento MODBUS RTU e Function Codes: Selecionando o Espaço de Registradores

diagrama de espaços de registradores e function codes no endereçamento MODBUS RTU

Isso significa que o endereço 13 pode existir legalmente quatro vezes dentro do mesmo dispositivo:

  • coil 13
  • entrada discreta 13
  • registrador de entrada 13
  • registrador de retenção 13

Não há ambiguidade porque eles nunca são acessados da mesma forma. No MODBUS RTU, o tipo de registrador nunca é transmitido explicitamente. Em vez disso, ele é indicado implicitamente pelos Function Codes do Modbus.

Por exemplo:

  • Function Code 01 → leitura de coils
  • Function Code 02 → leitura de entradas discretas
  • Function Code 03 → leitura de registradores de retenção
  • Function Code 04 → leitura de registradores de entrada

Sob essa perspectiva, o Function Code atua como um seletor que determina a qual espaço de registradores o endereço subsequente se refere.

Em outras palavras, o endereço real no nível do protocolo não é apenas o campo de endereço do registrador. É a combinação de:

  • Function Code
  • Endereço PDU do registrador

É por isso que o mesmo valor de endereço PDU pode legitimamente acessar dados completamente diferentes dependendo do Function Code utilizado.

Os endereços PDU são sempre baseados em zero no endereçamento MODBUS RTU

Dentro do PDU do MODBUS, o endereço do registrador é um valor de 16 bits baseado em zero, variando de 0 a 65535. Este é o único endereço transmitido fisicamente no barramento.

Não existe o conceito de “40001”, “30010” ou “10025” no frame MODBUS RTU. Esses formatos existem exclusivamente para fins de documentação e interfaces de usuário.

Qualquer esquema de endereçamento que comece em 1 ou inclua um dígito inicial para indicar o tipo de registrador é uma convenção lógica, não um requisito do protocolo.

A origem dos endereços lógicos e offsets no endereçamento MODBUS RTU

Para tornar os endereços MODBUS mais fáceis de interpretar para humanos, fabricantes e fornecedores de software introduziram esquemas de endereçamento lógico com offsets. O formato de endereço segue convenções utilizadas por muitos sistemas SCADA, conforme descrito pela Fernhill Software.

As convenções mais utilizadas incluem:

  • Coils: 0 ou 1
  • Entradas discretas: 10001
  • Registradores de entrada: 30001
  • Registradores de retenção: 40001

Esses offsets não alteram o funcionamento do protocolo. Eles simplesmente codificam duas informações em um único número:

  • o tipo de registrador
  • o índice do registrador

Diferentes fornecedores podem escolher offsets distintos, comprimentos de dígitos diferentes ou até omitir os offsets completamente. É por isso que a documentação de dispositivos e os softwares SCADA frequentemente parecem inconsistentes entre si.

Por que softwares SCADA frequentemente geram confusão no endereçamento MODBUS RTU

A maioria dos sistemas SCADA solicita que o usuário insira um “endereço de registrador” e um “tipo de registrador” separadamente. Outros esperam um único endereço lógico, como 400131.

Internamente, porém, todo mestre MODBUS executa as mesmas etapas:

  1. Seleciona o Function Code com base no tipo de registrador
  2. Converte o endereço lógico para um endereço PDU baseado em zero
  3. Transmite apenas o Function Code e o endereço PDU

Compreender esse processo interno deixa claro por que alterar o formato do endereço lógico não afeta a comunicação real, desde que o endereço PDU final e o Function Code estejam corretos.

A forma correta de pensar sobre o endereçamento MODBUS RTU

Um modelo mental útil é pensar no endereçamento MODBUS como um sistema de dois níveis:

  • O Function Code seleciona o espaço de registradores
  • O endereço PDU seleciona o elemento dentro desse espaço

Uma vez adotado esse modelo, muitos equívocos comuns desaparecem:

  • números de registradores idênticos deixam de parecer problemáticos
  • os offsets são claramente reconhecidos como convenções de interface
  • inconsistências na documentação tornam-se mais fáceis de interpretar

Conclusão

O MODBUS RTU não fornece um único espaço de endereçamento global. Em vez disso, ele depende de múltiplos espaços de registradores independentes, selecionados implicitamente pelo Function Code. Endereços lógicos, offsets e esquemas de numeração são ferramentas para humanos, não parte do protocolo em si. No nível de comunicação, apenas o Function Code e o endereço PDU baseado em zero são relevantes. Reconhecer essa distinção é fundamental para projetar integrações MODBUS robustas, interpretar a documentação de dispositivos corretamente e evitar erros de endereçamento desnecessários.

Leandro Roisenberg

ARTIGOS RELACIONADOS

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.