<< Clique para Mostrar o Sumário >>
Dúvidas Mais Frequentes |
•A aplicação está tentando ler um valor do tipo Float, porém não está conseguindo. O valor mostrado no CLP está totalmente diferente do mostrado na aplicação para o mesmo endereço.
•Resposta: Este CLP não utiliza o ordenamento de bytes padrão do protocolo, ou big endian. Deve-se configurar o ordenamento de bytes executando o swap ou permuta de Words, o que corresponde à opção "b2" na configuração por Strings, ou a selecionar a opção Swap Words nas configurações das operações da configuração numérica. Para mais informações, consulte o tópico Aba Operations.
•A aplicação 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, e é necessário utilizar variáveis internas ao CLP para realizar esta leitura, isto é, cria-se um espelho das entradas e saídas em uma área onde este Driver consiga acessar. Deve-se ainda ter o cuidado de criar uma rotina no CLP para verificar quando o valor de uma saída é alterado pela aplicação para que seja realmente ativada ou desativada no CLP.
•A aplicação está tentando ler um valor do tipo DWord, porém o valor correto não está chegando. A aplicação apresenta valores diferentes daqueles que constam no CLP.
•Resposta: Consulte o artigo Utilizando drivers Modbus Master (ASC/RTU/TCP) com controladores ATOS no Elipse Knowledgebase. Caso esteja usando a nova configuração por Strings, os campos Dispositivo e Item, consulte também o item Byte Order do tópico Configuração por Strings. Caso esteja utilizando a antiga configuração numérica, os parâmetros N/B, consulte também o tópico Aba Operations, sobretudo o item Byte Order.
•Existe um número de 32 bits que está armazenado em dois registradores de 16 bits cada um no CLP. Como mostrar na tela da aplicação este número como um único registro de 32 bits?
•Resposta: Deve-se criar Tags utilizando tipos de dados de 32 bits, como por exemplo os tipos de dados Float, DWord ou Int32. Na configuração do Tag de Comunicação, deve-se informar o primeiro endereço de cada variável no CLP. Para mais informações, consulte o tópico Configurando um Tag de Comunicação. Com isto, este Driver une dois registros de 16 bits do equipamento em um único valor de 32 bits, retornado no campo Valor do Tag ou no Elemento do Tag Bloco. Caso esteja usando a configuração por Strings, os campos Dispositivo e Item, informe o tipo de dados desejado logo após o endereço do registro. Para mais informações, consulte o tópico Configuração por Strings. Caso esteja utilizando a antiga configuração numérica, os parâmetros N/B, é necessário definir operações com tipos de dados de 32 bits. Note que, na aba Operations da janela de configuração, os tipos de dados de 32 bits são sempre mostrados com tamanho, o campo Size, de quatro bytes. Para mais informações, consulte o tópico Tipos de Dados Suportados.
•A aplicação já está desenvolvida, porém é preciso juntar os valores de dois Words em um único Tag.
•Resposta: É possível realizar esta união através do uso de scripts, criando um inteiro de 32 bits sem sinal. Para isto, deve-se multiplicar o Word que contém a parte mais alta da palavra por 65536 e então somar o Word que contém a parte mais baixa da palavra, como por exemplo UInt32 = (HighWord × 65536) + LowWord.
•A aplicação precisa ler valores do tipo Float. A função de leitura foi configurada como 03 e escrita 16 com o tipo de dados Float. Porém, a aplicação E3 ou Elipse Power mostra um valor que não condiz com o valor que está no equipamento.
•Resposta: O protocolo Modbus oficial usa o ordenamento de bytes, ou byte order, no padrão big endian, com os bytes mais significativos de cada valor vindo antes. Se este Driver está lendo valores absurdos, mesmo com a configuração correta do endereço, é muito provável que o equipamento utilize um byte order diferente do padrão do protocolo. Neste caso, é necessário configurar as opções de permuta ou swap. Caso esteja usando a configuração por Strings , os campos Dispositivo e Item, consulte o item Byte Order do tópico Configuração por Strings. Caso esteja utilizando a antiga configuração numérica, os parâmetros N/B, consulte o item Byte Order do tópico Aba Operations para mais informações sobre como utilizar as opções de swap.
•Existe mais de um equipamento na rede serial, cada um com endereço único. Como comunicar com cada um deles?
•Resposta: Deve-se ter cuidado apenas com o Slave Id de cada Tag de Comunicação, pois é neste campo que deve-se indicar com qual equipamento deseja-se comunicar. Em redes seriais RS485, todos os equipamentos escutam ao mesmo tempo as requisições deste Driver, ou seja, há um barramento único, porém apenas o que possuir o Slave Id correspondente responde à requisição, pois não pode haver múltiplos equipamentos com o mesmo Id. Na configuração por Strings, este valor pode ser fornecido no campo Dispositivo, ou no início do campo Item. Para mais informações, consulte o tópico Configuração por Strings. No caso da configuração numérica, este valor é fornecido nos parâmetros N1/B1 de cada Tag. Pode-se usar as mesmas operações para Tags de diversos equipamentos. Uma boa referência para maiores informações sobre a instalação e manutenção de redes seriais é o livro Serial Port Complete, de Jan Axelson.
•Existe mais de uma porta serial no computador. Como configurar este 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, como por exemplo Serial 1, Serial 2, e assim por diante, são necessários tantos Drivers de Comunicação quantas portas existirem. As configurações dos Tags deste Driver podem ser as mesmas para todos os objetos ou instâncias deste Driver. A única diferença é que um Driver deve ser configurado para comunicar pela porta Serial 1, outro Driver configurado para comunicar pela porta Serial 2, e assim por diante. As configurações da porta a ser usada são realizadas na aba Serial da janela de configurações deste Driver. Para mais informações, consulte o tópico Propriedades.
•Uma rede RS485 tem vários equipamentos comunicando através de um conversor RS232-RS485 pela porta Serial. Sempre ocorre a troca de endereço (Slave ID), ou seja, quando este Driver vai solicitar dados de outro equipamento, ocorre um time-out. Após retentar a mesma mensagem, o equipamento responde normalmente. Existe alguma forma de evitar este time-out durante a troca do endereço ou Slave ID?
•Resposta: Alguns conversores RS232-RS485 requerem um intervalo de tempo para chavearem, ou seja, comutarem do modo de transmissão para recepção, ou vice-versa. Para contornar esta limitação, pode-se utilizar a opção Inter-frame delay na aba Serial da biblioteca IOKit, disponível na janela de configurações. Esta opção define um intervalo de tempo entre mensagens. O valor exato do intervalo depende do conversor utilizado mas, em caso de incerteza, recomenda-se iniciar experimentando valores entre 50 ms e 300 ms.
NOTA |
A opção Inter-frame delay da biblioteca IOKit pode trazer significativo prejuízo de performance em algumas aplicações, devendo ser utilizada apenas quando absolutamente necessário. Certifique-se de que o conversor está em boas condições e se de fato exige a utilização deste delay. Se necessário, contate o suporte do fabricante. |
•Existe mais de um equipamento ligado em uma rede Ethernet, cada um com endereço IP único. Como 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 aos Tags deste Driver pode ser a mesma para todos os Drivers. A única diferença é que um Driver deve ser configurado para comunicar com o endereço IP 1 (um), outro Driver configurado para comunicar com o endereço IP 2 (dois), e assim por diante. O parâmetro Slave Id pode ainda ser utilizado em modo Modbus TCP para diferenciar equipamentos conectados a um gateway Modbus Ethernet / RS485 no mesmo endereço IP. Note que este gateway não apenas deve permitir a interconexão entre redes Ethernet e seriais, mas também converter frames ModbusTCP para os modos seriais suportados pelos equipamentos, ModbusRTU ou ModbusASC. O endereço IP deve ser configurado na aba Ethernet da biblioteca IOKit, na janela de configurações deste Driver.
DICA |
Evite usar o modo RTU ou ASC do protocolo encapsulado em meio TCP/IP. Caso seja necessário encapsular a comunicação serial de equipamentos que utilizem o Modbus RTU em TCP/IP, existem gateways disponíveis no mercado que não somente encapsulam a comunicação serial em Ethernet TCP/IP, as camadas física, de rede e de transporte, como também convertem o Modbus RTU em Modbus TCP, a camada de aplicação. Em último caso, se é inevitável a utilização de Modbus RTU em meio Ethernet TCP/IP, não deixe de habilitar a opção Reconnect after Timeout, descrita no tópico Aba Modbus. |
•Existe algum software que simule o protocolo Modbus e que possa ser utilizado para testes junto com este Driver?
•Resposta: Sim, existem diversas alternativas. A Elipse Software disponibiliza uma versão gratuita (demo) do Elipse Modbus Simulator, que permite simular os recursos mais básicos do protocolo. Há também a possibilidade de usar o Driver Modbus Slave da Elipse Software como emulador. Outra possibilidade é o software Modsim, uma das mais antigas e conhecidas alternativas para emular um dispositivo Modbus escravo. Este simulador pode ser adquirido em http://www.win-tech.com/html/modsim32.htm. Além deste, existe também a alternativa gratuita do Free Modbus PLC Simulator, disponível em http://www.plcsimulator.org. Existem ainda outras opções e uma lista de outras aplicações pode ser encontrada no site da Modbus.org.
•Qual endereço utilizar no parâmetro N4/B4 do Tag de Comunicação?
•Resposta: Este endereço varia de equipamento para equipamento. Para saber qual o endereço exato a ser utilizado, consulte o manual do equipamento ou entre em contato com o suporte técnico. O tópico Dicas de Endereçamento (Modbus Convention) deste manual contém algumas dicas de convenções comuns usadas por muitos fabricantes.
•O equipamento está comunicando diretamente na porta serial RS232 do computador. Como devo configurar os controles RTS e DTR?
•Resposta: Deve-se consultar a documentação do equipamento ou o suporte do fabricante para saber a configuração correta.
•O equipamento está comunicando através de um conversor RS232-RS485 ligado à porta serial RS232 do computador. Como configurar os controles RTS e DTR?
•Resposta: Na comunicação com equipamentos usando conversores RS232-RS485, tais configurações dependem do conversor. O equipamento, ou Slave, não tem influência, já que estes sinais só existem no lado serial RS232, não tendo equivalentes no meio serial RS485. O controle RTS é geralmente utilizado em conversores mais antigos para o chaveamento entre os modos de transmissão e recepção, pois o RS485 é half-duplex, devendo nestes casos em geral ser configurado no modo Toggle. Existem alguns raros equipamentos que exigem outras configurações. Na maioria dos conversores mais recentes, entretanto, o chaveamento entre transmissão e recepção é automático, e estes sinais em geral não são mais usados, podendo ser ignorados. Em caso de dúvidas, consulte o manual do conversor ou o suporte do fabricante.
Estas opções devem ser usadas para tipos de dados de 16, 32 ou 64 bits, cuja ordem dos bytes do valor fornecido por um equipamento não corresponde à ordem padrão do protocolo Modbus, onde os bytes mais significativos vêm sempre antes, ou padrão big endian, também chamado Motorola. Se este Driver está lendo valores absurdos ou diferentes dos valores armazenados no CLP, é possível que esteja utilizando um byte order diferente do padrão do protocolo. Para mais informações, consulte o item Byte Order do tópico Configuração por Strings, ou caso esteja usando a antiga configuração numérica, os parâmetros N/B, consulte o item Byte Order do tópico Aba Operations. Também recomenda-se consultar a documentação do equipamento.
•A aplicação está tentando ler um valor Word, porém o valor vem diferente do que está configurado no CLP. Se no CLP é configurado o valor "1" (um), na aplicação aparece o valor "256".
•Resposta: O valor 1 (um) em hexadecimal é 0001H e o valor 256 em hexadecimal corresponde a 0100H. O equipamento possui um byte order diferente do padrão do protocolo. Deve-se habilitar a opção Swap Bytes, a opção "b1" na configuração por Strings, para ler o valor correto.
•A aplicação tem um Tag configurado para ler um valor DWord, mas o valor lido pela aplicação é diferente do valor armazenado no CLP. Ao atribuir o valor "258", por exemplo, ao registro no CLP, na aplicação aparece o valor absurdo "16908288".
•Resposta: O valor 258 em hexadecimal é 00000102H e o valor 16908288 em hexadecimal corresponde a 01020000H. O equipamento possui um byte order diferente do padrão do protocolo, onde o Word menos significativo vem antes. Neste caso, deve-se habilitar a opção Swap Words, a opção "b2" na configuração por Strings, para ler o valor correto.
•Resposta: Na configuração dos Tags de Comunicação, deve-se habilitar a opção de ordenamento de bytes Swap Words, correspondente à opção "b2" na configuração por Strings. Caso esteja usando a antiga configuração numérica, os parâmetros N/B, consulte o item Byte Order do tópico Aba Operations.
•A aplicação no E3 ou no Elipse Power está tentando ler registros ou bits do CLP, mas sempre ocorrem erros.
•Resposta: Os equipamentos desta série não permitem o uso de Superblocos do E3 ou do Elipse Power pelos seguintes motivos:
•Existem descontinuidades no mapa de endereços de registradores dos equipamentos, com intervalos de endereços não definidos.
•O tamanho máximo do PDU é diferente do estabelecido pelo padrão do protocolo, e é definido como um tamanho que suporte 96 Words ou Bits. Uma vez que o protocolo agrupa oito bits em cada byte de dados, isto resulta em tamanhos máximos de PDU diferentes para as funções de leitura de Bits e Words, o que impossibilita o uso da customização do tamanho máximo do PDU permitida por este Driver, que não permite configurar limites diferentes para cada função do protocolo.
•Solução: Siga estes passos:
1.Desabilite a leitura por Superblocos, configurando a propriedade EnableReadGrouping deste Driver para Falso.
2.Dê preferência à definição de Tags Bloco, agrupando o maior número possível de variáveis no menor número de Blocos, respeitando o limite do equipamento de 96 Words ou 96 Bits em cada Bloco. Para mais informações, consulte a seção sobre Agrupamento Manual no tópico Leitura por Superblocos (Agrupamento).
NOTA |
Pode ainda ser possível utilizar o agrupamento automático, ou Superblocos, caso não seja preciso ler Words e Bits no mesmo objeto Driver, dependendo obviamente do intervalo de endereços que se precise ler, mais especificamente, se este intervalo possui ou não descontinuidades. Neste caso, de qualquer forma, é necessário configurar a propriedade Customize Max. PDU Size na aba Modbus, de acordo com o limite de 96 Words, 96 × 2 = 192 bytes, ou 96 Bits, 96 ÷ 8 = 12 bytes. Tal possibilidade pode ser avaliada com cuidado, caso a caso, pelo desenvolvedor da aplicação. |
•Resposta: O aparecimento desta mensagem não indica erro de comunicação ou de configuração. Recomenda-se apenas que o usuário verifique na programação do CLP por que está retornando valores não normalizados.
•Informações Adicionais: Tal mensagem indica que o equipamento enviou a este Driver um valor de ponto flutuante, um Float, no formato IEEE 754, porém não normalizado. Tais valores podem resultar de operações aritméticas com resultados que extrapolem as possibilidades de representação deste formato, como por exemplo as condições de overflow, underflow, +∞ e −∞, entre outras. Os valores não normalizados estão previstos na norma IEEE 754, não devendo em tese gerar problemas para este Driver ou para a aplicação. Entretanto, devido à detecção de erros no passado relacionada a tipos específicos de hardware, este Driver passou a retornar 0 (zero) para uma aplicação ao receber valores não normalizados de um equipamento, registrando esta mensagem em log.