ModBus RTU e ASCII: Protocolo de Comunicação Serial para Controle Industrial, Manuais, Projetos, Pesquisas de Programação de Rede

Baixe ModBus RTU e ASCII: Protocolo de Comunicação Serial para Controle Industrial e outras Manuais, Projetos, Pesquisas em PDF para Programação de Rede, somente na Docsity!

Protocolo de Comunicação Modbus RTU/ASCII

VERSÃO 1.0 – 28/08/

Parâmetros de programação dos indicadores ALFA Instrumentos

Protocolo de comunicação ModBus RTU / ASCII

1. Introdução

Este documento destina-se a programadores e/ou profissionais que de uma forma ou de outra, serão responsáveis pela programação de um PLC Modbus , nativo ou não, sendo desejável que tais profissionais tenham conhecimentos de bases numéricas (decimal, hexadecimal, código ASCII), do funcionamento básico de um PLC pois as informações contidas neste manual serão empregadas na sua programação, bem como dos conceitos de comunicação de dados, necessários para o bom funcionamento do programa.

É descrito em detalhes o protocolo de comunicação serial assíncrona padrão ModBus , implementado nos indicadores da ALFA Instrumentos, modelos 3104B Modbus e 3107 Modbus. Este protocolo deve ser utilizado para realizar a comunicação entre estes indicadores e qualquer controlador ou computador que esteja capacitado a transferir dados através do protocolo ModBus , nos modos ASCII ou RTU.

A interface serial dos indicadores ALFA pode operar tanto nos padrões elétricos RS232 como RS485 , configuráveis por hardware. Nestas condições o protocolo ModBus embarcado nos indicadores funciona normalmente pois independe do meio elétrico.

1.1. Terminologia

Descrição de alguns termos empregados ao longo deste documento:

PLC/CLP = Programable Logic Controller (Controlador Lógico Programável), dispositivo que controla e processa todas as informações de um sistema industrial

protocolo de comunicação = realização da troca de informações (mensagens) entre 2 ou mais dispositivos seguindo uma normalização específica, dependendo do tipo do protocolo

dispositivo = qualquer tipo de equipamento conectado a uma rede com capacidade de enviar e receber mensagens

mensagem = conjunto de dados que juntos, compõem uma série de informações passadas de um dispositivo a outro

mestre = dispositivo que inicia a transmissão de uma mensagem

escravo = dispositivo que responde a uma mensagem enviada por um dispositivo mestre

caracter = dado propriamente dito contido numa palavra de dados

palavra de dados (ou dados) = informação contendo o caracter, start bit, bits de paridade e stop bits

framing = conjunto de palavras de dados que compõem uma mensagem

barramento = meio físico por onde trafegam as mensagens

campo = uma mensagem é composta por vários campos, cada qual com uma informação específica

registrador = região de memória interna de um dispositivo

H = abreviação da base numérica hexadecimal

(+) = parte mais significativa da informação

(-) = parte menos significativa da informação

time-out = intervalo de tempo antes de se abortar um processo de comunicação

2. Conceitos de Mestre / Escravo e Enlace/Aplicação

Dois conceitos importantes numa comunicação de dados dizem respeito ao equipamento mestre e escravo. Em qualquer interligação na qual esteja sendo utilizado um protocolo necessariamente deverá existir um e somente um equipamento mestre e pelo menos um escravo.

Define-se como mestre o equipamento responsável por toda a iniciativa do processo de comunicação, ou seja, uma troca de dados entre os equipamentos, quer para transmissão ou recepção, é iniciado e finalizado pelo mestre. Defini-se como escravo o equipamento que, no processo de comunicação, só realiza alguma função sob solicitação e controle do mestre.

Um equipamento pode ser mestre ou escravo dependendo somente da sua aplicação no sistema. Isto quer dizer que em um determinado sistema, um equipamento pode ser configurado como mestre. Sendo que em outro sistema, o mesmo equipamento pode estar configurado com escravo.

Na comunicação entre um equipamento mestre e um escravo existem duas situações possíveis:

