Configuração por Strings

Driver Modicon Modbus

Configuração por Strings

Topo  Anterior  Próximo

A configuração por Strings de Tags de Comunicação é realizada usando os campos Dispositivo e Item de cada Tag.

Este novo método de configuração não funciona no Elipse SCADA, que usa o antigo método de configuração numérica (parâmetros N e B).

Os parâmetros N e B não são usados na configuração por Strings e devem ser deixados em 0 (zero).

A configuração por Strings torna a configuração dos Tags mais legível, facilitando a configuração e manutenção das aplicações.

 

Leitura em Bloco

Os Tags configurados por Strings podem ser Tags simples ou Tags Bloco, com os campos Dispositivo e Item tendo a mesma sintaxe.

 

NOTA

O serviço de agrupamento de Tags realizado pelos Superblocos não está disponível para os Tags que utilizam a configuração por Strings. Se houver necessidade de otimização através da leitura de superblocos, os Tags da aplicação devem utilizar somente a Configuração Numérica.

 

Campo Dispositivo

No campo Dispositivo, o Slave Id (endereço identificador do equipamento) deve ser fornecido como um número entre 1 (um) e 255 seguido de dois pontos, como por exemplo "1:", "101:", "225:", etc.

Cabe lembrar que, no protocolo Modbus, o Slave Id 255 é reservado para broadcast, o que só faz sentido ser usado para operações de escrita, pois não há retorno dos equipamentos, ou ocorreriam conflitos.

Opcionalmente, o Slave Id pode aparecer no início do campo Item, explicado a seguir, e neste caso o campo Dispositivo deve ser mantido vazio. Esta opção é detalhada a seguir.

 

Campo Item

No campo Item devem ser fornecidas todas as demais informações de endereçamento e da operação a ser realizada pelo Tag, com a seguinte a sintaxe:

<espaço de endereçamento><endereço>[.<tipo>[<tam. do tipo>]][.<byte order>][/bit]

 

Onde os parâmetros entre colchetes são opcionais.

Como já mencionado na seção anterior, pode-se opcionalmente adicionar o Slave Id no início do campo Item, como no exemplo a seguir:

<slave id>:<espaço de endereçamento><endereço>[.<tipo>[<tam. do tipo>]][.<byte order>][/bit]

 

Neste caso, como já explicado, deve-se deixar o campo Dispositivo vazio.

Os exemplos a seguir mostram os casos de uso mais comuns (note que as aspas duplas não devem ser adicionadas no supervisório):

1.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 100 do equipamento com Id 1 e com Slave Id no campo Dispositivo:

a.Dispositivo: "1:"

b.Item: "hr100"

2.Leitura ou escrita de Holding Register (funções 03 e 16) de endereço 120 do equipamento com Id 3 e com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "3:hr120"

3.Leitura ou escrita de Coil (funções 01 e 15) de endereço 65535 (FFFFh) com Slave Id 4, aqui especificado no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "4:cl&hFFFF" (ou opcionalmente "4:cl65535")

 

A figura a seguir mostra exemplos de Tags do Tutorial do E3 configurados por Strings.

Tags do Tutorial do E3 configurados por Strings

Tags do Tutorial do E3 configurados por Strings

Campos Obrigatórios e Opcionais

Os campos obrigatórios para todos os Tags são enumerados a seguir e detalhados individualmente mais adiante neste mesmo tópico:

1.Espaço de endereçamento: Mnemônico que define o conjunto de funções de leitura e escrita do protocolo a utilizar (veja a tabela em seção específica, mais adiante neste mesmo tópico).

