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 BlocoOs Tags configurados por Strings podem ser Tags simples ou Tags Bloco, com os campos Dispositivo e Item tendo a mesma sintaxe.
Campo DispositivoNo 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 ItemNo 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 Campos Obrigatórios e OpcionaisOs 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çõesAs 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çamentoAo 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
Tipos de DadosNa 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
Tipos de Dados Criados pelo UsuárioAlé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).
Exemplos1.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"
Tamanho do Tipo de DadosOs 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
* 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.
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 DriverAlé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
|