DRIVER MODBUS

Nome do Arquivo | MODBUS.DLL
Fabricante | Modicon
Equipamentos | Qualquer equipamento compatível com o protocolo Modbus v1
Protocolo | Modbus v1
Versão | 2.07 build 1
Última Atualização | 30/06/2010
Plataforma | Win32
Dependências | IOKit v1.06 ou superior

Introdução

Este driver implementa o protocolo Modbus Master/Slave que permite ao Elipse comunicar com qualquer equipamento que tenha implementado este protocolo nos modos ASCII, RTU ou TCP.

O driver Modbus da Elipse foi desenvolvido em conjunto com a biblioteca IOKit da Elipse.

Esta biblioteca, após ser configurada pelo usuário, é responsável por implementar o acesso ao meio físico desejado (Serial, Ethernet, Modem e RAS).

Para maiores informações sobre a configuração deste driver, ver o Manual do Usuário do IOKit.

Recomendamos que para o correto funcionamento do driver sejam lidos, nesta ordem, os capítulos Adicionando o driver em uma aplicação Elipse e Configurando o Driver.

Se você for um usuário com experiência na utilização dos produtos da Elipse, pode seguir o Passo a Passo.

Esta seção da documentação ajudou você a configurar o driver?
Sim Não
Comentários (150 caracteres):
Restam 150 caracteres.


O Protocolo Modbus

 Topo Anterior Próximo

O protocolo Modbus foi desenvolvido inicialmente pela Modicon (atual Schneider Electric) em 1979, sendo hoje um padrão aberto, implementado por centenas de fabricantes em milhares de equipamentos. O protocolo é baseado em mensagens de comando e resposta, posicionado no nível 7 do modelo OSI, que possibilita comunicação cliente/servidor entre equipamentos conectados a diferentes tipos de redes. Oferece serviços com funções definidas por um código de 8 bits.

Existem três categorias de códigos de funções:

· Códigos de Funções Públicas: Funções bem definidas pelo protocolo, com garantia de unicidade, validadas pela comunidade Modbus.org e publicamente documentadas em MB IETF RFC.
· Códigos de Funções Definidas pelo Usuário: Funções não-padronizadas, que não precisam de aprovação da Modbus.org, portanto sem qualquer garantia de unicidade, podendo ser livremente implementadas.
· Códigos de Funções Reservadas: Códigos atualmente usados por alguns fabricantes em produtos antigos, não disponíveis para uso público.

Este driver implementa todas as funções públicas, com exceção das funções 22, 23 e 43, bem como algumas funções específicas de fabricantes.


Sites Recomendados

O driver Modbus da Elipse está disponível para download (sem custos) no site da Elipse na área de Download de Drivers.

Maiores informações referentes ao protocolo Modbus podem ser obtidas no site www.modbus.org.

O Simulador Modbus Slave pode ser encontrado em www.win-tech.com/html/modsim32.htm. Existe também o software Free Modbus PLC Simulator, disponível em www.plcsimulator.org.


Funções do Modbus

As funções do protocolo Modbus suportadas por este driver estão descritas a seguir.

Funções de Leitura:

· 01: Leitura de Bit (Read Coil Status - 0x).
· 02: Leitura de Bit (Read Input Status - 1x).
· 03: Leitura de Words (Read Holding Registers - 4x).
· 04: Leitura de Words (Read Input Registers - 3x).
· 07: Leitura de Status (Read Exception Status).
· 20: Leitura da Memória Estendida (Read General Reference - 6x).

Funções de Escrita:

· 05: Escrita de Bit (Force Single Coil - 0x).
· 06: Escrita de Word Simples (Preset Single Register - 4x).
· 15: Escrita de Bits (Force Multiple Coils - 0x).
· 16: Escrita de Words (Preset Multiple Registers - 4x).
· 21: Escrita na Memória Estendida (Write General Reference - 6x).

A configuração completa do driver está descrita no capítulo Configurando o Driver.


Funções Especiais do Modbus

As operações de leitura e escrita especiais foram desenvolvidas para atender particularidades exclusivas de determinados equipamentos.

Estas operações devem ser configuradas na propriedade N2/B2 dos tags de comunicação e estão descritas a seguir.

Funções de Leitura:

· 6503: Leitura da Memória de Massa (ABB MGE 144).
· SOE GE: Leitura de eventos (GE PAC RX7 Systems).

Funções de Escrita:

· 6501: Zera medidor de energia (ABB MGE 144).
· 6502: Zera memória de máximo e mínimo (ABB MGE 144).

A configuração completa do driver está descrita no capítulo Configurando o Driver.


Codificação BCD

A codificação BCD (Binary Coded Decimal, ou Decimal Codificado em Binário) foi originalmente concebida para contornar limitações quanto ao número máximo de dígitos passíveis de serem representados nos formatos mais tradicionais de armazenamento de valores. Formatos como a representação de números reais em ponto flutuante mostram-se normalmente aceitáveis para cálculos matemáticos e científicos. Porém, erros de aproximação causados pela existência de algarismos que não possam ser representados por problemas de overflow ou underflow, podem não ser admissíveis em certas aplicações, como em procedimentos financeiros. Para superar este tipo de limitação foi desenvolvida a codificação BCD, que permite a representação de números até o último algarismo.

Nessa representação, cada algarismo decimal é representado somente em binário, sem limitações no que se refere ao número de algarismos.

A tabela a seguir mostra os algarismos decimais e seus valores correspondentes em BCD:

Decimal | BCD | Decimal | BCD
0 | 0000b | 5 | 0101b
1 | 0001b | 6 | 0110b
2 | 0010b | 7 | 0111b
3 | 0011b | 8 | 1000b
4 | 0100b | 9 | 1001b

A fim de melhorar a eficiência desta codificação, é comum representar-se dois algarismos por byte, já que cada algarismo decimal requer apenas 4 bits para sua codificação. Tal representação é chamada de BCD comprimido (Packed BCD), e é a representação utilizada por este driver. Ou seja, os pacotes enviados por este driver com valores BCD utilizam um byte de dado para cada dois algarismos do valor decimal representado. Por isso o campo Size, no caso de tipos de dado BCD, deve ser definido como a metade do número máximo de algarismos a serem representados nos valores a serem lidos ou escritos.


Tipos de Dados Suportados pelo Driver