2.Endereço: Valor numérico identificando o endereço do item (registrador ou bit) a ler ou escrever dentro do espaço de endereçamento definido. Os valores podem ser fornecidos em decimal, hexadecimal ou octal. Para valores em decimal não é preciso adicionar prefixo, ou pode ser usado o prefixo "&d". Para valores em hexadecimal, adicione o prefixo "&h" (por exemplo, "&hFFFF"). Já para octal, use o prefixo "&o" (por exemplo, "&o843"). Este endereço pode ter um deslocamento (offset) em relação ao endereço realmente enviado no frame de comunicação, o que depende da convenção utilizada pelo fabricante. Em caso de dúvidas sobre as convenções de endereçamento, consulte o tópico Dicas de Endereçamento (Modbus Convention). Em especial, verifique se o equipamento implementa o offset padrão do Data Model do protocolo (veja as opções de Data Address Model Offset na aba Modbus).

 

Já os campos enumerados a seguir são opcionais, usados para extensões ao protocolo padrão ou para compatibilidade com equipamentos que não sejam plenamente aderentes ao protocolo (são também melhor detalhados mais adiante):

1.Tipo: Define como os bytes da área de dados do frame de comunicação devem ser interpretados. Se for omitido, são usados os tipos padrão definidos pelo protocolo para as funções em uso, ou seja, Word para funções de acesso a registradores e Bit para funções de acesso a dados digitais (Coils e Discrete Inputs). Consulte a tabela de mnemônicos dos tipos suportados, mais adiante neste tópico.

2.Tamanho do tipo: É necessário especificar este campo apenas para os tipos de tamanho variável, como BCD e String. O valor numérico indica o tamanho do tipo em bytes.

3.Byte order: Mnemônico indicando o ordenamento dos bytes dos valores numéricos. Se omitido, é usado o padrão do protocolo, com os bytes mais significativos vindo primeiro no frame de comunicação, o chamado big endian. Veja mais informações na seção específica sobre esta opção, mais adiante neste tópico.

4.Bit: Permite retornar um bit específico de um valor inteiro, e obviamente só faz sentido em funções Modbus que retornem valores inteiros (Words). Em geral recomenda-se não usar este recurso, dando preferência ao mapeamento de bits do supervisório. O bit 1 (um) é o menos significativo e, quanto maior o valor, mais significativo é o bit. O valor máximo permitido obviamente depende do tamanho do tipo, sendo o máximo atualmente de 64 para tipos Double. Este campo corresponde à antiga opção Use Bit Mask da configuração numérica. Mais informações sobre esta opção podem ser obtidas no tópico Aba Operations.

 

Exceções

As funções Modbus 20 e 21 do protocolo Modbus, que acessam arquivos, utilizam sintaxe ligeiramente diferente da mostrada anteriormente:

fr<arquivo>.<registro>[.<tipo>[<tam. do tipo>]][.<byte order>][/bit]

 

Exemplo:

·Dispositivo: "" (String vazia)

·Item: "1:fr4.101" (leitura do registro 101 do arquivo 4 no Slave Id 1)

 

Especificamente para a função especial GenSOE (Elipse Generic SOE):

elsoe<N>.<end. inicial>[.<tipo>[<tam. do tipo>]][.<byte order>][/bit]

 

Especificamente para a função especial SP SOE (Sepam SOE), para leitura de todos os eventos:

spsoe<tipo do evento>.<end. inicial>[.<tipo>][.<byte order>][/bit]

 

Especificamente para a função especial SP SOE (Sepam SOE), para a leitura de eventos de pontos específicos:

ptspsoe<tipo do evento>.<end. do evento>

 

Especificamente para a função especial GE SOE (GE PAC RX7 SOE):

gesoe<tipo do tag + índice do ponto>.<end. base da pilha>

 

Consulte os tópicos específicos sobre as funções especiais mencionadas anteriormente para mais informações sobre a configuração dos respectivos Tags usando Strings.

 

Espaço de Endereçamento

Ao invés de definir explicitamente as funções Modbus ou especiais de leitura e escrita a serem utilizadas, como ocorre na antiga configuração numérica e seu conceito de operações, na configuração por Strings o usuário define um espaço de endereçamento através de um dos mnemônicos listados na tabela a seguir, já associado a funções pré-definidas do protocolo e seus respectivos tipos nativos de dados.