1. mestre deseja enviar/receber dados para/do escravo
2. escravo deve enviar/receber dados para/do escravo

No primeiro caso, como o mestre tem o poder de iniciar o processo de comunicação, ele envia a qualquer momento, de acordo com suas necessidades e independente do estado em que se encontrar o escravo, uma mensagem requisitando ao escravo a realização de uma determinada função. Ao receber a mensagem enviada pelo mestre, o escravo executa a função solicitada e envia uma resposta contendo o resultado desta função. Este processo da comunicação é chamado de select.

No segundo caso, como o escravo não pode tomar a iniciativa de começar o processo de comunicação, ele aguarda que o mestre envie uma mensagem. Ao receber a mensagem, o escravo realiza a função solicitada e envia uma resposta contendo o resultado. Este processo da comunicação é chamado de polling.

O nível de enlace se preocupa exclusivamente com os procedimentos a serem seguidos na transmissão e recepção das mensagens, recuperação de erros, sincronismo entre os equipamentos em relação à comunicação, conexão e desconexão, etc., deixando para o nível de aplicação o tratamento das informações relativas ao processo que se deseja supervisionar e/ou controlar.

O controle da comunicação é disciplinado por códigos HEXA ou ASCII (dependendo do protocolo utilizado) transmitidos em uma determinada sequências sendo que os procedimentos referentes ao sincronismo entre as mensagens e equipamentos são implementadas pelos processos de select e polling.

3. Protocolo ModBus

A comunicação com os indicadores ALFA Instrumentos através do protocolo ModBus, tanto no modo ASCII como RTU, seguem fielmente as normas estabelecidas pela Modicon Inc , desenvolvedora deste protocolo.

3.1. Introdução

Este protocolo foi desenvolvido pela Modicon Inc. para ser utilizado como meio de comunicação entre computadores existentes numa rede. Este protocolo basicamente define uma (^) estrutura de mensagens composta por bytes , que os mais diversos tipos de dispositivos são capazes de reconhecer, independentemente do tipo de rede utilizada.

Durante a comunicação, o protocolo determina como cada dispositivo:

• identificar seu endereço na rede
• reconhecer uma mensagem endereçada a ele
• determinar o tipo de ação a ser executada
• obter toda a informação necessária para executar a ação

Quando há a necessidade de devolver uma resposta ao comando recebido, o dispositivo monta uma mensagem e a envia, mesmo que esta indique um erro na comunicação.

3.2. Comunicação

A comunicação é feita através da técnica mestre-escravo, onde apenas um dispositivo (mestre) pode iniciar a comunicação (query). Os outros dispositivos (escravos) respondem enviando os dados solicitados pelo mestre. O mestre pode endereçar individualmente um escravo ou acessar a todos em uma rede através de mensagens em cadeia (broadcast), Apenas o escravo endereçado retorna uma resposta (response) a uma query e nunca são geradas responses quando uma query for do tipo broadcast.

O protocolo ModBus estabelece o formato da query definindo:

• o endereço do escravo (ou código para acesso broadcast)
• o código da função, que indica qual ação deve ser tomada pelo escravo
• parâmetros ou dados pertinentes à função definida
• o campo de checksum para checar a integridade da mensagem enviada

A resposta do escravo é gerada nos mesmos moldes porém, obedecendo o formato correspondente à função recebida pelo mestre que basicamente define:

• a confirmação a função realizada
• parâmetros ou dados pertinentes à função solicitada
• o campo de checksum para checar a integridade da mensagem enviada

Quando ocorrer um erro na comunicação ou se o escravo não estiver apto para atender à função requisitada, ele monta uma mensagem específica (exception) justificando o seu não atendimento.

3.4. Framing da mensagem

Na transmissão de uma mensagem ModBus, há (^) identificadores de início e fim de framing, específicos para cada um dos modos de transmissão. Este recurso permite aos dispositivos da rede detectarem o início de uma mensagem, ler o seu campo de endereço e determinar qual dispositivo está sendo endereçado (ou todos no caso do acesso ser tipo broadcast) e finalmente, ler todo o conteúdo da mensagem até o seu final. Será visto mais adiante que mensagens podem ser lidas apenas parcialmente com posterior geração de códigos de erro ( exceptions ) de acordo com a situação.