Opção | FAIXA | Descrição
Char | -128 a 127 | Palavra de 8 bits, caracter.
Byte | 0 a 255 | Palavra de 8 bits sem sinal.
Int8 | -128 a 127 | Palavra de 8 bits com sinal.
Int16 | -32768 a 32767 | Palavra de 16 bits com sinal.
Int32 | -2.147.483.648 a 2.147.483.647 | Palavra de 32 bits com sinal.
Word/UInt | 0 a 65535 | Palavra de 16 bits sem sinal.
Dword/ULong | 0 a 4294967295 | Palavra de 32 bits sem sinal.
Float | -3.4E38 a 3.4E38 | Ponto flutuante de 32 bits (IEEE 754) (4 bytes com o mais significativo primeiro: EXP F2 F1 0).
Float_GE | -1.427E+45 a 1.427E+45 | Ponto flutuante de 32 bits (não IEEE 754) (4 bytes na ordem: EXP F2 F1 F0).
Double | -1.7E308 a 1.7E308 | Real de 64 bits.
String | Não se aplica. | Palavra de N chars (texto).
BCD | Ver descrição e o item Codificação BCD | Valor numérico BCD (Decimal Codificado em Binário). Quando utilizando este tipo, a aplicação deve fornecer um valor decimal positivo e inteiro, a ser enviado no formato BCD, respeitando o tamanho especificado. O campo Size, no caso do tipo BCD, refere-se ao número de bytes a serem enviados para representar o valor. Uma vez que na codificação BCD cada algarismo será convertido em um nibble, tem-se que os valores permitidos devem possuir um número máximo de algarismos igual ao dobro do valor especificado no campo Size. Ou seja, se for selecionado 2 para o campo Size, o máximo valor que poderá ser enviado será 9999. Já se Size é igual a 4, o valor máximo será 99999999. Os valores permitidos para o campo Size no caso de tipos BCD são 2 (WORD) e 4 (DOUBLE WORD). Para maiores detalhes sobre a codificação BCD, consulte a seção Codificação BCD deste manual.
GE Events | Ver descrição | Tipo de dados usado na leitura do buffer de eventos (SOE) de CLP GE PAC RX7. Esses eventos são retornados como blocos de dois elementos, com timestamps definidos pelo controlador. Para mais informações, veja a seção Leitura de Buffer de Eventos em controladores GE PAC RX7.
Bit | 0 ou 1 | Tipo selecionado automaticamente quando uma função de acesso a bits é selecionada. As funções de acesso a bits são as seguintes: 01, 02, 05 e 15. O campo Size não é usado para tipos bits. Quanto este tipo é usado, cada elemento de bloco passa a representar um bit.


Lista de Equipamentos que Comunicam com o Modbus

A seguir têm-se uma lista de equipamentos, separados por fabricante, os quais sabe-se que comunicam via protocolo Modbus.

Fabricante

Equipamento

Schneider
· Twido
· A340
· Serie Premium
· Conversores de freqüência e soft starter
· Disjuntores de MT e BT
· Relés de proteção de BT e MT

Weg
· TP 03

Novus
· N1100
· N2000
· N3000

Fatek
· FB - 14MCU

Unitronics
· V120

LG
· DMT40U

ABB
· ETE30
· MGE 144

BCM
· BCM1088, BCM1086, BCM-GP3000 e BCM2085

Altus
· Praticamente todos equipamentos da Altus possuem Modbus, exceto alguns modelos da linha Piccolo

Moeller
· XC100 - Porta Serial 232
· XC200 - Porta Serial 232/422/485 (módulo de comunicação XIO-SER) e Porta Ethernet
· XV200 - Porta Serial 232 e Porta Ethernet
· XVH300 - Porta Serial 232 e Porta Ethernet
· XV400 - Porta Serial 232 e Porta Ethernet

Deep Sea
· DSE5210
· DSE5310
· DSE5310M
· DSE5320
· DSE5510
· DSE5510M
· DSE5520
· DSE7310
· DSE7320

Areva
· MiCOM P127


Adicionando o Driver em uma Aplicação Elipse

Esta seção descreve como adicionar o driver Modbus em aplicações E3 ou SCADA.


No Elipse SCADA

Através do Organizer, selecione o ítem Drivers e então clique no botão Novo.

Na janela aberta, selecione o driver desejado (o mesmo deverá ser descompactado em uma pasta no computador que está sendo utilizado) e então clique em Abrir.

O driver será então adicionado na aplicação.

Para que o driver funcione corretamente ainda é preciso configurá-lo. Para isso, leia o capítulo Configurando o Driver.


No Elipse E3

Através do Organizer, selecione o ítem Objetos de Servidor e então Drivers e OPC. Com o botão direito do mouse selecione a opção Inserir Driver de Comunicação em e então selecione o projeto desejado.

Na janela aberta, selecione o driver desejado (o mesmo deverá ser descompactado em uma pasta no computador que está sendo utilizado) e então clique em Abrir.

Após clicar em Abrir, a janela de configuração do driver será aberta. Nela deve-se configurar o driver conforme a necessidade.

No capítulo Configurando o Driver está descrito como configurar o driver.

Por hora, pode-se clicar em OK na janela de configuração e no botão Fechar da próxima janela (Tag Browser).


Configurando o Driver

Esta seção descreve como configurar o driver Modbus.


Propriedades do Driver

Configurando Operações de Leitura/Escrita

Para o correto funcionamento deste driver, é necessário definir quais as funções Modbus de leitura ou escrita serão utilizadas. Para isto, deve-se acessar a aba Modbus nas configurações do driver. Nela é possível definir configurações, denominadas operações, que definirão as funções Modbus de leitura e escrita utilizada por cada tag, bem como a forma como os dados lidos devem ser interpretados (tipo de dados).

A lista das funções Modbus suportadas pelo driver, e que podem ser atribuídas às operações configuradas, pode ser conferidas no item Funções do Modbus.

Por padrão, quando adiciona-se um novo driver no aplicativo, o driver já adiciona sete operações padrão, descritas na tabela a seguir.

Operação | Função de Leitura | Função de Escrita | Tipo de Dado | Finalidade
1 | 3 - Read Holding Registers | 16 - Write Multiple Registers | WORD | Para ler e escrever inteiros de 16 bits sem sinal.
2 | 3 - Read Holding Registers | 16 - Write Multiple Registers | DWORD | Para ler e escrever inteiros de 32 bits sem sinal.
3 | 3 - Read Holding Registers | 16 - Write Multiple Registers | INT16 | Para ler e escrever inteiros de 16 bits com sinal.
4 | 3 - Read Holding Registers | 16 - Write Multiple Registers | INT32 | Para ler e escrever inteiros de 32 bits com sinal.
5 | 3 - Read Holding Registers | 16 - Write Multiple Registers | FLOAT | Para ler valores com ponto flutuante de 32 bits.
6 | 3 - Read Holding Registers | 15 - Write Multiple Coils | BIT | Para ler e escrever bits.
7 | 2 - Read Discrete Inputs | None | BIT | Para ler bits do bloco de dados de Entradas Discretas (Discrete Inputs).

Para adicionar uma nova operação no driver, basta clicar no botão Add.

De acordo com a figura anterior, após clicar em Add, deve-se configurar a nova operação. Deve-se sempre escolher um número para esta operação (este número será utilizado no parâmetro N2/B2 dos tags de comunicação), qual função Modbus deseja-se utilizar para leitura e qual função Modbus deseja-se utilizar para escrita, além de informar o tipo de dado que será lido ou escrito pelo driver. Para mais informações sobre os tipos de dados suportados, veja o item Tipos de dados suportados pelo protocolo. Os demais campos devem ser configurados conforme a necessidade. A descrição destes campos é:

Opção | Descrição
Size | Deve ser informado o tamanho em bytes de cada elemento do tipo de dado selecionado. Este campo é preenchido automaticamente para tipos de dados com tamanho fixo, como os tipos BYTE, WORD e Int16, devendo ser preenchido para dados de tipo String e BCD. No caso de Strings, este tamanho define exatamente o número de bytes enviados ou recebidos para cada valor String, isto é, para cada tag PLC ou elemento de bloco. Se a String lida ou escrita tiver um tamanho menor, o restante dos bytes será preenchido com zeros, de forma a completar o tamanho configurado. O tipo String neste driver não possui um limite máximo de tamanho definido, sendo este limite o máximo permitido pelo protocolo para a área de dados do frame de uma determinada função.
Rev Frame | Indica que o sentido dos bytes no frame está invertido. Se estiver habilitada, esta opção faz com que toda a área de dados do frame de comunicação tenha sua ordem invertida. Esta opção não tem efeito na escrita de dados.
Swap Byte | Indica que o driver deverá inverter a ordem dos bytes um a um, para obter o valor.
Swap Word | Indica que o driver deverá inverter a ordem dos bytes dois a dois (em Words) para obter o valor.
Swap DWord | Indica que o driver deverá inverter a ordem dos bytes quatro a quatro (em DWords) para obter o valor.
Use Bit Mask | Habilita mascaramento de bits de registradores, através do parâmetro N3/B3. Essa opção afeta apenas a leitura e pode ser usada apenas com tipos inteiros, com ou sem sinal. Operações com essa opção habilitada não poderão ser usadas para escrita.

NOTA: As opções de Swap citadas acima não tem efeito para tipos de dados BIT ou tipos com 8 bits de tamanho (BYTE, CHAR e INT8). A permuta ocorre dentro de cada tipo de dado. Ou seja, a opção Swap Word não terá efeito para tipos de dados de 16 bits, assim como a opção Swap Dword não terá efeito para tipos de dados de 32 bits.

As funções Modbus que podem ser configuradas nos campos Read e Write estão descritas no capítulo Funções do Modbus.

Os demais campos que aparecem nesta aba são:

Opção | Descrição
Import Configuration | Esta opção permite importar configurações de funções de versões anteriores a 2.0 do driver Modbus Master/Slave, que armazenavam essas configurações em um arquivo modbus.ini. Este driver não utiliza mais arquivos .ini para armazenar tais configurações, que agora são armazenadas no próprio arquivo da aplicação.
Export Configuration | Esta opção faz a operação inversa da anterior, gerando um arquivo .ini contendo as configurações de funções, no mesmo formato das versões anteriores deste driver. Desta forma é possível guardar em um arquivo as configurações de funções, que podem ser usadas em outras aplicações.
Add | Adiciona um novo item a lista.
Edit | Atualiza um item selecionado na lista.
Remove | Remove um item selecionado na lista.

NOTA: As opções Rev Frame, Swap Byte, Swap Word e Swap Dword foram acrescentadas para permitir compatibilidade com equipamentos que não seguem o padrão do protocolo Modbus na codificação dos dados. O protocolo Modbus padrão transfere os dados com os bytes mais significativos primeiro. Se estas opções permanecerem desabilitadas, o comportamento do driver corresponderá ao padrão do protocolo, sendo esta a opção recomendada para a maioria dos equipamentos.

Protocol Options

Opção

Descrição

Modbus Mode

Nessa caixa de combinação é possível selecionar o modo a ser utilizado. São três as opções disponíveis:

· Modo RTU: modo padrão para uso em comunicação serial. Inclui CRC de 16 bits.
· Modo ASCII: também usado em comunicação serial, é usado em equipamentos mais simples, que não suportem os requisitos do modo RTU. Utiliza caracteres ASCII para transmissão, onde cada byte contém dois caracteres ASCII (um por nibble), sendo por isso menos eficiente que o modo RTU. Usa LRC (Longitudinal Redundancy Checking) para verificação de erros.
· Modo ModbusTCP: usado para comunicação em TCP/IP. Inclui campo para verificação de transação, e não possui sistema de verificação de erros. O campo de transação permite descartar respostas atrasadas, evitando que o driver assuma como resposta válida para o comando atual frames de resposta a comandos anteriores. Essa situação pode ocorrer se os modos anteriores forem encapsulados em TCP/IP.

Customize Max. PDU Size

Se habilitada, essa opção permite definir um tamanho máximo personalizado para o Protocol Data Unit (PDU). O Protocol Data Unit é a parte do protocolo que não varia entre os modos do protocolo (ModbusTCP, ASCII e RTU), e que contém a área de dados. O número de bytes de dados suportados em cada comunicação é dado por esse valor menos os bytes de cabeçalho, que dependem da função Modbus utilizada.

Se for deixada desabilitada, o tamanho máximo considerado será o valor padrão definido pelo protocolo Modbus, de 253 bytes.

Enable CMS Addressing

Essa opção pode ser usada para equipamentos que suportem o protocolo TeleBUS. Se estiver habilitada, o driver passa a aceitar uma WORD de 16 bits como endereço do escravo. Ou seja, passa a ser possível definir valores acima de 255 e abaixo de 65536 como endereço do escravo. Neste caso, o endereço do escravo passa a ser definido no protocolo por três bytes. Se esta opção for habilitada, a opção Default Slave Address passa a não funcionar mais.

Data Address Model Offset

Essa opção habilita ou desabilita o offset de dados padrão do protocolo. No modelo de dados padrão do protocolo, são definidos 4 blocos de dados, os quais são Discrete Inputs, Coils, Input Register e Holding Register. Em cada um desses blocos, os elementos de dados são endereçados iniciando em 1. Já a especificação do frame de comunicação, entretanto, define um Protocol Data Unit (PDU) contendo endereços que podem variar de 0 a 65535. A relação entre o endereço fornecido no PDU e o endereço dos elementos de dados, portanto, possui um deslocamento (offset) de 1. Ou seja, se no PDU de uma requisição constar o endereço 0, o elemento de dado acessado será o endereço 1. Com essa opção, o usuário pode escolher se deseja que o driver ajuste o valor automaticamente, de forma a permitir o uso do endereço do elemento de dado nos tags, ou se deseja que o valor enviado no PDU seja o valor fornecido na configuração dos tags. As opções são:

· Data is addressed from 1: endereço fornecido no parâmetro N4/B4 será decrementado de 1 antes de ser enviado ao equipamento.
· Data is addressed from 0: endereço fornecido pelo usuário será usado nas requisições do protocolo, sem alterações.

NOTA: a opção Data Address Model Offset era denominada Use Older Address nas versões anteriores à versão 2.3 desse driver, onde a opção Data is addressed from 1 equivale à antiga opção Use Older Adress habilitada, e a opção Data is addressed from 0 equivale à opção Use Older Address desabilitada.