Espaços de endereçamento e mnemônicos

Espaço de Endereçamento

Mnemônico

Tipo Nativo

Função

Comentários

Holding Register

hr

Word (16 bits)

Funções 03 e 16

As funções 03 e 16 são as mais usadas do protocolo (Modbus classe 0)

Single Holding Register

shr

Word (16 bits)

Funções 03 e 06

A função 06 escreve nos mesmos registradores da função 16, a diferença é que a função 16 pode escrever em Blocos, enquanto a função 06 escreve em apenas um registro por vez, mas com menor overhead

Coil

cl

Bit

Funções 01 e 15

 

Single Coil

scl

Bit

Funções 01 e 05

A função 05 escreve nos mesmos registros da função 15, porém não pode escrever em Blocos, portanto com menor overhead

Discrete Input

di

Bit

Funções 02 e None (somente leitura)

 

Input Register

ir

Word (16 bits)

Funções 04 e None (somente leitura)

 

Exception Status

es

Byte

Funções 07 e None (somente leitura)

 

File Register

fr

Word (16 bits)

Funções 20 e 21

 

ABB MGE 144 - Leitura de Memória de Massa

abbmge

Word (16 bits)

Funções 65 03 e None (somente leitura)

 

ABB MGE 144 - Reset

abbmge.rst

Não usado

Função de leitura None e de escrita 65 01

 

ABB MGE 144 - Zera Memória de Máximos e Mínimos

abbmge.rstmxmn

Não usado

Função de leitura None e de escrita 65 02

 

GE PAC RX7 SOE - Leitura

gesoe

GE_events

Função de leitura GE SOE e de escrita None

 

SEPAM SOE Events

spsoe

SP_events

Função de leitura SP SOE e de escrita None

Coleta do medidor e retorna ao Tag uma estrutura (tipo SP_events) com eventos de quaisquer pontos (veja o tópico SEPAM SOE)

SEPAM SOE Single Point Events

ptspsoe

Int32

Função de leitura SP SOE e de escrita None

Coleta do medidor e retorna ao Tag um valor inteiro do campo Edge, relativo a eventos de um ponto específico (veja o tópico SEPAM SOE)

Elipse Generic SOE

elsoe

Word (16 bits)

Função de leitura Gen SOE (função Modbus 03 com algoritmos adicionais) e de escrita 16

 

 

Tipos de Dados

Na tabela da seção anterior são listados os tipos de dados nativos do protocolo, conforme as funções Modbus utilizadas, bem como alguns tipos de dados específicos usados em funções especiais (não padrão do protocolo). Para Tags que retornem estes tipos de dados nativos, o parâmetro Tipo de Dado pode ser omitido da String do campo Item.

Caso seja necessário interpretar os dados nativos de outra forma, algo muito comum entre os equipamentos que usam Modbus, deve-se especificar o tipo de dados a ser usado, conforme explicado nesta seção.

A lista e o detalhamento de todos os tipos de dados suportados por este Driver pode ser consultada no tópico Tipos de Dados Suportados.

A tabela a seguir lista os mnemônicos usados no parâmetro <tipo> do campo Item para cada tipo de dados suportado, nativo do Driver, e também um alias ou nome alternativo.

Tipos de dados suportados

Tipo

Mnemônico

Alias

Char

char

ch

Byte

byte

by ou u8

Int8

int8

i8

Int16

int16

i16

Int32

int32

i32

Word ou UInt

word

u16

DWord ou ULong

dword

u32

Float

float

f

Float_GE

float_GE

fge

Double ou Real

double

d

String

string

s

BCD

BCD

bcd

GenTime

GenTime

gtm

Sp_time

Sp_time

sptm

UTC64d

UTC64d

-

UTC32

UTC32

-

 

Tipos de Dados Criados pelo Usuário

