<< Clique para Mostrar o Sumário >>   Configuração por Strings

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, por 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, em que os campos Dispositivo e Item têm a mesma sintaxe.

 

Campo Dispositivo

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

Cabe lembrar que, no protocolo Modbus RTU Serial, o Slave Id "0" (zero) é 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 sintaxe a seguir, em que os parâmetros entre colchetes são opcionais.

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

 

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 na aplicação.

1.Leitura ou escrita de Holding Registers, funções 03 e 16, de endereço 100 do equipamento com Id 1 (um) 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 (três) 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 (quatro), 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 E3 ou Elipse Power 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. Para mais informações, consulte 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", como por exemplo "&hFFFF". Já para octal, use o prefixo "&o", como 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úvida 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. Consulte 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, e 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 omitido, são usados os tipos de dados 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 de dados suportados, mais adiante neste tópico.

2.Tamanho do tipo: É necessário especificar este campo apenas para os tipos de dados de tamanho variável, como BCD e String. O valor numérico indica o tamanho do tipo de dados 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. Consulte 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 ou 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 de dados. O tamanho máximo atualmente é 64 para tipos de dados 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 no 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 os respectivos tipos de dados nativos.

Espaços de endereçamento e mnemônicos

 

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 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 deste Driver, e também um alias ou nome alternativo.

Tipos de dados suportados

 

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. Para mais informações, consulte 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, este Driver não permite o uso destes tipos de dados no campo Item. Para mais informações, consulte 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 de um equipamento com Id 1 (um), interpretado como um DWord, com Slave Id no campo Dispositivo:

a.Dispositivo: "1:"

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

2.Leitura ou escrita de Holding Registers, funções 03 e 16, de endereço 150 de um equipamento com Id 3 (três), 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 de um equipamento com Id 5 (cinco), 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 é 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 de um equipamento com Id 5 (cinco), 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 de um equipamento com Id 5 (cinco), 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"

 

 

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, ou type size, em bytes, logo após o tipo de dados.

Cabe lembrar que são válidos apenas os tipos de dados 2 (dois) e 4 (quatro), ou seja, 2 (dois) e 4 (quatro) bytes ou 4 (quatro) e 8 (oito) 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 de um equipamento com Id 1 (um), interpretado como uma String de 10 bytes, ou 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 de um equipamento com Id 1 (um), interpretado como BCD de oito dígitos, ou 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 um 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 um 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 este Driver lê um valor igual a "1234h", ou "4660" em decimal, por padrão espera que este dado seja enviado com a sequência de bytes 12h e 34h. Se entretanto um equipamento usa o padrão inverso, chamado de little endian, é enviado primeiro o byte 34h e depois o 12h, e este Driver pode interpretá-lo como 3412h, ou 13330 em decimal, a não ser que os dois bytes tenham a ordem invertida antes da interpretação.

No caso de valores de 32 bits pode também ocorrer de valores em Word permutados, ou 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, este 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". Para mais informações, consulte a tabela a seguir.

Se o parâmetro byte order é omitido, um 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

* 64 bits, em que "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 de um equipamento, equivalente a não selecionar nenhuma opção de permuta na aba Operations da antiga configuração numérica.

Já o ordenamento "b1" realiza a permuta dos bytes, dois a dois, ou seja, ao receber um Word, um 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 ordenamento "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, ao receber de um equipamento o valor 01020304h, o valor utilizado para os Tags da aplicação é 03040102h.

Já ao usar o ordenamento "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 ordenamento "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 colunas Alias e Alias 2 (swaps) 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 de um equipamento especifica qual o ordenamento utilizado, ou como configurá-lo, pois 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 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 as situações a seguir:

1.Caso um 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 um 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 por um equipamento para o formato big endian padrão do protocolo.

 

 

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 de um equipamento com Id 5 (cinco), 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 de um equipamento com Id 5 (cinco), 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 de um equipamento com Id 5 (cinco), 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 deste Driver

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

Tags especiais