Opção | Descrição
Default Slave Address | Este recurso permite configurar um endereço padrão de escravos, de forma a não precisar configurá-lo em cada tag. Para usar este recurso, basta configurar o parâmetro N1/B1 como 1000. Ou seja, todos os tags que tiverem B1/N1 = 1000 terão este valor substituído pelo valor configurado na caixa de edição Default Slave Address. Também é possível forçar o uso do endereço padrão em todos os tags, independente do valor configurado em N1/B1, marcando-se a opção Use Default Address.
Use swap address delay | Esta opção deve normalmente ser deixada desabilitada. Em raras situações, existem controladores que precisam de uma pausa entre a troca de escravos, isto é, um tempo de espera após a comunicação com um determinado equipamento, antes de o driver se comunicar com um outro equipamento com endereço de escravo diferente. Se este for o caso, pode-se definir este atraso em ms.
Wait Silence on error | Se esta opção estiver habilitada, após cada erro de comunicação o driver ficará em loop recebendo dados até ocorrer timeout. Isto limpa o canal de recepção, impedindo que ocorram problemas em futuras comunicações devido à recepção de bytes atrasados, que ainda estejam trafegando no momento do erro, e que possam ser confundidos com a resposta a um novo comando.


Configurando em Modo Offline

As configurações do driver também podem ser acessadas em tempo de execução se o driver for iniciado no modo OFFLINE, usando-se os seguintes strings:

PARÂMETRO

TIPO

ModiconModbus.ModbusMode

Inteiro:

· 0: Modbus RTU
· 1: Modbus ASCII
· 2: Modbus TCP

ModiconModbus.Olderaddr

Booleano (0 ou 1)

· 1: data is addressed from 1
· 0: data is addressed from 0

ModiconModbus.UseDefaultSlaveAddress

Booleano (0 ou 1)

ModiconModbus.DefaultSlaveAddress

Inteiro sem sinal

ModiconModbus.UseSwapAddressDelay

Booleano (0 ou 1)

ModiconModbus.SwapAddressDelay

Inteiro

ModiconModbus.WaitSilenceOnError

Booleano (0 ou 1)

ModiconModbus.EnableCMSAddressing

Booleano (0 ou 1)

ModiconModbus.EnCustomizeMaxPDUSize

Booleano (0 ou 1)

ModiconModbus.MaxPDUSize

Inteiro

ModiconModbus.ConfigFile

String contendo o arquivo de configuração com as operações do driver

Para maiores informações sobre a configuração OFFLINE em tempo de execução (runtime), ver o Manual do Usuário do IOKit.


Configurando Tag CLP / Tag Comunicação

Os tags deste driver permitem ler e escrever em registros Modbus nos equipamentos escravos, usando-se funções do protocolo Modbus. Os dados são lidos do equipamento no formato WORD de 16 bits, conforme especificação do protocolo, mas podem ser formatados de acordo com um dos tipos de dados suportados pelo driver antes de serem retornados à aplicação.

Na janela de configurações do driver podem ser definidas operações do driver, compostas por funções do protocolo Modbus para leitura e escrita, e de um formato específico de dados. Essas operações podem ser referenciadas através dos parâmetros N2/B2 dos tags de acesso a registros.

· N1: Endereço do equipamento escravo (CLP) na rede. Este endereço pode variar de 1 a 255. Pode-se ainda configurar este parâmetro com o valor 0. Com isto, este tag trabalhará em modo broadcast, enviando a mensagem para todos os equipamentos escravos (CLP) que estiverem na rede.

NOTA: no modo broadcast, com N1 = 0, não é possível realizar leituras, apenas escritas. Neste modo, todos os equipamentos na rede serão endereçados, recebendo o valor escrito, e não retornando qualquer resposta, de forma a evitar conflitos na rede.

· N2: Código da operação. Referencia uma operação de leitura ou escrita adicionada na janela de configurações do driver.
· N3: Parâmetro adicional. Para as funções de leitura e escrita de arquivos (funções 20 e 21), o parâmetro N3 especifica o arquivo a ser acessado. Para as demais funções de leitura e escrita de registradores, N3 especifica a máscara a ser usada na leitura. Esse parâmetro só será usado se a opção Use Bit Mask for habilitada para a operação em uso, e o número de um bit específico a ser retornado for selecionado. O valor zero indica o bit menos significativo. O valor do bit selecionado será sempre retornado no bit menos significativo do valor. Ou seja, se a opção Use Bit Mask estiver habilitada para a operação na janela de configuração, o valor retornado do tag será sempre 0 ou 1.
· N4: Endereço do registrador ou da variável no equipamento escravo (CLP) que se deseja ler ou escrever.

Além dos tags de acesso a registros Modbus, tem-se também tags especiais para executar uma função específica do driver, conforme mostra a tabela abaixo:

Tags Especiais

N2/B2 | Descrição dO Tag Especial
9001 | Força a execução de um "Wait Silence" (veja seção Configurando Tag Especial para Forçar um "Wait Silence").
9999 | Leitura da última exceção (veja seção Configurando Tag Especial para Leitura do Código da Última Exceção).


Configurando Tag Bloco

Os tags deste driver permitem ler e escrever registros Modbus em equipamentos escravos.

Utilizando tags bloco tem-se a vantagem de conseguir, em uma única comunicação, ler ou escrever em diversos registros do equipamento escravo.

Para isto, deve-se configurar os parâmetros B conforme descrito a seguir:

· B1: Endereço do equipamento escravo (CLP) na rede. Este endereço pode variar de 1 a 255. Pode-se ainda configurar este parâmetro com o valor 0. Com isto este tag trabalhará em modo broadcast, enviando a mensagem para todos os equipamentos escravos (CLP) que estiverem na rede.

NOTA: no modo broadcast, com B1 = 0, não é possível realizar leituras, apenas escritas. Neste modo, todos os equipamentos na rede serão endereçados, recebendo o valor escrito, e não retornando qualquer resposta, de forma a evitar conflitos na rede.

· B2: Número da operação de leitura ou de escrita adicionada na janela de configurações do driver.
· B3: Parâmetro adicional. Para as funções de leitura e escrita de arquivos (funções 20 e 21), o parâmetro B3 especifica o arquivo a ser acessado. Para as demais funções de leitura e escrita de registradores, B3 especifica a máscara a ser usada na leitura. Esse parâmetro só será usado se a opção Use Bit Mask for habilitada para a operação em uso, e seleciona o número de um bit específico a ser retornado. O valor zero indica o bit menos significativo. O valor do bit selecionado será sempre retornado no bit menos significativo do valor. Ou seja, se a opção Use Bit Mask estiver habilitada para a operação na janela de configuração, o valor retornado do tag será sempre 0 ou 1.
· B4: Endereço do registrador ou da variável no equipamento escravo (CLP) que se deseja ler ou escrever.


Configurando Tag Especial para Forçar um "Wait Silence"

Tag especial utilizada para descartar todos os dados pendentes da comunicação até encontrar um "Timeout", indicando que não há mais dados a serem recebidos.

Este Tag Especial é executado através de um comando de escrita de Tag PLC, com parâmetro B2 = 9001.


Configurando Tag Especial para Leitura do Código da Última Exceção

Conforme já mencionado neste manual, os tags especiais para leitura do código da última exceção são utilizados para ler o último código de exceção enviado por um determinado equipamento escravo.

Tais códigos são armazenados automaticamente pelo driver em registradores internos, que podem ser acessados por meio deste tag. Além disso, a cada comunicação bem sucedida com determinado equipamento em que nenhuma exceção for retornada, o driver zera automaticamente o registrador associado ao mesmo.