Além dos tipos de dados listados na tabela anterior, usuários podem também fornecer mnemônicos de tipos de dados criados pelo usuário ou estruturas (veja o tópico Tipos de Dados Definidos pelo Usuário).

Para que os tipos de dados definidos pelo usuário possam ser usados no campo Item, entretanto, é preciso que os nomes destes tipos de dados não se diferenciem apenas por maiúsculas e minúsculas, uma vez que o campo Item não leva em conta caixa alta ou baixa. Se isto ocorrer, o Driver não permite o uso destes tipos de dados no campo Item (veja o tópico Tipos de Dados Definidos pelo Usuário).

 

Exemplos

1.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 100 do equipamento com Id 1, interpretado como um DWord, com Slave Id no campo Dispositivo:

a.Dispositivo: "1:"

b.Item: "hr100.u32" ou "hr100.dword", ou se for conveniente usar hexadecimal, "hr&h64.u32"

2.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 150 do equipamento com Id 3, interpretado como um Float, com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "3:hr150.f" ou "3:hr150.float" ou em hexadecimal "3:hr&h96.f"

3.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 1500 do equipamento com Id 5, interpretado como um Double, com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:hr1500.d" ou "5:hr1500.double" ou ainda, se for conveniente endereçar em hexadecimal, "5:hr&h5DC.d"

4.Leitura ou escrita de Holding Registers (funções 03 e 06) de endereço 100 do equipamento com Id 5, interpretado como um Word, com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:shr100" ou "5:shr100.u16" ou "5:shr100.word". Note que, por ser um Word, o tipo de dados nativo do protocolo Modbus para Holding Registers, o tipo de dados pode ser omitido

5.Leitura ou escrita de Holding Registers (funções 03 e 06) de endereço 100 do equipamento com Id 5, interpretado como o tipo de dados do usuário chamado "mytype", com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:shr100.mytype"

 

NOTA

O espaço de endereçamento de Holding Registers no protocolo Modbus contém registros de 16 bits. Portanto, para a leitura de tipos de dados de 32 bits, como DWord ou Float, é necessário ler dois endereços de "hr" para cada Tag acessado. Da mesma forma, a leitura de um Tag do tipo Double exige a leitura de quatro endereços de Holding Registers. Pelos mesmos motivos, a leitura e escrita de Tags de "hr" de tipo Byte só pode ser realizada aos pares. No equipamento, cada endereço de Holding Register contém sempre dois bytes.

 

Tamanho do Tipo de Dados

Os tipos de dados BCD e String, por possuírem tamanho variável, exigem a especificação do tamanho do tipo de dados (type size), em bytes, logo após o tipo.

Cabe lembrar que são válidos apenas os tipos de dados 2 e 4 (2 e 4 bytes ou 4 e 8 dígitos) para os tipos de dados BCD. Exemplos:

1.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 100 do equipamento com Id 1, interpretado como uma String de 10 bytes (cinco registros "hr"), com Slave Id no campo Dispositivo:

a.Dispositivo: "1:"

b.Item: "hr100.s10"

2.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 100 do equipamento com Id 1, interpretado como BCD de oito dígitos (quatro bytes ou dois registros "hr"), com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "1:hr100.bcd4"

 

Ordenamento de Bytes (Byte Order)

Como mostrado nas sintaxes da seção anterior, pode-se adicionar o parâmetro opcional byte order no campo Item dos Tags para especificar o ordenamento de bytes para equipamentos que não seguem o padrão do protocolo. Se o equipamento segue o ordenamento padrão do protocolo Modbus, este campo pode ser omitido.

Caso ocorram leituras de valores distorcidos, o que pode ser observado já nos primeiros testes com o equipamento, e se estes valores, convertidos para hexadecimal, se mostrarem corretos com a inversão da posição de alguns bytes, leia esta seção atentamente.