3.4.1. Framing no modo ASCII

Neste modo o início das mensagens são identificadas através do caracter dois pontos ( : ), correspondente ao valor ASCII 3AH, e o seu término é identificado pelo conjunto de caracteres Retorno de Carro (Carriage Return – CR ) e Avanço de Linha (Line Feed – LF ), respectivamente com correspondentes em ASCII aos valores 0DH e 0AH.

Os caracteres permitidos para transmissão para todo o resto da mensagem são 0 à 9 e A à F , respectivamente correspondentes aos caracteres ASCII 30H à 39H e 41H à 46H.

Os dispositivos da rede monitoram continuamente o barramento e quando é detectado o caracter 3AH tem início a decodificação do próximo campo, que indica para quem é a mensagem que está sendo transmitida.

Intervalos de até 1 segundo podem ocorrer entre o envio de cada caracter dentro de uma mesma mensagem sendo que para intervalos maiores, o escravo assume ocorrência de erro. A seguir é mostrado um framing típico no modo ASCII.

Início de framing

Endereço do Escravo

Função ModBus

Dados para o Escravo

Checksum Fim de framing 3AH char + char - 2 chars N chars LRC + LRC - 0DH 0AH

O exemplo a seguir utiliza valores em DECIMAL e respectivos em HEXA e ASCII, usados para ilustrar a formação do framing de dados:

• endereço do indicador: 69 = 45H = 34H 35H
• função ModBus: leitura de registradores: 03 = 03H = 30H 33H
• registrador inicial a ser lido: 11 = 0BH – pela norma ModBus: 000AH = 30H 30H 30H 41H
• número total de registradores a serem lidos: 1 = 0001H = 30H 30H 30H 31H
• Checksum (LRC) gerado: 173 = ADH = 41H 44H

Para os valores acima será gerado o seguinte framing de dados: 3AH 34H^ 35H^ 30H 33H 30H^ 30H^ 30H^ 41H^ 30H 30H 30H 31H 41H^ 44H^ 0DH 0AH

3.4.2. Framing no modo RTU

Diferentemente do modo ASCII, o modo RTU (^) não possui bytes que indiquem início e fim de framing. Para identificar estes campos, não deve haver nenhuma transmissão de dados por um período mínimo, equivalente a 3.5 vezes o tamanho da palavra de dados ( silent ).

Por exemplo, suponha que a taxa de transmissão seja de 19200 bps. Para esta taxa, o tempo total para envio de 1 palavra de dados (11 bits) é de 572.9 us (11 x (1 / 19200)) portanto, para identificar um início e/ou término de framing, não deve haver transmissão por um período mínimo de (^) 2.005 ms (3.5 x 572.9 us).

Para o restante da mensagem são aceitos todos os caracteres hexadecimais. Os dispositivos ficam monitorando o barramento e checando intervalos silent que, após detectados, dá início à recepção da mensagem, de maneira similar ao modo ASCII. Após a recepção de toda a mensagem, deve ser gerado pelo mestre um intervalo silent similar ao do início da mensagem, caracterizando o fim da mesma.

Neste modo, toda a mensagem deve ser enviada de maneira contínua. Se um intervalo maior que 1.5 vezes o tamanho da palavra de dados for detectado antes que toda a mensagem tenha sido recebida, o escravo descarta os dados já recebidos da mensagem atual e assume que o próximo caracter será o campo de endereço de uma nova mensagem. De modo similar, se uma nova mensagem for recebida em um intervalo menor que o intervalo silent, o escravo assume que esta mensagem é uma continuação da última mensagem recebida. Esta condição irá gerar um erro pois o campo CRC não corresponderá aos dados enviados na mensagem. A seguir é mostrado um framing típico no modoRTU.

Início de framing

Endereço do Escravo

Função ModBus

Dados para o Escravo

Checksum Fim de framing TInício 1 char 1 char N chars CRC - CRC + TFim