Os códigos de exceção são usados pelo escravo para informar uma falha ao executar uma determinada função. Os equipamentos escravos não retornam exceções no caso de falhas de comunicação, situação em que estes simplesmente não respondem. Os códigos de exceção são retornados pelos escravos em situações em que a solicitação do mestre foi recebida com sucesso, porém não pôde ser executada por algum motivo, como, por exemplo, a tentativa de ler ou escrever em um registrador inexistente. Neste caso, o código de exceção retornado indica o tipo de erro ocorrido.

A especificação do protocolo Modbus define nove códigos de exceção, os quais são apresentados na tabela ao final dessa seção. Além destes códigos, alguns fabricantes definem códigos adicionais, específicos de seus equipamentos.

A forma mais usual de utilizar este tag durante o scan normal dos tags de funções é através de um evento OnRead do tag de exceção. Neste caso, o script deve antes de tudo rejeitar valores nulos, pois estes indicam o não recebimento de exceções. Em seguida, pode-se tratar a exceção, executando os procedimentos adequados conforme o código recebido. Constitui-se uma boa prática zerar o registrador de exceção ao sair do script, de forma a indicar que a exceção já foi tratada.

Veja um exemplo abaixo, escrito em Elipse Basic (Elipse SCADA):

// Evento OnRead da TagExc

// Obs: Para este exemplo, considere TagExc com leitura e escrita automatica habilitadas

IF TagExc == 0

RETURN

ENDIF

IF TagExc == 1

... // TRATA EXCECAO 1

ELSEIF TagExc == 2

... // TRATA EXCECAO 2

ELSE

... // TRATA DEMAIS EXCECOES

ENDIF

TagExc = 0 // ZERA REGISTRADOR DE EXCECOES

Veja um exemplo abaixo, escrito em VBScript (Elipse E3):

'Evento OnRead da TagExc

'Obs: Para este exemplo, considere TagExc com leitura e escrita automatica habilitadas

Sub TagExc_OnRead()

If Value = 0 Then

Exit Sub

End If

If Value = 1 Then

... 'TRATA EXCECAO 1

ElseIf Value = 2 Then

... 'TRATA EXCECAO 2

Else

... 'TRATA DEMAIS EXCECOES

End If

Value = 0 'ZERA REGISTRADOR DE EXCECOES

End Sub

Já nas operações de escrita por script, em que seja preciso testar o retorno de exceções logo em seguida ao envio do comando, deve-se primeiramente zerar o registrador de exceções. Isto evita que uma eventual exceção provocada pelo comando de escrita seja confundida com uma pré-existente. Executa-se então a operação de escrita e testa-se o valor do tag especial, que deve retornar zero caso nenhuma exceção tenha sido recebida. Caso este retorne um valor diferente de zero, pode-se então tratar apropriadamente a exceção recebida.

Veja um exemplo abaixo, escrito em Elipse Basic (Elipse SCADA):

// Obs: Para este exemplo, considere TagExc com leitura e escrita automática habilitadas

// e TagVal com escrita automática desabilitada.

TagExc = 0 // ZERA REGISTRADOR DE EXCECOES

TagVal.WriteEx(10) // ESCREVE O VALOR 10

IF TagExc <> 0

... // TRATA EXCECAO

ENDIF

Veja um exemplo abaixo, escrito em VBScript (Elipse E3):

'Obs: Para este exemplo, considere TagExc com leitura e escrita automática habilitadas

' e TagVal com escrita automática desabilitada.

Application.GetObject("Tags.TagExc").Value = 0 'ZERA REGISTRADOR DE EXCECOES

Application.GetObject("Tags.TagVal").WriteEx(10) 'ESCREVE O VALOR 10

If Application.GetObject("Tags.TagExc").Value <> 0 Then

... 'TRATA EXCECAO

End If

NOTA: O tag especial B2 = 9999 retorna, além do código da exceção (retornado no elemento zero), também os parâmetros do tag cuja comunicação teria provocado a exceção. Caso essas informações não sejam necessárias, pode-se perfeitamente ler o mesmo registro através de um tag PLC com N2 = 9999. Neste caso os procedimentos recomendados permanecem os mesmos.

Códigos de exceção padronizados pelo protocolo Modbus

CÓDIGO | NOME | SIGNIFICADO
1 | ILLEGAL FUNCTION | O código de função recebido não é válido. Isso pode indicar que a função não está implementada, ou que o escravo encontra-se em um estado inadequado para processá-la.
2 | ILLEGAL DATA ADDRESS | Endereço de dados recebido não é um endereço válido. Mais especificamente, a combinação do endereço de referência e a quantidade de dados a serem transferidos é inválida.
3 | ILLEGAL DATA VALUE | Valor presente na requisição do Mestre não é válido. Isto indica uma falha na estrutura de dados remanescente de uma requisição complexa, como quando o tamanho informado para o bloco de dados não está correto. Esta exceção não indica que os valores submetidos para escrita estejam fora do escopo esperado pela aplicação, uma vez que tal informação não é acessível ao protocolo.
4 | SLAVE DEVICE FAILURE | Ocorreu um erro irrecuperável durante o processamento da função solicitada.
5 | ACKNOWLEDGE | Usado com comandos de programação. O escravo aceitou a mensagem e a está processando. Porém este processamento levará um longo tempo. Esta exceção previne um timeout no mestre. O fim da requisição deve ser testado por um processo de polling.
6 | SLAVE DEVICE BUSY | Usado com comandos de programação. Indica que o escravo está processando um outro comando de longa duração, e que a solicitação deve ser retransmitida mais tarde, quando o escravo estiver novamente disponível.
8 | MEMORY PARITY ERROR | Usado em conjunto com as funções 20 e 21, reference type 6, para indicar que a área extendida de arquivos falhou em um teste de consistência. O equipamento escravo pode estar precisando de manutenção.
0A | GATEWAY PATH UNAVAILABLE | Usado em conjunto com gateways, para indicar que o gateway não foi capaz de alocar um caminho interno para o processamento da solicitação. Geralmente indica que o gateway está desconfigurado ou sobrecarregado.
0B | GATEWAY TARGET DEVICE FAILED TO RESPOND | Usado em conjunto com gateways, para indicar que não foi recebida nenhuma resposta do equipamento destino. Geralmente indica que tal equipamento não está presente na rede.


Leitura de Buffer de Eventos em Controladores GE PAC RX7

Para a leitura do buffer de eventos (SOE) de controladores GE PAC RX7, deve ser definida, na janela de configuração do driver, uma operação do driver que use como função de leitura a opção SOE GE. O tipo de dado deve ser definido como GE Events.

O buffer de eventos pode ser lido através de três tipos de tags: tags reportados por eventos, tags reportados por eventos por ponto, e tags de tempo real.

Tags Reportados Por Eventos

Os tags reportados por eventos retornam, a cada operação de leitura, todos os eventos acumulados no buffer interno do driver.

Os seguintes parâmetros devem ser utilizados:

· B1: Slave ID.
· B2: Código da Operação definida com a função SOE GE.
· B3: 0.
· B4: Endereço base da pilha de eventos no CLP.