O protocolo Modbus utiliza por padrão o formato big endian, onde os valores são formatados com os bytes mais significativos vindo primeiro nos frames de comunicação. Este é o formato que este Driver usa como padrão. Existe, entretanto, um grande número de equipamentos no mercado que se utilizam de valores com outras combinações de ordenamento dos bytes.

Como exemplo, se o Driver lê um valor igual a "1234h" (ou "4660" em decimal), por padrão o Driver espera que o dado seja enviado com a sequência de bytes 12h e 34h. Se entretanto o equipamento usa o padrão inverso, chamado de little endian, é enviado primeiro o byte 34h e depois o 12h, e o Driver pode interpretá-lo como 3412h, ou 13330 em decimal, a não ser que os dois bytes tenham sua ordem invertida antes de sua interpretação.

No caso de valores de 32 bits pode também ocorrer de valores em Word permutados (swapped), porém com os bytes dentro dos valores em Word mantendo a ordem padrão. Por exemplo, o valor 12345678h pode vir como 56781234h. E há vários outros casos, com inúmeras combinações diferentes de ordenamento.

Para permitir a comunicação com estes equipamentos que não seguem o padrão do protocolo de ordenamento de bytes, o Driver permite ao usuário configurar Tags especificando o padrão a ser utilizado.

O parâmetro byte order corresponde às opções de swap das operações, utilizadas antigamente na configuração numérica, e pode ter os valores "b0", "b1", "b2", "b3", "b4", "b5", "b6", "b7", "alias" ou ainda "alias2" (veja a tabela a seguir).

Se o parâmetro byte order for omitido, o dado é interpretado seguindo o padrão do protocolo, o que equivale ao código "b0".

A tabela a seguir indica que operações de swap ou permutas (Swap Bytes, Swap Words e Swap DWords) são realizadas para cada mnemônico de ordenamento (de "b0" até "b7").

Operações de permuta ou swap

 

Swap Bytes

Swap Words

Swap DWords

Alias

Alias 2 (Swaps)

Ordenamento *

b0

 

 

 

msb

-

by7 by6 by5 by4 by3 by2 by1 by0

b1

X

 

 

-

sb

by6 by7 by4 by5 by2 by3 by0 by1

b2

 

X

 

-

sw

by5 by4 by7 by6 by1 by0 by3 by2

b3

X

X

 

-

sb.sw

by4 by5 by6 by7 by0 by1 by2 by3

b4

 

 

X

-

sdw

by3 by2 by1 by0 by7 by6 by5 by4

b5

X

 

X

-

sb.sdw

by2 by3 by0 by1 by6 by7 by4 by5

b6

 

X

X

-

sw.sdw

by1 by0 by3 by2 by5 by4 by7 by6

b7

X

X

X

lsb

sb.sw.sdw

by0 by1 by2 by3 by4 by5 by6 by7

* 64 bits (onde "by0" é "lsb" e "b7" é "msb")

Ou seja, "b0" não realiza nenhuma operação de permuta nos bytes de dados, mantendo o ordenamento de bytes original recebido do equipamento, equivalente a não selecionar nenhuma opção de permuta na aba Operations da antiga configuração numérica.

Já "b1" realiza a permuta dos bytes, dois a dois, ou seja, ao receber um Word (inteiro sem sinal de 16 bits) com o valor em hexadecimal 0102h, o valor que é retornado ao Tag é 0201h, com os bytes trocados. Equivale à antiga opção Swap Bytes.

Já o código "b2" realiza a permuta de Words, ou seja, de duplas de bytes, dois a dois, o que obviamente só afeta dados de 32 bits ou maiores. Tem o mesmo efeito de selecionar a opção Swap Words na configuração numérica. Como exemplo, se for recebido do equipamento o valor 01020304h, o valor utilizado para os Tags da aplicação é 03040102h.

Já se for usado o código "b3", tem-se a troca de bytes e Words, equivalente às antigas opções Swap Bytes e Swap Words habilitadas simultaneamente. Neste caso, o valor 01020304h se torna 04030201h.

