Este documento tem como objetivo orientar desenvolvedores de sistemas, como configurar uma arquitetura de CPs redundantes da série Nexto, NX3030, utilizando as E/S do sistema acionadas por remotas MODBUS.
O objetivo principal é orientar a implementação da aplicação.
Para o melhor entendimento do funcionamento dos equipamentos é recomendado que o Manual de Usuário UCPs Série Nexto (MU214100) e o Manual de Utilização MasterTool IEC XE (MU299048) sejam consultados. A mesma recomendação aplica-se caso seja necessário modificar a arquitetura proposta como exemplo.
1. Introdução
A Série Nexto é uma poderosa e completa série de Controladores Programáveis (CP) com características exclusivas e inovadoras. Devido a sua flexibilidade, design funcional, recursos de diagnóstico avançado e arquitetura modular, o CP Nexto pode ser usado para controle de sistemas em aplicações de pequeno, médio ou grande porte.
A arquitetura da Série Nexto fornece uma grande variedade de módulos de entradas e saídas. Estes módulos, combinados com uma poderosa UCP de 32 bits e um barramento baseado em Ethernet de alta velocidade, atendem a muitas aplicações de usuário, tais como controle rápido de máquinas, complexas aplicações de processos distribuídos e redundantes, ou até mesmo grandes sistemas de E/S para automação predial. Entre outras funcionalidades, a Série Nexto oferece módulos para controle de movimento, comunicação e interfaces com as mais conhecidas redes de campo.
A tecnologia de barramento utilizada na série é baseada em Ethernet de alta velocidade, a qual permite que as entradas, saídas e informações processadas sejam compartilhadas entre todos os módulos do sistema. Os módulos de E/S podem ser facilmente distribuídos no campo, e podem ser usados tanto E/S locais quanto remotas, sem nenhuma perda no desempenho.
Adicionalmente, a Série Nexto apresenta uma ferramenta completa para programação, configuração, simulação e depuração da aplicação do usuário: o MasterTool IEC XE. Trata-se de um software flexível e de fácil utilização que oferece seis linguagens de programação definidas pela norma IEC 61131-3: Texto Estruturado (ST), Sequenciamento Gráfico de Funções (SFC), Diagrama de Blocos Funcionais (FBD), Diagrama Ladder (LD), Lista de instruções (IL) e Gráfico Funcional Continuo (CFC). O MasterTool IEC XE permite o uso de diferentes linguagens na mesma aplicação, fornecendo ao usuário uma poderosa forma de organizar a aplicação e reaproveitar códigos usados em aplicações anteriores.
A CPU NX3030 pode operar em redundância do tipo hot-standby, onde os controladores são duplicados. Um dos controladores normalmente está em estado Ativo e controlando o processo, enquanto o outro controlador normalmente está em estado Reserva, mantendo-se sincronizado com o controlador Ativo. Caso ocorra uma falha no controlador Ativo, que o impeça de continuar controlando o processo, o controlador Reserva chaveia automaticamente para Ativo, em um tempo suficientemente baixo para não perturbar o processo, sem causar descontinuidades nas saídas que controlam o processo.
A redundância hot-standby é um método utilizado para aumentar a tolerância a falhas e, consequentemente, aumentar a disponibilidade do sistema de automação. A ideia básica é que nenhuma falha simples em componentes duplicados cause a interrupção do controle do processo.
- A redundância hot-standby é muito aplicada em:
- plataformas de exploração de petróleo
- sistemas de geração e distribuição de energia
- intertravamentos de segurança (Sistemas Instrumentados de Segurança)
- processos contínuos, tais como plantas químicas, refinarias de petróleo, produção de celulose, etc.
Além dos controladores, podem ser também duplicadas, opcionalmente, as redes de campo (PROFIBUS DP), as redes de supervisão Ethernet, e as redes de controle Ethernet HSDN (High Speed Deterministic Network). Optando-se pela duplicação destas redes, obtém-se uma disponibilidade ainda maior.
A redundância hot-standby de CPs da Série Nexto não prevê duplicação de módulos de E/S. Caso a redundância de módulos de E/S seja desejável, ela pode ser tratada em nível de aplicação, pelo usuário final. Por exemplo, o usuário pode duplicar ou até mesmo triplicar um módulo de entradas analógicas, e criar um algoritmo de votação para determinar qual das entradas irá ser considerada em determinado momento em sua aplicação.
Uma solução de baixo custo e que garante a confiabilidade do sistema, é a configuração de uma arquitetura de CPs redundante com o acionamento dos módulos de E/S através de remotas MODBUS, através de rede simples ou redundante.
2. Definição da Arquitetura de Referência
A seguir mostra-se um exemplo de uma arquitetura redundante com E/S acionadas por remotas MODBUS.
Material Utilizado no Exemplo
Dentre os itens utilizados para a construção de um sistema redundante de referência temos:
CP Redundante:
- dois half-clusters idênticos
- painel de controle de redundância PX2612
- 2 cabos AL-2319 (interligações NETA e NETB entre CPA e CPB)
- 1 cabo AL-2317/A (interligação entre CPA e PX2612)
- 1 cabo AL-2317/B (interligação entre CPB e PX2612)
Cada half-cluster é constituído, no mínimo, dos seguintes módulos:
- o próprio bastidor onde os módulos são inseridos, que pode ser o NX9001, com 12 posições, NX9002, com 16 posições ou o NX9003, com 24 posições
- a fonte de alimentação NX8000, nas posições 0 e 1 do bastidor
- a UCP NX3030, nas posições 2 e 3 do bastidor
- o módulo NX4010, nas posições 4 e 5 do bastidor
A Figura 1 mostra um exemplo de configuração mínima de um CP redundante, utilizando o menor bastidor (NX9001, com 12 posições). Neste caso, observa-se que os 3 módulos inseridos no bastidor têm largura dupla (ocupam duas posições do bastidor).
Figura 1. Sistema Redundante com Remotas MODBUS
3. Configuração do CP Redundante
Para criar um projeto e configurar um sistema redundante NX3030, deve-se utilizar o software MasterTool IEC XE.
Não será descrito aqui o processo de instalação e autorização de funcionamento do software MasterTool IEC XE. Considera-se que o mesmo já esteja instalado, configurado e funcionando perfeitamente em um computador.
O Software MasterTool IEC XE utilizado no desenvolvimento abaixo é de versão 1.23.
3.1. Novo Projeto
Neste capítulo, será abordada a criação de um novo projeto a partir do perfil Simples, utilizando a ferramenta "Wizard", a qual apresenta as opções de configuração do sistema ao usuário.
Inicialmente, o usuário deverá criar um novo projeto no MasterTool IEC XE a partir do menu Arquivo e logo em seguida, "Novo Projeto...", conforme mostra a Figura 2:
Figura 2. Novo Projeto
Após, uma janela será apresentada ao usuário, solicitando que o mesmo selecione o tipo de projeto que deseja fazer e, em seguida, escreva um nome e a localização para armazenar o projeto no computador. Clicar em OK para prosseguir ou Cancelar para interromper.
Figura 3. Classificação do Projeto
A seguir, o usuário deverá selecionar a UCP desejada, os módulos de hardware básicos que compõem o barramento, ou seja, o modelo de bastidor e de fonte de alimentação e a configuração de redundância. Nesse caso, será utilizada a UCP NX3030 (com redundância), um bastidor NX9001 e uma fonte de alimentação NX8000.
Figura 4. Módulos de Hardware
Na janela de configuração de redes, o usuário deverá selecionar a quantidade de redes PROFIBUS e a quantidade de redes Ethernet adicionais. No exemplo proposto não utilizaremos nenhuma rede adicional.
Figura 5. Quantidade de Redes PROFIBUS e Ethernet
Então, o usuário deverá selecionar a linguagem padrão para as POUs (programas). Nesse caso o novo projeto está exemplificado perfil Simples e linguagem ST.
Figura 6. Seleção da Linguagem Padrão
A próxima tela define a linguagem das POUs de usuário não redundante (NonSkippedPrg) e redundante (ActivePrg) . Clicar em Anterior para voltar à tela antecedente, Concluir para finalizar ou Cancelar para interromper.
Figura 7. Linguagem dos Programas das Tarefas Principais
Ao pressionar o botão Concluir, o MasterTool IEC XE iniciará a criação do ambiente de desenvolvimento do projeto. Esse procedimento pode levar alguns segundos.
4. Configurações das Portas Ethernet da UCP NX3030 (NET 1 e NET 2)
4.1. Configuração do Endereço de IP
A Figura 8 mostra as configurações da porta NET 1 da UCP NX3030. Para abrir esta tela, deve-se dar um duplo clique sobre NET 1, abaixo da UCP NX3030 na árvore de dispositivos. Nesta tela deve-se definir o IP que o CP vai assumir quando operar no modo ativo e os IPs de cada Half-Cluster.
Figura 8. Parâmetros da Porta Ethernet NET 1
4.2. NIC Teaming entre NET 1 e NET 2
A opção Avançado, na tela de configuração da interface NET 1, abre uma nova tela de configuração, a qual define se NET 1 será redundante. Habilitando o checkbox de Redundância de Comunicação, as interfaces NET 1 e NET 2 formarão um par redundante com NIC Teaming. Automaticamente, outros parâmetros serão habilitados e deverão ser configurados:
• Período de Teste da Redundância (ms): Período de envio do frame de teste de comunicação entre as duas NETs. Pode ser configurado com valores entre 100 e 9900.
• Número de Retentativas do Teste da Redundância: Numero máximo de vezes que a NET que enviou o frame irá esperar pela resposta. Pode ser configurado com valores entre 1 e 100.
• Período para Chaveamento (s): Tempo máximo que a NET Ativa irá esperar por um pacote qualquer. Pode ser configurado com valores entre 1 e 25.
Figura 9. Configurações Avançadas da Ethernet
Caso o tempo de resposta do Teste da Redundância atinja Período de Teste vezes o Número de Retentativas e a interface ativa permaneça por um tempo maior que o Período para Chaveamento sem receber nenhum pacote, ocorrerá um switchover, tornando ativa a interface que até então estava inativa. É importante ressaltar que há um delay entre a detecção da falha e ativação da interface inativa devido ao tempo necessário para sua configuração. Tal delay pode chegar a algumas dezenas de milisegundos.
Quando uma das NETs estiver ativa, esta assumirá o endereço de IP configurado, permanecendo a NET inativa com seus parâmetros de Endereço de IP, Máscara de Subrede e Endereço do Gateway em branco nos diagnósticos da UCP.
5. Configuração da rede MODBUS
O primeiro passo para configurar a rede MODBUS é incluir uma instância na NET desejada (neste caso NET 1, pois a UCP NX3030 está operando com NIC Teaming entre NET 1 e NET 2). Clicar com o botão direito sobre a NET 1 e selecionar "Acrescentar Dispositivo...", conforme mostra a Figura 10:
Figura 10. Adicionando a Instância
Após, surgirá na tela os protocolos disponíveis ao usuário. Nesse caso, "MODBUS Ethernet Client" e "MODBUS Ethernet Server". Clicar em Acrescentar, conforme mostra a Figura 11:
Figura 11. Selecionando o Protocolo
5.1. MODBUS Client
Conforme a Figura 11, acrescentar uma instância MODBUS Cliente.
O próximo passo indica a inserção de uma relação MODBUS cliente, Figura 4 11. No exemplo em questão serão inseridos quatro clientes MODBUS. Um para a comunicação entre o CP ativo e CPA e outro para a comunicação entre CP ativo e CPB, os outros dois clientes são destinados para a comunicação com duas remotas MODBUS.
Todos os comandos e diagnósticos referentes aos clientes MODBUS devem ser mapeados em áreas de memória não redundante.
Figura 12. Inserção das Relações MODBUS Client
O próximo passo, Figura 13 e Figura 14, indica a inserção dos mapeamentos MODBUS em cada Cliente. Cada cliente que comunica o CP ativo com os CPA e CPB, deve possuir uma relação de Hoding Register de 120 posições, iniciando do endereço 1. A área de memória mapeada nos diagnósticos deve ser não redundante.
Os Clientes referentes às remotas MODBUS, devem ter seus diagnósticos mapeados em áreas não redundantes, e as áreas de memória referentes às E/S devem ser áreas redundantes.
Figura 13. Mapeamento das Relações MODBUS
Figura 14. Tela de Mapeamento de uma Relação MODBUS
5.2. Mapeamento MODBUS Cliente
Segue abaixo o mapeamento MODBUS Cliente utilizado no exemplo:
Descrição | Configuração | |
Endereço Inicial de Diagnósticos em %Q | 90000 | |
Tamanho | 20 | |
Protocolo | TCP |
Tabela 1. Configuração do Cliente MODBUS
A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com o CPA:
Descrição | Configuração |
Nome da Instância | MODBUS_NACT_PLCA |
IP de Destino | 192.168.17.52 |
Porta TCP | 502 |
Desabilitação dos Mapeamentos | 90020 |
MODBUS_NACT_PLCA_Mapping_000 - Holding Register | |
Descrição | Configuração |
Função | Ler |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90036 |
Endereço Inicial de Leitura | 1 |
Tamanho dos Dados de Leitura | 120 |
Variável IEC de Leitura | 10000 |
Tabela 2. Dispositivo 0
A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com o CPB:
Descrição | Configuração |
Nome da Instância | MODBUS_NACT_PLCB |
IP de Destino | 192.168.17.53 |
Porta TCP | 502 |
Desabilitação dos Mapeamentos | 90024 |
MODBUS_NACT_PLCB_Mapping_000 - Holding Register | |
Descrição | Configuração |
Função | Ler |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90044 |
Endereço Inicial de Leitura | 1 |
Tamanho dos Dados de Leitura | 120 |
Variável IEC de Leitura | 10240 |
Tabela 3. Dispositivo 1
A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com a remota MODBUS 1. O mapeamento 0 se refere aos pontos de saída que serão acionados e o mapeamento 1 se refere os pontos de entrada que serão lidos da remota MODBUS.
O usuário pode inserir outros mapeamentos, a fim de ampliar a quantidade de pontos E/S controlados na remota MODBUS.
Descrição | Configuração |
Nome da Instância | REMOTA_MODBUS_01 |
IP de Destino | 192.168.17.49 |
Porta TCP | 502 |
Desabilitação dos Mapeamentos | 90028 |
REMOTA_MODBUS_01_Mapping_000 - Holding Register | |
Descrição | Configuração |
Função | Escrever |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90052 |
Endereço Inicial de Escrita | 1 |
Tamanho dos Dados de Escrita | 120 |
Variável IEC de Escrita | 10000 |
REMOTA_MODBUS_01_Mapping_001 - Holding Register | |
Descrição | Configuração |
Função | Ler |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90060 |
Endereço Inicial de Leitura | 121 |
Tamanho dos Dados de Leitura | 120 |
Variável IEC de Leitura | 10480 |
Tabela 4. Dispositivo 2
A tabela abaixo descreve a configuração MODBUS utilizada para comunicar o CP ativo com a remota MODBUS 2. O mapeamento 0 se refere aos pontos de saída que serão acionados e o mapeamento 1 se refere os pontos de entrada que serão lidos da remota MODBUS.
O usuário pode inserir outros mapeamentos, a fim de ampliar a quantidade de pontos E/S controlados na remota MODBUS.
Descrição | Configuração |
Nome da Instância | REMOTA_MODBUS_02 |
IP de Destino | 192.168.17.50 |
Porta TCP | 502 |
Desabilitação dos Mapeamentos | 90032 |
REMOTA_MODBUS_02_Mapping_000 - Holding Register | |
Descrição | Configuração |
Função | Escrever |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90068 |
Endereço Inicial de Escrita | 1 |
Tamanho dos Dados de Escrita | 120 |
Variável IEC de Escrita | 10240 |
REMOTA_MODBUS_02_Mapping_001 - Holding Register | |
Descrição | Configuração |
Função | Ler |
Endereço do Escravo | 1 |
Polling (ms) | 100 |
Área de Diagnóstico do Mapeamento | 90076 |
Endereço Inicial de Leitura | 121 |
Tamanho dos Dados de Leitura | 120 |
Variável IEC de Leitura | 10720 |
Tabela 5. Dispositivo 3
5.3. MODBUS Server
Conforme a Figura 11, acrescentar uma instância MODBUS Server.
O próximo passo indica a inserção de uma relação MODBUS Servidor, Figura 15. No exemplo em questão é inserido um servidor MODBUS, para a comunicação entre CP ativo e CP não ativo.
Todos os comandos e diagnósticos referentes ao servidor MODBUS devem ser mapeado em áreas de memória não redundante.
Figura 15. Inserção da Relação MODBUS Server
Figura 16. Tela de Mapeamento de uma Relação MODBUS Server
5.4. Mapeamento MODBUS Servidor
Segue abaixo o mapeamento MODBUS Servidor utilizado no exemplo:
Descrição | Configuração | |
Endereço Inicial de Diagnósticos em %Q | 90084 | |
Tamanho | 20 | |
Porta TCP | 502 | |
Desabilitação dos Mapeamentos | 90104 | |
Protocolo | TCP |
Tabela 6. Configuração do Servidor MODBUS
Descrição | Configuração | |
Endereço Inicial do Dado | 1 | |
Tamanho do Dado | 120 | |
Variável IEC | 92000 |
Tabela 7. Relação 0 - Holding Register
6. Código Fonte
Este capitulo descreve o código fonte a ser inserido pelo usuário na aplicação, afim gerenciar a comunicação com as remotas MODBUS e o comportamento do sistema redundante em caso de falha.
6.1 Criando as POUs
Uma POU (Program Organization Unit, ou Unidade de Organização de Programa), é uma subdivisão do programa aplicativo que pode ser escrito em qualquer uma das linguagens disponíveis no software MasterTool IEC XE.
Com a criação do projeto através de um perfil selecionado, algumas POUs já são criadas, porém o usuário poderá criar quantas quiser, limitado pelo tamanho máximo da memória de programa.
Para inserir uma nova POU, basta clicar com o botão direito sobre o nome da aplicação, (nome padrão criado para a aplicação é "Application"), selecionar "Acrescentar Objeto" e, então, "POU...", conforme mostra a Figura 17:
Figura 17. Inserindo POUs
Uma janela de configuração irá surgir na tela, na qual o usuário deve colocar o nome da POU, selecionar o tipo e a linguagem que se deseja implementar. A seguir, deve clicar em Abrir.
Figura 18. Classificando a POU
Para editar a POU basta selecionar a aba com o nome correspondente e iniciar o desenvolvimento da aplicação na linguagem escolhida anteriormente. O mesmo procedimento é válido para as POUs criadas automaticamente pelo perfil do projeto.
Figura 19. Editando a POU
6.2. MODBUS_Manager
A POU MODBUS_Manager, do tipo programa, é responsável pelo gerenciamento das relações MODBUS e Switchover entre CPs.
De acordo com o código exemplificado abaixo, se ocorrerem falhas MODBUS na comunicação entre Clusters e entre o CP Ativo e as remotas, será executado um Switchover.
O tempo de Switchover é a soma do tempo configurado no temporizador TemporizadorSwitchoverMasterModBus com o tempo que leva para ser detectada a falha na função FALHA_MODBUSClient. Este deve ser maior que o Timeout e maior que o Período para Chaveamento do NIC Teaming.
Caso o usuário deseje incluir novas remotas MODBUS, deve-se incluir na linha "// Calcula falha geral Master ModBus", sua consistência de falha.
Código Fonte:
PROGRAM MODBUS_Manager
VAR
TemporizadorSwitchoverMasterModBus : TON_NR;
EstadoAtivo : BOOL;
EstadoReserva : BOOL;
EstadoInativo : BOOL;
EstadoOutroReserva : BOOL;
ExecutarSwitchoverMasterModBus : BOOL;
AguardarStandby : BOOL;
ChavearInativo : BOOL;
eRedStateLocal: BYTE;
eRedStateLocal_old: BYTE;
END_VAR
EstadoAtivo := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.ACTIVE);
EstadoReserva := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.STANDBY);
EstadoInativo := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.INACTIVE);
EstadoOutroReserva := (DG_NX4010.tRedundancy.RedDgnRem.sGeneral_Diag.eRedState = REDUNDANCY_STATE.STANDBY) AND
DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bExchangeSync;
// Leitura do estado atual do CP local
eRedStateLocal := DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState;
// O estado do CP local mudou?
IF eRedStateLocal <> eRedStateLocal_old THEN
IF eRedStateLocal = REDUNDANCY_STATE.ACTIVE THEN
// CP local entrou em estado Ativo
Diagnostics.DG_MODBUS_Client.tCommand.bRestart:= TRUE;
ELSE
// CP local entrou em um estado Não Ativo
Diagnostics.DG_MODBUS_Client.tCommand.bStop:= TRUE;
END_IF
// Salva o último estado do CP local
eRedStateLocal_old:= eRedStateLocal;
END_IF
// Lógica de falha geral Master ModBus - Switchover
FAL_GERAL_MODBUS:= (FAL_MODBUS_NACT_PLCA OR FAL_MODBUS_NACT_PLCB) AND FAL_REMOTA_MODBUS_01 AND FAL_REMOTA_MODBUS_02;
// Gerencia switchover automático do Master ModBus
TemporizadorSwitchoverMasterModBus(IN := FAL_GERAL_MODBUS AND EstadoAtivo AND EstadoOutroReserva, PT := T#5S, Q => ExecutarSwitchoverMasterModBus);
IF ExecutarSwitchoverMasterModBus THEN
DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal := TRUE;
AguardarStandby := TRUE;
END_IF
IF (AguardarStandby AND EstadoReserva) THEN
DG_NX4010.tRedundancy.RedCmdLoc.bInactiveLocal := TRUE;
END_IF
IF EstadoInativo THEN
AguardarStandby := FALSE;
END_IF
6.3. FALHA_MODBUSClient
A POU FALHA_MODBUSClient, do tipo função, é responsável por acionar os bits de falha de comunicação caso ocorra algum erro no respectivo cliente MODBUS, pelo tempo especificado na entrada PT.
Caso o usuário deseje incluir novas remotas MODBUS, deve-se incluir novos temporizadores.
Código Fonte:
FUNCTION FALHA_MODBUSClient : BOOL
VAR
END_VAR
// Seção para cálculo de falha na comunicação, chamando função de diagnóstico de mapeamento MODBUS
TEMP_FAL_MODBUS_NACT_PLCA(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_MODBUS_NACT_PLCA_Mapping_000), PT:= T#2500MS, Q=> FAL_MODBUS_NACT_PLCA);
TEMP_FAL_MODBUS_NACT_PLCB(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_MODBUS_NACT_PLCB_Mapping_000), PT:= T#2500MS, Q=> FAL_MODBUS_NACT_PLCB);
TEMP_FAL_REMOTA_MODBUS_01(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_REMOTA_MODBUS_01_Mapping_000), PT:= T#2500MS, Q=> FAL_REMOTA_MODBUS_01);
TEMP_FAL_REMOTA_MODBUS_02(IN:= FALHA_MODBUS_EthMapping(DG_MODBUS_Client, DG_REMOTA_MODBUS_02_Mapping_000), PT:= T#2500MS, Q=> FAL_REMOTA_MODBUS_02);
6.4. FALHA_MODBUS_EthMapping
Esta POU é do tipo função e é responsável por identificar na estrutura de diagnósticos do cliente MODBUS referenciado, se existe alguma falha.
Código Fonte:
FUNCTION FALHA_MODBUS_EthMapping : BOOL
VAR_INPUT
DgClient : T_DIAG_MODBUS_ETH_CLIENT_1;
DgMap : T_DIAG_MODBUS_ETH_MAPPING_1;
END_VAR
VAR
END_VAR
FALHA_MODBUS_EthMapping:= DgClient.tDiag.bNotRunning OR DgMap.byStatus.bCommError OR DgMap.byStatus.bCommAborted;
6.5. GVL_MODBUS
Esta lista de variáveis globais declara os temporizadores utilizados para acionar o diagnóstico de falha de um cliente MODBUS, caso ocorra alguma falha por um tempo superior ao definido na função FALHA_MODBUSClient().
Caso o usuário deseja incluir novas remotas MODBUS, deve-se declarar novos temporizadores.
Código Fonte:
VAR_GLOBAL
// Temporizador de falha de comunicação com PLCA não ativo
TEMP_FAL_MODBUS_NACT_PLCA: TON;
// Temporizador de falha de comunicação com PLCB não ativo
TEMP_FAL_MODBUS_NACT_PLCB: TON;
// Temporizador de falha de comunicação com a Remota ModBus 01
TEMP_FAL_REMOTA_MODBUS_01: TON;
// Temporizador de falha de comunicação com a Remota ModBus 02
TEMP_FAL_REMOTA_MODBUS_02: TON;
END_VAR
6.6. GVL_MODBUS_Persist
Esta lista de variáveis globais declara as variáveis do tipo persistente, utilizadas para indicar os clientes MODBUS que apresentam falha.
Caso o usuário deseje incluir novas remotas MODBUS, deve-se declarar novas variáveis.
Código Fonte:
VAR_GLOBAL PERSISTENT
FAL_GERAL_MODBUS: BOOL; // Falha de comunicação geral
FAL_MODBUS_NACT_PLCA: BOOL; // Falha de comunicação com PLCA não ativo
FAL_MODBUS_NACT_PLCB: BOOL; // Falha de comunicação com PLCB não ativo
FAL_REMOTA_MODBUS_01: BOOL; // Falha de comunicação com a Remota MODBUS 01
FAL_REMOTA_MODBUS_02: BOOL; // Falha de comunicação com a Remota MODBUS 02
END_VAR
6.7. NonSkippedPrg
Esta linha de código deve ser copiada dentro da POU NonSkippedPrg.
Código Fonte:
// Gerenciamento das Remotas Modbus
MODBUS_Manager();
6.8. ActivePrg
Esta linha de código deve ser copiada dentro da POU ActivePrg.
Código Fonte:
// Tratamento de alarmes Master ModBus Client
FALHA_MODBUSClient();
7. Redundancy Configuration
A Figura 20 indica quais objetos devem ser selecionados como redundantes através da aba Redundancy Configuration.
Figura 20. Redundancy Configuration
8. Desempenho
Na arquitetura proposta tanto a CPU redundante, como as Remotas MODBUS, foram configuradas para operar com um tempo de ciclo de execução de aplicação de usuário de 100 ms.
Através desta configuração foi possível obter uma taxa de atualização das entradas e saídas do sistema de 200 ms.
O tempo de execução ocupado pela "MainTask" no CP ativo do sistema redundante foi de 19 ms.
Comentários
0 comentário
Por favor, entre para comentar.