A cada scan neste tag, o driver irá verificar se existem eventos no buffer do controlador. Se houver eventos, o driver iniciará uma thread de leitura de eventos, que será executada em segundo plano, não bloqueando a varredura dos demais tags. Após o término da leitura do buffer pelo driver, este tag, reportado por eventos, retornará o conjunto de eventos lidos na varredura.

Os eventos retornados geram uma sucessão de eventos OnRead() neste tag. Para cada evento lido o E3 atualizará os campos do tag (valores de elementos e timestamp) com os valores de um determinado evento, e chamará uma vez o evento OnRead(). O script do evento chamado deverá ser definido pelo usuário, sendo geralmente usado para inserir os dados do tag no histórico.

Cada evento será representado por um bloco de dois elementos, com o campo timestamp indicando o valor lido do equipamento. Os campos do respectivo tag bloco de leitura são mostrados na tabela a seguir.

OFFSET | SIGNIFICADO | TIPO DE DADO | FAIXA DE VALORES
0 | Identificação do ponto | BYTE | 0 - 15
1 | Status do ponto | BYTE | 0 - 1

Tags Reportados Por Eventos Por Ponto

A partir da versão 2.5 do driver, é possível utilizar um novo tag para o download de eventos de um ponto específico.

Este tag funciona de forma idêntica ao anterior, exceto pelo fato de retornar apenas os eventos de um ponto específico.

Ao contrário do anterior, o valor retornado possui apenas 1 elemento com o valor do Status do ponto, de forma que pode ser utilizado um tag PLC.

O tag deve ser configurado da seguinte forma:

· N1: Slave ID.
· N2: Código da Operação definida com a função SOE GE.
· N3: 200 + Índice do Ponto (ex: para ponto = 2, configurar 202).
· N4: Endereço base da pilha de eventos no CLP.

Tags de Tempo Real

Esses tags retornam o evento mais recente já lido para um ponto específico. Esses eventos são armazenados na memória interna do driver a cada leitura de eventos do CLP, com seus respectivos timestamps lidos do equipamento.

Este tag utiliza os seguintes parâmetros:

· B1: Slave ID.
· B2: Código da Operação.
· B3: 100 + Índice do Ponto.
· B4: Endereço base da pilha de eventos no CLP.

Ao contrário do anterior, este tag pode ser representado por um tag PLC ou por um tag Bloco com apenas um elemento. O valor retornado representa o campo Status do Ponto do evento.


Passo a Passo

Esta seção descreve os passos necessários para configurar o driver Modbus.


Inserindo o Driver

Se estiver utilizando o Elipse Scada, veja o capítulo Adicionando o driver no Elipse Scada.

Se estiver utilizando o Elipse E3, veja o capítulo Adicionando o driver no Elipse E3.


Configurando o Driver

Por favor, leia o capítulo Configurando o Driver.


Configurando o(s) Tag(s) de Comunicação

Se for utilizar tag CLP ou de Comunicação, leia o capítulo Configurando Tag CLP / Tag de Comunicação.

Se for utilizar tag Bloco, leia o capítulo Configurando Tag Bloco.


Dúvidas Mais Frequentes

1) Particularidades conhecidas do equipamento Twido da empresa Schneider.

· Está tentando ler um valor do tipo float porém não está conseguindo. No CLP, o endereço em questão possui o valor -234.5 e no Elipse está mostrando 0.

Resposta: Deve-se habilitar a opção de Swap Word nas configurações das funções de leitura e escrita Modbus.

· Está tentando ler as entradas e saídas do CLP porém não está conseguindo.

Resposta: Este equipamento não permite leitura ou escrita nas variáveis de entrada e saída, sendo necessário utilizar variáveis internas ao CLP para fazer esta ponte. Isto é, cria-se um espelho das entradas e saídas em uma área onde o driver da Elipse consiga acessar. Deve-se ainda ter o cuidado de criar uma rotina no CLP para verificar quando o valor de uma saída for alterada pelo supervisório para que a mesma seja realmente ativada ou desativada no CLP.

2) Particularidades conhecidas do equipamento MPC 6006 da empresa Atos - Schneider.

· Está tentando ler um valor do tipo DWord, porém, não está chegando o valor correto. A aplicação está apresentando valores diferentes daqueles que constam no CLP.

Resposta: Deve-se habilitar a opção de Swap Byte e Swap Word nas configurações das funções de leitura e escrita Modbus para concordar com o "byte order" utilizado pelo CLP.

NOTA: Alguns CPLs da Atos permitem que o "byte order" seja configurado pelo próprio usuário.

3) Como devo fazer para juntar dois valores do tipo Int16 (que estão no CLP) em um valor do tipo Int32 (no Elipse)?

· Tenho um número de 32 bits que está armazenados em 2 bytes de 16 bits cada um no CLP. Como devo fazer para mostrar na tela do Elipse este número como um único registro?

Resposta: Deve-se criar, na janela de configurações do Driver uma função de leitura 03 e escrita 05 com o tipo de dado Int32. Na configuração do tag de comunicação, deve-se utilizar esta função para leitura e escrita e informar o primeiro endereço das variáveis no CLP.

NOTA: Se o valor a ser lido ou escrito for sem sinal é possível ainda configurar, na janela de configurações do Driver, uma função de leitura 03 e escrita 05 com o tipo de dado sendo um Dword.
· Já tenho minha aplicação desenvolvida, porém quero saber como juntar os valores de duas Words em um único tag?

Resposta: É possível fazer esta união através do uso de scripts. Para isto deve-se multiplicar a Word que contém a parte mais alta da palavra por 32768 e então somar a Word que contém a parte mais baixa da palavra. Por exemplo: (HighWord * 32768) + LowWord.

· Preciso ler valores do tipo Float, configurei a função de leitura como sendo 03 e escrita 16 além do tipo de dado ser Float, porém aparece no Elipse um valor que não condiz com o valor que está no equipamento.

Resposta: O driver Modbus por padrão é big-endian. Como se trata de um dado de 32 bits, é necessário inverter todos os bytes. Neste caso então é necessário marcar as opções Swap Byte e Swap Word nas configurações da função de leitura e escrita na janela de configurações do Driver.

4) Como devo fazer para comunicar com mais de um equipamento em minha rede de comunicação SERIAL?

· Tenho mais de um equipamento na minha rede serial, cada um com endereço único, como devo fazer para comunicar com cada um deles?

Resposta: Deve-se ter cuidado apenas com o parâmetro N1 de cada tag pois é neste campo que deve-se indicar com qual equipamento deseja-se comunicar. As funções de leitura e escrita podem ser as mesmas para qualquer equipamento.

· Tenho mais de uma porta serial em meu computador, como devo configurar o driver para comunicar com os equipamentos que estão ligados em cada uma das portas?

Resposta: Neste caso, como existe mais de um meio físico diferente (Serial 1, Serial 2, etc.), é necessário tantos drivers de comunicação quantas portas existirem. A configuração referente a funções de leitura e escrita é a mesma para todos os drivers. A única diferença é que um driver deve ser configurado para comunicar pela Serial 1, outro driver configurado para comunicar pela Serial 2, outro driver configurado para comunicar pela Serial 3, etc.