Os campos Endereço do Indicador e Função ModBus possuem um único byte ao invés de 2 como no modo ASCII) e outra particularidade está na sequência de envio dos bytes de checksum da mensagem. O primeiro byte enviado é o menos significativo e depois o mais significativo.

O exemplo a seguir utiliza os mesmos valores do exemplo empregado no modo ASCII:

• endereço do indicador: 69 = 45H
• função ModBus: leitura de registradores: 03 = 03H
• registrador inicial a ser lido: 11 = 0BH – pela norma ModBus: 000AH
• número total de registradores a serem lidos: 1 = 0001H
• Checksum (CRC) gerado: 19627 = 4CABH – pela norma ModBus RTU = ABH 4CH

Para os valores acima será gerado o seguinte framing de dados:

45H 03H 00H 0AH 00H 01H ABH 4CH

3.7.2. Comandos com erro

Quando o mestre envia uma mensagem para um escravo, é esperada uma resposta normal porém, pode ocorrer uma das seguintes possibilidades:

• se o escravo receber uma mensagem sem nenhum tipo de erro de comunicação e a mesma poder ser tratada corretamente, o escrevo reponde ao mestre os dados pertinentes ao comando recebido;
• se o escravo não receber a mensagem devido a um erro de comunicação, nenhuma mensagem é retornada ao mestre e provavelmente o mestre executará um procedimento de time-out;
• se o escravo receber uma mensagem mas detectar que houve um erro de comunicação (framing, checksum), nenhuma mensagem é retornada ao mestre e provavelmente o mestre executará um procedimento de time-out;
• se o escravo receber uma mensagem sem erro de comunicação mas não puder atendê-la, ele retornará uma mensagem de exception informando ao mestre a natureza do erro;

As mensagens de exception possuem dois campos que a diferenciam de uma mensagem normal.

3.7.2.1. Campo Código da Função

Em uma resposta normal, o escravo repete o código da função no respectivo campo da sua mensagem, sendo que nestes casos, todos os códigos possuem o bit mais significativo igual a 0. Quando ocorre um erro, porém, este mesmo bit passa a ter valor igual a 1 caracterizando uma resposta com exception. Uma vez detectada, o mestre passa a analisar o próximo campo da mensagem, Campo de Dados, que deve conter o código do motivo que originou a exception.

3.7.2.2. Campo de Dados

Em mensagens sem erro o escravo utiliza este campo para retornar informações pertinentes ao comando solicitado. Quando ocorre um erro, este campo contém o código da causa da exception. A seguir estão relacionados os códigos de exception e os respectivos significados.

código identificação Significado 1 Função inválida A função ModBus solicitada pelo mestre não está implementada pelo escravo. 2 Sensor ou registrador inválido O escravo não possui o(s) sensor(es) ou registrador(es) especificado(s) no comando enviado pelo mestre. 3 Valor de dado inválido O valor de algum dado(s) contido no Campo de Dados é inválido. 4 Falha no dispositivo Ocorrência de erro por parte do escravo durante a execução do comando solicitado pelo mestre. 5 Estado de espera O escravo reconheceu o comando enviado pelo mestre mas o notifica de que o mesmo será processado num período de tempo maior que o normal. Este tipo de código é enviado para evitar a ocorrência de time-out por parte do mestre. Nestas condições, o mestre pode ficar monitorando as atividades do escravo até a realização do comando. 6 Dispositivo ocupado O escravo está ocupado atendendo a outro comando. O mestre pode retransmitir a mensagem mais tarde quando o escravo já tiver completado o comando em execução. 7 Não reconhecimento O escravo não conseguiu executar o comando. É gerado quando o mestre envia um comando através das funções 13 ou 14. 8 Erro de paridade na memória O escravo detectou erro de paridade na leitura da sua memória estendida.

O exemplo a seguir adota o modo de comunicação RTU. O mestre envia um comando para o escravo número 69H da rede, solicitando que seja programado o seu registrador 0058H com o valor 05AFH. A mensagem enviada para este comando é a seguinte:

69H 06H 00H 58H 05H AFH 43H DDH

