Pessoal,
Agradeço a todos que visitaram o blog e que muito me incentivaram em 2006.
Espero que 2007 seja para todos, um ano de conquistas e realizações, assim como 2006 foi para mim.
Abraços,
Márcio Roberto
Pessoal,
Agradeço a todos que visitaram o blog e que muito me incentivaram em 2006.
Espero que 2007 seja para todos, um ano de conquistas e realizações, assim como 2006 foi para mim.
Abraços,
Márcio Roberto
Recentemente o Gabriel me questionou sobre como detectar falhas de comunicação entre um Mestre DP e seus Slaves no S7-300/400, e disponibilizar as falhas da CPU/Sistema no SCADA.
Citei algumas formas de como fazer isso, que você pode ler logo abaixo nesse post. O legal do questionamento do Gabriel é observar que o mercado, cada vez mais procura fazer softwares de qualidade e que forneçam informações consistentes ao usuário, seja ele da manutenção, operação ou engenharia. Parabéns ao Gabriel, e que mais pessoas passem a utilizar essas práticas.
Dentro do S7-300/400 costumamos classificar os erros em dois tipos básicos: Erros de Sistema e Erros de Funcionamento.
- Erros de sistemas são geralmente erros detectados pela própria CPU/sistema e tendem a levar a CPU para o estado STOP, como exemplo erro de acesso a periferia.
- Erros de funcionamento são erros não detectados pela CPU, e geralmente ocasionam instabilidade no processo, como exemplo erros de lógica.
Em ambos os casos o STEP7 provê ferramentas de diagnósticos para identificar tais erros. Estas ferramentas podem ser as tabelas de monitoramento de variáveis (VAT), monitoramento online do programa ou o poderosissímo diagnósticos de hardware .
E quais são as ferramentas que o STEP7 provê para que o próprio programa do usuário detecte estes erros, sejam eles de funcionamento ou de sistema?
A resposta é muito simples, a excessão dos forces (não força vai, tem soluções melhores) o STEP7 permite que o programa detecte tudo o que está acontecendo no sistema, e dessa forma o programa pode tomar uma decisão, como desabilitar uma determinada rotina ou simplesmente mandar uma mensagem para o SCADA/IHM.
Vamos citar alguns exemplos, sendo que não entrarei em muitos detalhes de como implementar, pois o espaço aqui é resumido e tornaria o post um pouco indigesto. Mas como sempre, se perguntar eu respondo. Só não respondo mais nada por e-mail. Suporte Técnico da Siemens é no 11-3833-4040. Brincadeira, respondo sim, mas tem que ser no blog, para ficar disponível para todo mundo.
Eu, particularmente não gosto de usar os OBs.
Bom, OB (organization block) é a maneira como a CPU interage com o seu programa, vale lembra que você nunca chama um OB, é sempre a CPU que decide o momento em que um determinado OB deve ser executado. O principal OB num programa é OB1, onde origina-se a grande maioria do seu programa, pois este é o OB cíclico que é executado após o término do ciclo da CPU.
Dessa forma, assim como existe o OB1 para uma determinada condição, existem outros OBs específicos, como por exemplo para situações de erros detectados pela CPU. Estes OBs geralmente estão entre a faixa do 80 ao 87 para erros assíncronos (ex, falha de um canal analógico) e na faixa do 121 ao 122 para os erros síncronos (ex, leitura de endereço inexistente).
Como todo bloco, o OB usa dados em sua local stack ou área L através de variáveis locais, sendo que no caso dos OBs a CPU vai disponibilizar diversas informações sobre o motivo do OB estar sendo executado, como por exemplo, timestamp do horário de execução do bloco, endereço do módulo que ocasionou a falha, tipo do módulo, tipo da falha e por aí vai. O que o seu programa pode fazer é analisar estes dados e em função dos valores, que são devidamente documentados nos manuais, diagnosticar o tipo da falha num determinado módulo. Aqui você pode estar se perguntando “Vou ter que analisar um monte de variáveis para detectar um erro” e a resposta é sim, vai! Felizmente, você que não é bobo nem nada vai criar um bloquinho que faça isso e você só vai chamar esse bloquinho dentro dos OBs. Nada mais simples.
O motivo de eu não gostar de usar OBs, é que preciso saber o OB que vai ser chamado para uma determinada falha. E também pelo fato do OB ser chamado duas vezes, uma para quando a falha for detectada e outra para quando a falha for sanada.
Um dos maiores prazeres que tenho em programar é ver o SFC51 no STEP7, é o verdadeiro faz tudo. De uma olhada na documentação do STEP7 pra ver o que é possível fazer com ele. Basicamente você pode consultar o status de qualquer módulo com o SFC51. Você pode por exemplo, consultar se um módulo possue alguma falha, pode diagnosticar se o conector de uma placa foi retirado, se um canal analógico de 4..20mA está com quebra de fio, se a CPU está com alguma falha interna/externa ou mesmo se a CPU possue algum sinal forçado (O pessoal de manutenção odeia esse, pois geralmente eu coloco essa condição no SCADA, ai fica logado quando um sinal foi forçado…he he he).
A grande sacada do SFC51, é que ele na realidade consulta o status list da CPU/Módulo e pode informar simplesmente todas as informações disponíveis no módulo. Evidentemente alguns módulos possuem mais informações que outros, portanto consulte a documentação dos seus módulos para maiores informações. O uso do SFC51 também é bem simples, basicamente para cada tipo de consulta ele retorna uma struct, e nessa struct está o resultado do que você consultou. Para maiores informações de uma olhada no www4.ad.siemens.de. Uma vez que você tem o status de um módulo, você pode fazer o que você quiser com ele. Desde bloquear uma lógica, até mesmo mandar uma informação para o SCADA.Existem outros SFC/SFBs para diagnosticar erros e falhas, tipo erros em redes DPs e por ai vai. Como sempre de uma olhada na documentação do STEP7.
AGORA, se você usa o STEP7 em conjunto com o WinCC, eu sugiro que você não recrie a roda. Você pode utilizar o conceito de TIA (Totally Integrated Automation ), onde é possível abrir o Hardware Diagnostic do STEP7 direto do WinCC, e com isso visualizar na apartir do SCADA erros em seus módulos. É possível visualizar até mesmo a lógica do PLC diretamente no SCADA, usando funções com o Ladder Rung Jump ou então visualizar processos sequencias com o Pro-Agent/Sequential Function Chart(SFC) ou S7-Graph.
Ainda no caso do WinCC, existe um controle ActiveX da Siemens, o qual eu nunca usei, que pode ser integrado ao WinCC que irá exibir as mesmas informações disponíveis no Module Information do STEP7.
Bom, resumidamente é isso. Existem muitas outras maneiras de diagnosticar falhas, que variam de sistema para sistema, e estas são as formas que eu realizo os diagnósticos.
Abraços,
E bom uso.
Márcio Roberto