NOTA: É importante ter o cuidado de não utilizar o mesmo arquivo DLL para todos os drivers. Sempre indicar ou fazer a cópia do arquivo renomeando-o ou fazer a cópia do arquivo e colocá-lo em outro diretório. Cada driver adicionado no Elipse deve apontar para um arquivo DLL diferente.

5) Como devo fazer para comunicar com mais de um equipamento em minha rede de comunicação SERIAL com conversor para RS485?

· Tenho uma rede RS485 com vários equipamentos comunicando através de um conversor RS232<->RS485 pela porta serial. Sempre que troco de endereço (ID) entre os equipamentos escravos, ocorre um "time-out". Após retentar a mesma mensagem, o equipamento responde normalmente. Existe alguma forma de evitar esse "time-out" durante a troca do endereço (ID)?

Resposta: Alguns conversores RS232<->RS485 requerem um invervalo de tempo para "chavearem" o endereçamento da rede RS485, para isso, utilize a opção "Inter-frame delay" na aba "Serial" da janela de configurações, experimentando valores entre 50 a 300 ms de intervalo de tempo entre as mensagens.

6) Como devo fazer para comunicar com mais de um equipamento em minha rede de comunicação ETHERNET?

· Tenho mais de um equipamento ligado em minha rede Ethernet, cada um com um endereço IP único, como devo fazer para comunicar com cada um deles?

Resposta: Atualmente, para cada endereço IP, é necessário tantos drivers de comunicação quantos endereços IP deseja-se comunicar. A configuração referente a funções de leitura e escrita é a mesma para todos os drivers. A única diferença é que um driver deve ser configurado para comunicar com o endereço IP 1, outro driver configurado para comunicar com o endereço IP 2, outro driver configurado para comunicar com o endereço IP 3, etc.

NOTA: É importante ter o cuidado de não utilizar o mesmo arquivo DLL para todos os drivers. Sempre indicar ou fazer a cópia do arquivo renomeando-o ou fazer a cópia do arquivo e colocá-lo em outro diretório. Cada driver adicionado no Elipse deve apontar para um arquivo DLL diferente.

7) Software simulador Modbus.

· Existe algum software que simule o protocolo Modbus e que se possa usar para testar junto com o driver da Elipse?

Resposta: Sim. Existe o software Modsim que simula o protocolo Modbus Slave. O mesmo pode ser adquirido em http://www.win-tech.com/html/modsim32.htm. Além disso, existe o Free Modbus PLC Simulator, disponível em www.plcsimulator.org.

8) Como configurar o parâmetro N4/B4 dos tags de comunicação.

· Como sei qual o endereço devo utilizar no parâmetro N4/B4 do meu tag de comunicação?

Resposta: Este endereço varia de equipamento para equipamento. Para saber qual o endereço exato a ser utilizado, por favor, consulte o manual do equipamento ou entre em contato com o suporte técnico do mesmo.

9) Quando utilizar os controles de RTS e DTR (que aparecem na aba Serial da janela de configurações do Driver).

Este sinais são utilizados apenas quando a comunicação entre o Elipse e o equipamento é feita através do meio físico Serial. Deve-se preferencialmente consultar a documentação do equipamento ou o suporte do fabricante para saber a configuração correta. A seguir são descritas algumas configurações conhecidas.

· Desejo comunicar com o equipamento N1100 da Novus utilizando um conversor RS232/RS485. É necessário alguma configuração especial?

Resposta: Neste caso é necessário configurar o controle RTS para Toggle.

· Desejo comunicar com o equipamento Field Logger da Novus utilizando um conversor USB/Serial e mais um RS232/RS485. É necessário alguma configuração especial?

Resposta: Neste caso é necessário configurar o controle RTS para Toggle e o controle DTR para ON.

10) Quando utilizar as funções de Swap Byte e Swap Word.

· Está tentando ler um valor do tipo Float porém não está conseguindo. No CLP, o endereço em questão possui o valor -234.5 e no Elipse está mostrando 0.

Resposta: Deve-se habilitar a opção de Swap word nas configurações das funções de leitura e escrita Modbus.

· Estou tentando ler o valor de uma variável do tipo ponto flutuante mas o valor que aparece no Elipse não é bem diferente do valor que está no CLP.

Resposta: o valor Float é composto de um byte de expoente (EXP) e mais três bytes de mantissa (F0 F1 F2), totalizando quatro bytes (32 bits). O driver Modbus espera receber o valor Float na seguinte ordem de bytes: "EXP F2 F1 F0". Eventualmente, pode existir um equipamento que envia o valor Float em uma outra ordem de bytes, como por exemplo: "F0 F1 F2 EXP". Neste caso, seria preciso reordenar os bytes recebidos do equipamento para a ordem "EXP F2 F1 F0", de modo que o driver possa interpretar corretamente o dado Float. Sendo assim, para mudar de "F0 F1 F2 EXP" para "EXP F2 F1 F0", é necessário habilitar as opções de Swap Byte e Swap Word.


Histórico de Revisões do Driver

 Topo Anterior

Versão

Data

Autor

Comentários

2.07

30/06/2010

A. Quites
· Ajustes na recepção dos dados para descartar possíveis bytes inválidos (case 11394).

C. Mello
· Atualização do tópico "Configurando Tag Especial para Leitura do Código da Última Exceção" da documentação do driver (case 11233).
· Atualização do tópico "Dúvidas Mais Freqüentes" da documentação do driver (case 11316).

2.06

26/11/2009

A. Quites
· Removido mensagem de erro falsa no arquivo de LOG para leitura de dados de memória com endereço zero (case 10654).
· Otimização da leitura do tipo bit via superblocos (case 10971).

C. Mello
· Modificada a rotina de "Wait Silence" para ser executada em qualquer erro que ocorrer no driver. O usuário também poderá executar o "Wait Silence" manualmente pela nova Tag Especial N2 = 9001 (case 10850).
· Suporte para compatibilidade com a plataforma Windows CE (case 10914).

2.05

30/06/2009

A. Quites
· Corrigido erro no Swap Address Delay (case 10425).
· Valor default para o tamanho máximo do PDU atualizado conforme versão mais recente do padrão Modbus (case 10274).
· Solucionado bug nos tags especiais de última exceção, que poderiam não reportar algumas exceções (case 10337)
· Corrigido erro no retorno do ano para registros de SOE com o dia atual (GE PAC RX7) (case 10382).
· Corrigido bug na função 20 - Read File Record (case 10312)

M. Ludwig
· Criado novo tag para ler eventos de SOE de pontos específicos do GE PAC RX7 (case 10370).

2.04

17/02/2009

A. Quites
· Corrigido erro na leitura de tipos Bit com superblocos (case 10100).
· Implementada leitura de evento GE SOE mais recente (case 10178).
· Criadas operações padrão para os tipos de funções mais comuns (case 9185).

2.03

02/09/2008

C. Mello
· Adicionado novo tipo de dado Float_GE (case 9427).