onde:

• 69H = endereço do escravo
• 06H = código da função ModBus de escrita em um único registrador
• 00H 58H = número do registrador interno do escravo
• 05H AFH = valor a ser programado no registrador 0058H do escravo
• 43H DDH = checksum da mensagem enviada pelo mestre

Antes de executar o comando de escrita, o escravo identifica que não existe o registrador 0058H em seu dispositivo e retorna a seguinte mensagem de exception:

69H 86H 02H 42H 7DH

O bit de paridade porém, não garante que não houve erro na transmissão de um caracter. Suponha que o mesmo caracter enviado: 0111 1011 seja recebido com o valor 0001 1011. A quantidade de bits em nível 1 permanece a mesma , ou seja, PAR, mas ocorreu uma alteração do conteúdo durante a transmissão, portanto, a ocorrência de um erro, mas não detectado pelo método de checagem da paridade. Para contornar este problema, foram desenvolvidos métodos que analisam não o caracter isoladamente nas toda a mensagem , garantindo assim uma maior integridade na checagem dos dados transmitidos.

Quando é configurada a opção SEM paridade, o bit de paridade não é transmitido e sim, um STOP BIT adicional, para manter a quantidade de bits da palavra de dados: 10 bits no modo ASCII e 11 bits no modo RTU.

3.8.2. Checagem do framing - LRC

Quando é utilizado o modo de transmissão ASCII, o método de cálculo de checksum adotado é o LRC, Longitudinal Redundancy Check, que calcula o conteúdo dos campos da mensagem exceto os caracteres de identificação de início: 3AH - e fim de mensagem: 0DH / 0AH.

O valor gerado por este cálculo é de 8 bits portanto, possui dois caracteres ASCII para representá- lo, sendo que na composição final do campo, o caracter mais significativo é enviado primeiro. Este é o penúltimo campo da mensagem antes do identificador de término da mesma. O escravo realiza o cálculo do LRC durante a recepção da mensagem e ao final, compara seu valor com o do LRC enviado no campo de checksum do mestre. Se não forem iguais caracteriza-se um erro de comunicação, não sendo gerada mensagem de exception e o sistema aguarda a ocorrência do time-out.

O LRC é calculado adicionando-se sucessivamente os 8 bits dos campos da mensagem, descartando-se eventuais bits de estouro ( carry/overflow bits ), e submetendo o^ resultado final à lógica de complemento de dois. Como o LRC é um valor de 8 bits , é quase certo que a soma sucessiva dos bytes exceda o valor máximo de 255: 1111 1111. Como não há o nono bit para o cálculo do LRC, este é simplesmente descartado.

Apesar de eficiente, não é um método seguro pois analisa apenas os valores dos campos e não o que realmente é enviado na mensagem, (^) fisicamente falando. No exemplo do (^) item 3.4.1 , não é feita a soma dos bytes 34H e 35H , relativos ao Campo de Endereço, ao invés, considera-se o seu valor numérico, ou seja, 69 decimal. O mesmo ocorre para o campo Função ModBus. Já nos campos Endereço do Registrador Inicial: 30H 30H 30H 41H e Quantidade de Registradores: 30H 30H 30H 31H, campos de 16 bits, soma-se individualmente seus valores numéricos dos 8 bits mais significativos e em seguida, os menos significativos, ou seja, (0 + 10) e (0 + 1).

Como regra geral, o procedimento para o cálculo do LRC é o seguinte:

1. adiciona-se todos os bytes dos campos da mensagem, exceto os campos de Início e Fim de mensagem, descartando-se todos os bits de estouro;
2. subtrai-se o valor obtido na soma do item 1 de 255 decimal (FFH), que nada mais é do que o método complemento de 1 , que resulta na inversão simples dos valores dos bits;
3. adiciona-se 1 ao valor obtido no item 2, caracterizando o complemento de 2.

Para ilustrar melhor o cálculo do LRC, analisemos a seguinte mensagem e os campos a serem somados:

3AH 34H 35H 30H 33H 30H 30H 30H 41H 30H 30H 30H 31H 41H 44H 0DH 0AH