Da mesma forma, o código "b4" realiza a troca de DWords entre si em valores de 64 bits, como a antiga opção Swap DWords da configuração numérica, ou seja, o valor 1122334455667788h é interpretado como 5566778811223344h. E assim por diante para os demais códigos.

As duas últimas colunas da tabela especificam apelidos ou aliases que o usuário pode usar para facilitar a legibilidade, ou seja, ao invés de usar o código "b0", pode ser utilizado "msb". Ao invés do código "b6", pode-se utilizar o apelido "sw.sdw", e assim por diante.

 

Como Selecionar a Opção de Ordenamento Correta?

Em muitos casos a documentação do equipamento especifica qual o ordenamento utilizado, ou como configurá-lo (há equipamentos que permitem esta configuração).

Nos casos em que a documentação é omissa, deve-se contatar o suporte do fabricante.

Caso não seja possível obter-se informações confiáveis, deve-se testar empiricamente, analisando os valores retornados, em hexadecimal, comparando com os valores esperados e observando se existem inversões de ordenamento que possam explicar as diferenças.

Podem ocorrer basicamente três situações:

1.Caso o equipamento forneça dados usando o ordenamento de bytes padrão do protocolo Modbus (big endian ou Motorola), com os bytes mais significativos vindo antes, deve-se omitir este parâmetro, ou defini-lo como "b0". Esta é a situação mais comum.

2.Caso o equipamento use outro padrão de ordenamento de bytes, com os bytes menos significativos vindo antes (little endian), é necessário habilitar-se todas as opções de permuta referentes ao tipo de dados usado, o que corresponde ao mnemônico "b7".

3.No caso menos comum, há equipamentos que usam ordenamentos de bytes diferentes para tamanhos de dados diferentes, fornecendo por exemplo o byte mais significativo de cada Word primeiro, porém o Word menos significativo de cada DWord primeiro. Portanto, é preciso avaliar em qual caso cada opção de permuta precisa ser habilitada, de maneira a converter o valor retornado pelo equipamento para o formato big endian padrão do protocolo.

 

NOTA

As opções de permuta citadas não têm efeito para tipos de dados Bit ou tipos com tamanho de oito bits (Byte, Char e Int8). A permuta ocorre dentro de cada tipo de dado, ou seja, a opção Swap Words não tem efeito para tipos de dados de 16 bits, assim como a opção Swap DWords não tem efeito para tipos de dados de 32 bits. Os tipos de dados BCD também não permitem operações de permuta.

 

O tópico Dúvidas Mais Frequentes lista alguns casos conhecidos, já observados nos atendimentos de suporte. Exemplos:

1.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 1500 do equipamento com Id 5, interpretado como um Double sem inversão de bytes, com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:hr1500.d", ou "5:hr1500.double" ou ainda "5:hr1500.d.b0"

2.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 1500 do equipamento com Id 5, interpretado como um Double com o byte menos significativo de cada Word vindo antes e com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:hr1500.d.b1" ou "5:hr1500.double.b1", ou ainda "5:hr1500.double.sb"

3.Leitura ou escrita de Holding Registers (funções 03 e 16) de endereço 1500 do equipamento com Id 5, interpretado como um Double com os bytes menos significativos vindo antes (little endian) e com Slave Id no campo Item:

a.Dispositivo: "" (String vazia)

b.Item: "5:hr1500.d.b7" ou outras variações, como "5:hr1500.d.lsb" e "5:hr1500.d.sb.sw.sdw"

 

Tags Especiais do Driver

Além dos Tags já descritos, pode-se configurar Tags Especiais do Driver usando Strings, descritos em mais detalhes em tópicos específicos (clique no item desejado para mais informações).

Tags especiais

Device

Item

Operação

 

ForceWaitSilence

Escrita

<slave id>:

LastExceptionCode

Leitura ou escrita

 
Esta seção da documentação ajudou você a configurar este Driver?
Sim Não
Comentários (opcional):