A. Quites
· Corrigido erro na configuração offline do parâmetro ModiconModbus.ModbusMode (case 9831).
· Implementada leitura de máscara de bits de registradores (case 9682).
· Implementação de leitura de buffer de eventos em controladores GE PAC RX7 (case 9523).
· Implementada possibilidade de configurar limite máximo para o PDU (case 9154).
· Corrigido bug nos recursos de reordenamento de bytes (Swap Byte, Swap Word, Swap DWord, Rev. Frame) na leitura de tipos Word com superblocos habilitado (case 9220).
· Implementada opção Enable CMS Addressing (case 8665).
· Revisões e testes em funções Modbus pouco usadas (case 8730).
· Melhorada consistência de dados escritos através da função Modbus 06 - Write Single Register (case 8663).

2.02

11/05/2007

A. Quites
· Corrigido bug na leitura de blocos de tipos não WORD com superblocos habilitado (case 8243).

2.01

23/01/2007

A. Quites
· Implementação do recurso de superblocos (case 6185).
· Melhorada consistência de parâmetros N2/B2 de tags de acesso a registros (case 7714).
· Corrigido bug na leitura de blocos de dados tipo BCD de tamanho 4 (case 7728).
· Corrigido bug na leitura de blocos de strings (case 7804).

2.00

10/11/2006

A. Quites
· Versão original com IOKit (case 3339).

1.00

R. Farina
· Todas as versões anteriores ao controle de revisões.


Configurando Tags Especiais para Leitura do Código da Última Exceção

 Topo

Conforme já mencionado neste manual, os tags especiais para leitura do código da última exceção são utilizados para ler o último código de exceção enviado por um determinado equipamento escravo.

Tais códigos são armazenados automaticamente pelo driver em registradores internos, que podem ser acessados por meio deste tag. Além disso, a cada comunicação bem sucedida com determinado equipamento, em que nenhuma exceção for retornada, o driver zera automaticamente o registrador associado ao mesmo.

Os códigos de exceção são usados pelo escravo para informar uma falha ao executar uma determinada função. Os equipamentos escravos não retornam exceções no caso de falhas de comunicação, situação em que estes simplesmente não respondem. Os códigos de exceção são retornados pelos escravos em situações em que a solicitação do mestre foi recebida com sucesso, porém não pôde ser executada por algum motivo, como por exemplo, a tentativa de ler ou escrever em um registrador inexistente. Neste caso o código de exceção retornado indica o tipo de erro ocorrido.

A especificação do protocolo Modbus define nove códigos de exceção, os quais são apresentados na tabela ao final dessa seção. Além destes códigos, alguns fabricantes definem códigos adicionais, específicos de seus equipamentos.

A forma mais usual de utilizar este tag, durante o scan normal dos tags de funções, é através de um evento OnRead do tag de exceção. Neste caso o script deve antes de tudo rejeitar valores nulos, pois estes indicam o não recebimento de exceções. Em seguida pode-se tratar a exceção, executando os procedimentos adequados, conforme o código recebido. Constitui-se uma boa prática zerar o registrador de exceção ao sair do script, de forma a indicar que a exceção já foi tratada. Veja o exemplo a seguir, em Elipse Basic (Elipse SCADA):

// EVENTO OnRead DA TAGEXC

// Obs: Para este exemplo, considere TAGEXC com leitura e escrita automatica habilitadas

IF TAGEXC == 0

RETURN

ENDIF

IF TAGEXC == 1

... // TRATA EXCECAO 1

ELSEIF TAGEXC == 2

... // TRATA EXCECAO 2

ELSE

... // TRATA DEMAIS EXCECOES

ENDIF

TAGEXC = 0 // ZERA REGISTRADOR DE EXCECOES

Já nas operações de escrita por script, em que seja preciso testar o retorno de exceções logo em seguida ao envio do comando, deve-se primeiramente zerar o registrador de exceções. Isto evita que uma eventual exceção provocada pelo comando de escrita seja confundida com uma pré-existente. Executa-se então a operação de escrita e testa-se o valor do tag especial, que deve retornar zero caso nenhuma exceção tenha sido recebida. Caso o mesmo retorne um valor diferente de zero, pode-se então tratar apropriadamente a exceção recebida. Veja o exemplo a seguir, em Elipse Basic (Elipse SCADA):

// Obs: Para este exemplo, considere TAGEXC com leitura e escrita automática habilitadas,

// e TAG com escrita automática desabilitada.

TAGEXC = 0 // ZERA REGISTRADOR DE EXCECOES

TAG = 10

TAG.WRITE()

IF TAGEXC <> 0

... // TRATA EXCECAO

ENDIF

NOTA: O tag especial B2 = 9999 retorna, além do código da exceção (retornado no elemento zero), também os parâmetros do tag cuja comunicação teria provocado a exceção. Caso essas informações não sejam necessárias, pode-se perfeitamente ler o mesmo registro através de um tag PLC com N2 = 9999. Neste caso os procedimentos recomendados permanecem os mesmos.

Códigos de exceção padronizados pelo protocolo Modbus

CÓDIGO | NOME | SIGNIFICADO
1 | ILLEGAL FUNCTION | O código de função recebido não é válido. Isso pode indicar que a função não está implementada, ou que o escravo encontra-se em um estado inadequado para processá-la.
2 | ILLEGAL DATA ADDRESS | Endereço de dados recebido não é um endereço válido. Mais especificamente, a combinação do endereço de referência e a quantidade de dados a serem transferidos é inválida.
3 | ILLEGAL DATA VALUE | Valor presente na requisição do Mestre não é válido. Isto indica uma falha na estrutura de dados remanescente de uma requisição complexa, como quando o tamanho informado para o bloco de dados não está correto. Esta exceção não indica que os valores submetidos para escrita estejam fora do escopo esperado pela aplicação, uma vez que tal informação não é acessível ao protocolo.
4 | SLAVE DEVICE FAILURE | Ocorreu um erro irrecuperável durante o processamento da função solicitada.
5 | ACKNOWLEDGE | Usado com comandos de programação. O escravo aceitou a mensagem e a está processando. Porém este processamento levará um longo tempo. Esta exceção previne um timeout no mestre. O fim da requisição deve ser testado por um processo de polling.
6 | SLAVE DEVICE BUSY | Usado com comandos de programação. Indica que o escravo está processando um outro comando de longa duração, e que a solicitação deve ser retransmitida mais tarde, quando o escravo estiver novamente disponível.
8 | MEMORY PARITY ERROR | Usado em conjunto com as funções 20 e 21, reference type 6, para indicar que a área extendida de arquivos falhou em um teste de consistência. O equipamento escravo pode estar precisando de manutenção.
0A | GATEWAY PATH UNAVAILABLE | Usado em conjunto com gateways, para indicar que o gateway não foi capaz de alocar um caminho interno para o processamento da solicitação. Geralmente indica que o gateway está desconfigurado ou sobrecarregado.
0B | GATEWAY TARGET DEVICE FAILED TO RESPOND | Usado em conjunto com gateways, para indicar que não foi recebida nenhuma resposta do equipamento destino. Geralmente indica que tal equipamento não está presente na rede.