1. soma sucessiva:

Campo analisado Valores em HEXA Valor a ser somado

Campo de Endereço 34H 35H (^) 69 / 45H

Campo Função ModBus 30H 33H 3 / 03H

Endereço Registrador Inicial (+) 30H 30H 0 / 00H

Endereço Registrador Inicial (-) 30H 41H 10 / 0AH

Quantidade de Registradores (+) 30H 30H 0 / 00H

Quantidade de Registradores (-) 30H 31H 1 / 01H

Valor resultante da soma 83 / 53H

2. complemento de 1:

FFH – 53H = ACH

3. complemento de 2:

ACH + 01H = ADH

Como o modo de transmissão é o ASCII, o valor do LRC calculado ADH equivale a 41H, que representa a letra A e 44H, que representa a letra D.

3.8.3. Checagem do framing - CRC

No modo RTU, o cálculo de checksum adotado é o CRC, Cyclical Redundandcy Chceck, que calcula o conteúdo de (^) toda a mensagem. É gerado um valor de 16 bits sendo que na composição final desde campo, os 8 bits menos significativos são enviados primeiro. Este é o último campo da mensagem sendo que os 8 bits mais significativos representam o último byte da mensagem.

O dispositivo transmissor calcula o valor do CRC e o integra à mensagem, transmitindo-a em seguida ao dispositivo receptor, que por sua vez, recalcula o CRC de toda a mensagem após a sua total recepção e o compara ao campo CRC da mensagem enviada, sinalizando erro caso não sejam iguais.

Este método, apesar de levar mais tempo para ser executado em relação ao método LRC, é muito mais confiável pois, como será visto a seguir, analisa o real conteúdo dos dados, bit a bit , que estão sendo transferidos na linha de comunicação, fisicamente falando.

O cálculo do CRC é iniciado primeiramente carregando-se um registrador / variável de memória (referenciado de agora em diante simplesmente como (^) registrador CRC ) de 16 bits com valor FFFFH. Apenas os 8 bits menos significativos deste registrador CRC serão utilizados para o cálculo efetivo do CRC. Os bits de configuração: start, paridade e stop bits, não são utilizados no cálculo do CRC, apenas os bits do caracter propriamente dito.

Durante a geração do CRC, cada caracter é submetido a uma lógica XOR (OU exclusivo) com os 8 bits menos significativos do registrador CRC, cujo resultado é retornado a ele mesmo e (^) deslocado (não é rotacionado) uma posição (1 bit) à direita , em direção ao bit menos significativo, sendo que a posição do bit mais significativo é preenchida com valor 0 (zero). Após esta operação, o bit menos significativo é examinado, ocorrendo o seguinte processamento:

1. se o valor deste bit for igual a 0, nada ocorre e a rotina de cálculo do CRC continua normalmente;

7. após este processo, os registradores CRC + e CRC – já possuem os respectivos valores a serem programados no Campo Checksum da mensagem.

Tabela CRC +

0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41, 0x00,0xC1,0x81,0x40,0x01,0xC0,0x80,0x41,0x01,0xC0,0x80,0x41,0x00,0xC1,0x81,0x40,

Tabela CRC –

0x00,0xC0,0xC1,0x01,0xC3,0x03,0x02,0xC2,0xC6,0x06,0x07,0xC7,0x05,0xC5,0xC4,0x04, 0xCC,0x0C,0x0D,0xCD,0x0F,0xCF,0xCE,0x0E,0x0A,0xCA,0xCB,0x0B,0xC9,0x09,0x08,0xC8, 0xD8,0x18,0x19,0xD9,0x1B,0xDB,0xDA,0x1A,0x1E,0xDE,0xDF,0x1F,0xDD,0x1D,0x1C,0xDC, 0x14,0xD4,0xD5,0x15,0xD7,0x17,0x16,0xD6,0xD2,0x12,0x13,0xD3,0x11,0xD1,0xD0,0x10, 0xF0,0x30,0x31,0xF1,0x33,0xF3,0xF2,0x32,0x36,0xF6,0xF7,0x37,0xF5,0x35,0x34,0xF4, 0x3C,0xFC,0xFD,0x3D,0xFF,0x3F,0x3E,0xFE,0xFA,0x3A,0x3B,0xFB,0x39,0xF9,0xF8,0x38, 0x28,0xE8,0xE9,0x29,0xEB,0x2B,0x2A,0xEA,0xEE,0x2E,0x2F,0xEF,0x2D,0xED,0xEC,0x2C, 0xE4,0x24,0x25,0xE5,0x27,0xE7,0xE6,0x26,0x22,0xE2,0xE3,0x23,0xE1,0x21,0x20,0xE0, 0xA0,0x60,0x61,0xA1,0x63,0xA3,0xA2,0x62,0x66,0xA6,0xA7,0x67,0xA5,0x65,0x64,0xA4, 0x6C,0xAC,0xAD,0x6D,0xAF,0x6F,0x6E,0xAE,0xAA,0x6A,0x6B,0xAB,0x69,0xA9,0xA8,0x68, 0x78,0xB8,0xB9,0x79,0xBB,0x7B,0x7A,0xBA,0xBE,0x7E,0x7F,0xBF,0x7D,0xBD,0xBC,0x7C, 0xB4,0x74,0x75,0xB5,0x77,0xB7,0xB6,0x76,0x72,0xB2,0xB3,0x73,0xB1,0x71,0x70,0xB0, 0x50,0x90,0x91,0x51,0x93,0x53,0x52,0x92,0x96,0x56,0x57,0x97,0x55,0x95,0x94,0x54, 0x9C,0x5C,0x5D,0x9D,0x5F,0x9F,0x9E,0x5E,0x5A,0x9A,0x9B,0x5B,0x99,0x59,0x58,0x98, 0x88,0x48,0x49,0x89,0x4B,0x8B,0x8A,0x4A,0x4E,0x8E,0x8F,0x4F,0x8D,0x4D,0x4C,0x8C, 0x44,0x84,0x85,0x45,0x87,0x47,0x46,0x86,0x82,0x42,0x43,0x83,0x41,0x81,0x80,0x40,

4. Funções ModBus

Existem diversas funções ModBus disponíveis, de acordo com o modelo de CLP utilizado. Os indicadores da ALFA, entretanto, estão programados para reconhecer apenas as que realizam os comandos pertinentes à pesagem de maneira mais rápida e eficaz. Serão descritas em detalhes apenas estas funções, nos modos ASCII e RTU mas antes, é necessário saber como os dados são referenciados no protocolo ModBus.

4.1. Codificação do endereço

Todos os dados relativos a endereçamento têm o zero como referência, ou seja, se o registrador do dispositivo estiver no endereço 0001H, seu endereço na mensagem ModBus será o 0000H, e assim sucessivamente. Tomemos o exemplo do item 3.7.2.2.

Na realidade, o registrador que será programado no dispositivo é o de número 0059H porém, como ele, o registrador, está sendo acessado através do protocolo ModBus, o mesmo deve ser referenciado como número 0058H na mensagem. O mesmo ocorre para os sensores e demais registradores de acesso do dispositivo.

Nos indicadores da ALFA, todos os registradores são do tipo holding , ou seja, podem tanto ser acessados para leitura como para escrita e, segundo os padrões da Modicon, estes registradores são numerados a partir do endereço (^) 40001 , cujo endereço correspondente na mensagem é 0000H. Recorrendo uma vez mais ao exemplo do item 3.7.2.2 , o registrador 0058H, na realidade, possui valor 40089, em decimal.

4.2. Conteúdo dos campos

A seguir é mostrado um exemplo de um comando e resposta, tanto em modo ASCII como em RTU. O mestre envia um comando de (^) leitura de registradores tipo holding para o dispositivo escravo número 7BH, desejando ler o conteúdo dos registradores 40108 à 40110, portanto, um total de 3 registradores. Note que na mensagem o endereço do registrador inicial é 0107 decimal, equivalente a 006BH.

Na resposta, o escravo repete o código da função ModBus, indicando que o comando foi executado com sucesso. O campo Byte Count especifica quantos bytes estão sendo retornados ao mestre. No modo ASCII seu valor é igual à metade dos caracteres enviados no (^) Campo de Dados , ou seja, para cada quatro bits é necessário o envio de um caracter ASCII portanto, para cada byte de dado são enviados dois caracteres ASCII.

No exemplo, um dos dados lidos possui valor 7BH. No modo RTU é enviado este mesmo valor: 01111011, pois é uma grandeza de 8 bits. Já no modo ASCII, são enviados dois caracteres para representar este valor: 37H - 00110111, que equivale ao número 7 em ASCII e 42H - 01000010, que equivale à (^) letra B em ASCII. Neste caso, apesar de serem enviados dois caracteres para cada dado, totalizando portanto 12 bytes, o campo Byte Count deve conter a metade da quantidade real enviada.

Mensagem response :

Nome do campo Valores em HEXA Caracteres ASCII Bytes em RTU

Identificador de início (^) : NÃO HÁ

Endereço do escravo 7BH 7 B 0111 1011

Função ModBus 03H 0 3 0000 0011

Campo Byte Count 06H 0 6 0000 0110

Dado do 1º registrador (+) 00H 0 0 0000 0000

Dado do 1º registrador (-) 5FH 5 F 0101 1111

Dado do 2º registrador (+) 01H 0 1 0000 0001

Dado do 2º registrador (-) A8H A 8 1010 1000

Dado do 3º registrador (+) 3CH 3 C 0011 1100

Dado do 3º registrador (-) 69H 6 9 0110 1001

Checksum caracter 1

Checksum caracter 2

C

F

Indicador de fim CR LF NÃO HÁ

Total de bytes enviados 23 11

Conteúdo em hexa da mensagem response no modo ASCII :

3AH 37H^ 42H^ 30H 33H 30H^ 36H^ 30H 30H 35H 46H 30H^ 31H^ 41H^ 38H 33H 43H 36H 39H 43H^ 46H^ 0DH 0AH

Conteúdo em hexa da mensagem response no modo RTU :

7BH 03H 06H 00H 5FH 01H A8H 3CH 69H FFH 28H

4.3. Leitura de Bloco de Registradores – Função 03

4.3.1. Descrição

Lê o conteúdo de um bloco de registradores tipo holding (referenciados como 4XXXX). Para este comando não são válidos acessos tipo broadcast.

4.3.2. Comando enviado

A mensagem query especifica o registrador inicial e a quantidade de registradores a serem lidos. Lembrar que os registradores são endereçados a partir do endereço 0, ou seja, os registradores 1 à 99, são endereçados como 0 à 98. No exemplo a seguir é solicitada uma leitura dos registradores 40108 à 40110 do dispositivo 17.

Observe que as informações relativas aos registradores são formatadas em 2 bytes sendo que o primeiro byte contém a parte mais significativa da informação.

Nome do campo Valores em HEXA Caracteres ASCII Bytes em RTU

Identificador de início : NÃO HÁ

Endereço do escravo 11H 1 1 0001 0001

Função ModBus 03H 0 3 0000 0011

Endereço inicial (+) 00H 0 0 0000 0000

Endereço inicial (-) 6BH 6 B 0110 1011

No. de registradores (+) 00H 0 0 0000 0000

No. de registradores (-) 03H 0 3 0000 0011

Checksum caracter 1

Checksum caracter 2

E

Indicador de fim CR LF NÃO HÁ

Total de bytes enviados 17 8

Conteúdo em hexa da mensagem query no modo ASCII :

3AH 31H 31H 30H 33H 30H 30H 36H 4BH 30H 30H 30H 33H 37H 45H 0DH 0AH

Conteúdo em hexa da mensagem query no modo RTU :

11H 03H^ 00H 6BH 00H^ 03H^ 76H 87H

4.3.3. Resposta ao comando

Na resposta, os dados dos registradores também são formatados em 2 bytes sendo que o primeiro byte contém a parte mais significativa do dado.