Sugestão de blog para Rockwell

Amigos,

Muitas pessoas me questionavam sobre sistemas fornecidos pela Rockwell (ControlLogix, RSView, etc.).  A maioria das pessoas sabem que tenho um relacionamento mais estreito com a Siemens, infelizmente não tive contato com sistemas da Rockwell, não por que eu não queria, mas sim por falta de oportunidades.

Recentemente publicaram no orkut um post divulgando um blog, que me parece ser voltado para Rockwell, ou no mínimo mantido por pessoas com experiência em Rockwell e que talvez possam ajudar vocês.

Segue o link.
http://automationcontrolblog.blogspot.com/

Abraços,

Publicado em CLP, PLC, SCADA. 1 Comentário »

Tutoriais de WinCC, Step7 e Outros

Pessoal,

Aqui vai um link para quem sempre me pediu apostilas e tutoriais de WinCC, Step7, Profibus e outros.
O material é baixado diretamente do site do Sitrain, que é a divisão de treinamentos da Siemens e é fornecido em Inglês. Aqui vai o link: https://www.automation.siemens.com/fea/html_76/down_module.htm?HTTPS=REDIR

Abraços,

Márcio Roberto

Publicado em CLP, PLC, SCADA, WinCC. 2 Comentários »

Reencontro

Pessoal,

O ano começa prometendo novos desafios. E para mim, dentre inúmeros desafios, coloquei como desafio manter o blog atualizado durante esse ano. E para tanto vou colocar aqui os inúmeros posts que estão no forno ou que estão previamente formatados ou que ainda não passam de masturbações mentais.

Mas vamos lá, são eles:
- Tutorial de IEC61131-3. Incluindo exemplos, principais diferenças, vantagens e desvantagens e se possível colocar alguma coisa de CFC.
- Tutorial sobre o uso de componentes e bibliotecas (OCX e DLL). Incluindo exemplos de como criar, declarar e reaproveitar componentes. Recentemente fiz uns testes criando componentes COM utilizando o VB2005 e chamando os mesmos dentro do WinCC. Pretendo tomar essa prática padrão daqui pra frente.
- Tutorial sobre o acesso a dados no WinCC. Explicando os conceitos de ADO, o uso de RecordSets e principalmente o Connectivity Pack do WinCC, que pra quem me conhece sabe que é uma das ferramentas que eu mais gosto no WinCC.
- Um How To sobre como abrir blocos travados do Step7 e se possível do WinCC, e ver se ajudo a abolir de uma vez por todas essa praga de travar blocos.
- Finalizar um programa para exportar dados do WinCC para N formatos. Nesse desafio eu estou procurando parceiros.

E se tudo ocorrer bem, começar a discutir algo que eu acho que vai dominar o mercado de automação daqui pra frente. Business Intelligence. Acabei de participar de um workshop que mostra o BI usando o SQL Server 2005 que acompanha o WinCC. Fiquei de queixo com as possibilidades de utilizar algo que no mercado de TI já é o diferencial.

E muito, mas muito mais. O que me falta é tempo.

Publicado em CLP, PLC, SCADA, VB, WinCC. 1 Comentário »

Acesso indexado no Step7

Eu costumo comentar com as pessoas que o divisor de águas entre quem pode afirmar que conhece, e bem o PLC da Siemens e quem sabe o usar o PLC, é exatamente o conhecimento e o uso do tipo ANY. 
Genericamente falando o ANY é um dado muito pretensioso, pois ele pode ser qualquer coisa e apontar para qualquer coisa dentro do PLC. Tradução literal, ANY pode ser qualquer coisa. E ele é. Veja as figuras abaixo. 

Formatação do ANY para variáveis
Formatação do ANY para variáveis na memória.

Formatação do ANY para parâmetros
Formatação do ANY para blocos de dados (parâmetros).

Essas figuras documentam a formatação do dado ANY, que possui em sua estrutura 80 bits. Com essa formatação ele pode simplesmente apontar para qualquer área no PLC. Isso é mais do que ser uma forma de endereçamento variável.
Geralmente, associamos o termo endereçamento variável ou endereçamento indireto ao uso de dados que ora apontam para uma região de memória e ora apontam para outra região. Não é esse o caso, pois o ANY pode inclusive apontar para funções, atuando quase que como um ponteiro para função do C/C++.
Se você precisa somente de um ponteiro que aponte para endereços de memória, você poderia utilizar o tipo POINTER do PLC.  
Veja a figura abaixo. 
Formatação do POINTER
Formatação do Pointer
 

O uso do POINTER e ANY de forma a apontarem para endereços de memória são muito semelhantes, sendo que o POINTER possui em sua estrutura 48 bits, mas por hora me atentarei ao uso do ANY, que é muito mais completo e muito mais mutante. 
Vamos analisar a estrutura completa do ANY.
Primeiramente vamos analisar a estrutura apontando para endereços de variáveis na memória do PLC. 

  1. Byte 0:
    Indica o header do ANY, sendo que no S7 é obrigatório que esse byte possua o valor 10h (B#16#10).
  2. Byte 1:
    Indica o tipo de dados representado pela ANY, podendo ser:

    Código Hexadecimal

    Tipo do Dado Descrição
    B#16#00 NIL Ponteiro Nulo
    B#16#01 BOOL Bits
    B#16#02 BYTE Byte (8 bits)
    B#16#03 CHAR Caracteres (8 bits)
    B#16#04 WORD Palavra (16 bits)
    B#16#05 INT Inteiro (16 bits)
    B#16#06 DWORD Dupla Palavra (32 bits)
    B#16#07 DINT Duplo Inteiro (32 bits)
    B#16#08 REAL Número de Ponto Flutuante (32 bits)
    B#16#09 DATE Data
    B#16#0A TIME_OF_DAY (TOD) Hora do Dia
    B#16#0B TIME Tempo
    B#16#0C S5TIME Tempo tipo S5TIME
    B#16#0E DATE_AND_TIME (DT) Data e Hora (64 bits)
    B#16#13 STRING Texto

  3. Byte 2 e Byte 3 (Word 2):
    Indica o fator de repetição, ou seja, quantos dados esse ANY representa.
  4. Byte 4 e Byte 5 (Word 4):
    Indica o número do DB, caso o ANY esteja representando dados de um DB em específico, ou o valor zero caso não aponte para nenhum DB.
  5. Byte 6:
    Indica o tipo de memória representada pelo ANY, podendo ser:

    Código Hexadecimal

    Área Descrição
    B#16#81 I Área de Entrada
    B#16#82 Q Área de Saída
    B#16#83 M Área de Bit Memory (Flags ou Markers)
    B#16#84 DB Bloco de Dados
    B#16#85 DI Bloco de Dados Instanciados
    B#16#86 L Área Local (L stack)
    B#16#87 V Área de Local Anterior

  6. Byte 7, 8 e 9:
    Nesses bytes está representado o endereço (no padrão Byte.Bit,ou 00000bbbbbbbbbbbbbbbb.xxx, onde b=número do byte e x número do bit). 

Agora vamos analisar a estrutura apontando para parâmetros de blocos na memória do PLC

  1. Byte 0:
    Indica o header do ANY, sendo que no S7 é obrigatório que esse byte possua o valor 10h (B#16#10).
  2. Byte 1:
    Indica o tipo de dados representado pela ANY em questão, podendo ser:

    Código Hexadecimal

    Tipo do Dado Descrição
    B#16#17 BLOCK_FB Número do FB
    B#16#18 BLOCK_FC Número do FC
    B#16#19 BLOCK_DB Número do DB
    B#16#1A BLOCK_SDB Número do SDB
    B#16#1C COUNTER Número do Contador
    B#16#1D TIMER Número do Temporizador

  3. Byte 2 e Byte 3 (Word 2):
    Não relevantes, sendo que o valor dessa Word será sempre 1.        
  4. Byte 4 e Byte 5 (Word 4):
    Não relevante, sendo que o valor dessa Word será sempre 0.
  5. Byte 6:
    Não relevante, sendo que o valor dessa Word será sempre 0.
  6. Byte 8 e 9 (Word 8):
    Indica o número do FB, FC, DB, SDB, Contador ou Temporizador representado pelo ANY. 

Bom, até aqui eu somente fiz uma tradução simples do help do S7. O que por um lado é bom, e por outro é ruim.
O bom é que por mais complexo que pareça, o TIPO ANY é simples de entender, o ruim é que o help básico do S7 não contempla bons exemplos com o ANY. O que pode ser facilmente corrigido, fazendo uma procura no www4.ad.siemens.de. 

Mas façamos o seguinte, outro dia o Williams me perguntou como fazer um FC para reescrever os valores das entradas.
De bate pronto eu comentei com ele que é plenamente possível fazer isso com:
A        I0.0
NOT
=       I0.0
Ou seja, se o código acima (em STL) estiver rodando na primeira linha do OB1, a entrada I0.0 será invertida a cada começo de ciclo de CPU (observe que estou desconsiderando a possibilidade de utilizar-se o particionamento de imagem de periferia do S7) e terá o valor invertido durante este ciclo em qualquer parte do programa.

Para tentar ser mais claro, poderia fazer o seguinte:
A        M4.3
=       I0.0
Se esse código estiver rodando na primeira linha do OB1, a entrada (ou mais correto dizer, o endereço) I0.0 será cópia do valor de M4.3.
Se você não sabia desse fato, fique sabendo agora, e saiba também que todo PLC a principio segue esse comportamento.
Devido a esse comportamento, que eu vivo criando ferramentas de simulação de I/O para tudo quanto é tipo de PLC, assim como queria fazer o Williams. 
Legal, mas aonde entra o ANY nisso tudo? Esse é o ponto meu camarada! O Williams que não é bobo, queria fazer uma função parametrizada que fizesse isso por ele. Logo ele iria entrar com o endereço inicial da entrada que ele iria simular e os valores que deveriam ser forçados. Nada mais prático!
Bom, eu mandei uma sugestão para ele, sendo que poderia criar o seguinte FC:
FUNCTION FC 3 : VOID
TITLE =
FAMILY : Sim
NAME : SimIO
VERSION : 1.0

VAR_INPUT
IoIn : ANY ; //Pointer entrada digital para ser forçada
IN00 : BOOL ; //Valor da entrada 0
IN01 : BOOL ; //Valor da entrada 1
IN02 : BOOL ; //Valor da entrada 2
IN03 : BOOL ; //Valor da entrada 3
IN04 : BOOL ; //Valor da entrada 4
IN05 : BOOL ; //Valor da entrada 5
IN06 : BOOL ; //Valor da entrada 6
IN07 : BOOL ; //Valor da entrada7
END_VAR

VAR_TEMP
DB_NR : WORD ;
END_VAR
BEGIN NETWORK
TITLE =Inicializa apontador
//Ver que esta sendo usado um parametros do tipo ANY
//Deverá ser chamado este bloco passando o primeiro bit da área a ser
//sobreescrita.
//////////////////////////////////////////////////////////////////////////////////////////////
L P##IoIn;
LAR1 ;
//Abre o DB, se estiver sendo utilizado
L W [AR1,P#4.0];
T #DB_NR;
OPN DB [#DB_NR];
//carrega pointeiro de area cruzada. Ver ponteiro any
L D [AR1,P#6.0];
LAR1 ;
//////////////////////////////////////////////////////////////////////////////////////////////
NETWORK
TITLE =Sobreescreve os bits apontados pelo parametro IoIn
//////////////////////////////////////////////////////////////////////////////////////////////
//Entrada 00
A #IN00;
= [AR1,P#0.0];
//Entrada 01
A #IN01;
= [AR1,P#0.1];
//Entrada 02
A #IN02;
= [AR1,P#0.2];
//Entrada 03
A #IN03;
= [AR1,P#0.3];
//Entrada 04
A #IN04;
= [AR1,P#0.4];
//Entrada 05
A #IN05;
= [AR1,P#0.5];
//Entrada 06
A #IN06;
= [AR1,P#0.6];
//Entrada 07
A #IN07;
= [AR1,P#0.7];
//////////////////////////////////////////////////////////////////////////////////////////////
END_FUNCTION

Bom, pra ser sincero, o segredo desse FC está em como o parâmetro ANY é passado para o FC, pois se vocês perceberem, o IoIn é um parâmetro de entrada. Mas se ele é um parâmetro de entrada, como pode estar sendo sobrescrito? No mínimo deveria ser um parâmetro do tipo Input/Output.
Não vamos nos desviar do nosso foco, o ANY. A grande sacada é perceber que o ANY nos informa o tipo e o endereço do dado que está sendo passado, e com isso poderiamos avaliar todas as informações possíveis sobre este dado.
No FC acima, foi executada a instrução
L P#IoIn
LAR1
Mas que raio isso significa?
A instrução L P#IoIn está carregando o ponteiro de 32 bits no acumulador 1 da CPU (ou o ACCU1), ela retorna algum valor do tipo DW#16#8700XXYY, onde:
B#16#87: Corresponde a memória local anterior. E o que significa isso? Resumidamente, significa que o ANY em questão está armazenado na área local (L stack) do bloco que o chamou. Aqui é o segredo da coisa. Pois, com a próxima instrução, LAR1, o conteúdo do ACCU1 será copiado para o registrador de endereço 1 (ou o AR1).
Como o AR1 está apontando exatamente para o ANY que foi passado, basta copiarmos a parte do ponteiro de 32 Bits de área cruzada desse ANY para o AR1, e logo o AR1 irá apontar exatamente para a variável apontanda inicialmente pelo IoIn. Dessa forma:
L D[AR1,P#6.0]
LAR1

Uma vez que você tem o ponteiro de onde sua informação está armazenada, é só acessá-la. Como? Veja isso:
A #IN01
= [AR1,P#0.0]
O que significa esse raio pior ainda?
Calma, vamos analisar.
A instrução A #IN01 não deveria ser problema para quem está querendo aprender o ANY. No caso essa instrução está iniciando uma operação lógica com o bit IN01 (parâmetro de entrada do tipo BOOL, ver declaração do FC).
Ok, mas o que significa =[AR1,P#0.0]? Significa que o resultado da operação lógica (RLO para os íntimos) será atribuída ao endereço apontado por AR1 (que guardou o endereço do parâmetro IoIn, conforme código acima) deslocada de zero bit, conforme o OFFSET P#0.0. Lindo, não?
Se você quisesse escrever no endereço apontado por AR1, porém deslocado de 2 bits você poderia fazer o seguinte:
Opção A:
= [AR1, P#0.2]
Dessa forma você está mudando o deslocamento através do OFFSET da instrução de escrita.
Opção B:
L P#0.2
+AR1
= [AR1,P#0.0]
Sim, amigo. Existe notação de ponteiros no PLC da Siemens. No caso as instruções L P#0.2 +AR1, somou o deslocamento de 2 bits ao endereço apontado por AR1. Evidentemente nesse caso, perdeu-se o endereço apontado por IoIn.

Conclusão:

Percebe-se por este pequeno post, que o uso do ANY é muito mais complexo do que a sua documentação sugere. Até porque fizemos um uso até que simples para ele.
Poderiamos aumentar as possibilidade utilizando dados complexos (maiores que 32 bits) como , array, structs, UDT, date and time e outros, porém tudo parte do principio que o ANY pode apontar para esses dados através de seus 80 bits.
Evidentemente e forçadamente eu tentei evitar o seu uso em lógicas simples, como para intertravamentos ou o uso do ANY onde outros meios fariam a mesma coisa e com uma simplicidade de entendimento e desenvolvimento muito melhor. Logo NÃO SE USA O ANY AONDE NÃO É PRECISO, porém o seu uso pode facilitar e muito certos problemas.
Exemplos aonde o ANY pode ser utilizado:
Leituras e Escritas de records extensos;
Criação de funções com buffers e vetores;
Funções que precisam avaliar o tipo de dado que está sendo passado, e que o mesmo pode mudar ao longo da execução do programa.
Blocos de Comunicação (quase todos os que eu conheço usam o ANY como parâmetro).
Criação de funções que demandem alto processamento de copy, move, set e reset.
Funções que demandem acessos indexados.

No caso de funções que demandem somente acessos indexados simples, eu sugiro antes de usar o ANY o estudo do uso do seguintes acessos indexados:
Ponteiro de 16 Bits com uso de memória (para DBs, temporizadores e contadores). Ex.:
OPN DB[ MW100]
SE[MW100]
CD[MW100];
Ponteiro de 32 Bits com uso de memória (com área interna). Ex.:
L P#0.0
T MD100

L IW[MD100]
Ponteiro de 32 Bits com uso de registrador indireto (com área interna). Ex.:
L P#0.0
LAR1
L IW[AR1,P#0.0]
Ponteiro de 32 Bits com uso de registrador indireto (com área cruzada). Ex.:
L P#I0.0
LAR1
L W[AR1,P#0.0]
Ponteiro de 48 Bits com uso de registrador indireto (com área cruzada).
Este permite o acesso ao número do DB utilizado.
Este ponteiro funciona como o ponteiro de 32 Bits com uso de registrador indireto e com área cruzada. A principal diferença é que ele pode ser declarado como parâmetro em FB e FC. Sua estrutura segue o padrão da figura abaixo.
Formatação do POINTER
Formatação do Pointer

O uso de parâmetros complexos, como o Ponteiro de 48 Bits e o ANY (80 Bits) tem restrições quando utilizados em FB e FC, porém não vou entrar em detalhes, pois o próprio Step7 não deixará você utilizá-los de forma errada, porém faço grandes advertências em relação ao uso dos registradores de endereço, AR1 e AR2.

Cuidados com o uso do AR1 e do AR2:
Cuidado com o uso do AR1 em FCs que chamam blocos que pedem dados complexos (string, array,structure e UDT) como parâmetro. O mesmo vale para FBs que passam esses parâmetros como IN_OUT.
Cuidado com o uso do AR2 dentro de FBs, pois ele é utilizado para acessar os dados do DB Instance, logo dependendo da forma como você alterá-lo, pode impedir o acesso aos dados do DB instance desse FB.

Uma luz no fim do túnel:
Pra quem está dizendo:
Não entendi nada!
Que porcaria esse ANY e esses acessos indexados!
Tô perdido!

Eu dou um conselho. Não entre em pânico!
Felizmente você pode passar a vida toda sem se preocupar em ter que aprender o ANY e seus derivados, pois o seu processo pode ser extremamente simples e não demandar algo do tipo. Ou então você pode precisar de algo do tipo e acabar de vez com os seus problemas programando o PLC com a linguagem SCL (o texto estruturado da IEC61131-3). Veja que facilidade em fazer um acesso indexado sobre um DB indexado sendo que o componente interno desse DB também será acessado de forma indexada:
word_to_db(número_DB).DW[número_componente].
Nada mais simples!
Evidentemente o que está rolando por trás é muito acesso indexado com o ANY e seus derivados. Mas você nem precisaria saber isso!

Publicado em CLP. 9 Comentários »

Quem procura acha, Siemens na faixa!

Pessoal,

Procurando um manual achei duas páginas que sempre me perguntaram se existiam, e eu nunca soube responder.

1. Vários vídeos explicativos do STEP7.
http://support.automation.siemens.com/WW/view/en/21064133

2. Download do STEP7 demo (versão Lite)
http://support.automation.siemens.com/WW/view/en/22764522

Ambos as páginas estão na área de documentação da Siemens. Espero que possa ajudar as pessoas as desmitificar alguns mitos. Gostei muito do vídeo sobre a integração do STEP7 com as IHM/WinCC.

Não me perguntem as limitações do STEP7 Lite, pois não instalei, mas talvez seja mais seguro “brincar” com essa versão do que as versões do Astalavista ou do Emule.

Abraços,

Márcio Roberto

Como você detecta os erros no seu sistema?!

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.

  • Detectando Erros por OBs.

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.

  • Detectando Erros por SFC/SFB.

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

Quanto vale a sua informação? Parte 2 de ∞.

No post anterior dessa série, levantei a questão de como os sistemas de aquisição e armazenamento nos SCADAS são sub-utilizados. Na realidade eles são sub-utilizados, pois estes sistemas são configurados de forma que não geram informações com valor agregado aos seus consumidores.

Neste post, irei relatar um processo onde tentei convencer o cliente a como maximizar a utilização do SCADA, de forma que as informações pudessem ter valor agregado, sem ter que utilizar sistemas complexos na aquisição e armazenamento destas informações.
Neste projeto estava sendo utilizado a seguinte configuração:
WinCC 6.0
Banco de Dados: SQL Server 2000 (Nativo do WinCC)

A idéia básica de meus argumentos era demonstrar como diferentes configurações afetavam diretamente a quantidade de informações armazenadas, bem como os processos de visualização e análise das mesmas.

O cliente em si, é um grande player da área de energia, sendo que está acostumado a utilizar sistemas dedicados de análise de informações, tais como oscilopertubografos e dataloggers, e não via nas informações de curvas de tendências do SCADA grande importância, tanto é, que algumas configurações básicas, a princípio, poderiam atender as suas necessidades.
O grande problema é que a utilização desses sistemas de análises complexos em certos projetos é inviável, devido ao alto custo de aquisição e implementação dos mesmos, e principalmente pelo excesso de informações geradas nesses sistemas, que pode levar ao abandono no uso de tais ferramentas por pessoas com menor nível técnico, no caso, a grande maioria dos operadores. Logo o operador acaba por não utilizar nem as ferramentas do SCADA nem as ferramentas dos oscilopertubografos.

Como o SCADA utilizado era o WinCC, não entrarei em detalhes técnicos das configurações, caso exista um interesse das pessoas que acessam o blog, poderei demonstrar futuramente como fazer tais configurações.

Para demonstrar o efeito prático dessas configurações, cadastrei 3 informações no sistemas de aquisição e armazenamento (Tag Logging), sendo que as informações seriam aquisitadas do mesmo tag no PLC, no caso uma onda senoidal representando variações de tensão do sistema, sendo que o valor desse tag oscilava entre 13300 e 14300, com período de 45s. Cada informação cadastrada no Tag Logging recebe o nome de archive, logo temos os seguintes archives:

- Curva Tensão_Continuos = Aquisição e armazenamento de 1s;
- Curva Tensão_Média = Aquisição de 1s e armazenamento da média de 30 aquisições (intervalos de 30s);
- Curva Tensão_Evento = Aquisição e armazenamento de 1 s, sendo habilitado o armazenamento quando o valor ficava acima de 13700 e sendo desabilitado quando o valor ficava abaixo de 13500.

Quando definimos se uma informação tem valor agregado, devemos levar em consideração a forma como essa informação será consumida. Exemplo, a informação representará uma variação brusca num sistema estável ou a informação representará a variação normal de um sistema instável?
Se a informação representa uma variação brusca num sistema estável, faz sentido plotar um gráfico com longos períodos, de forma a constatar essas variações.
Se a informação representa a variação normal num sistema instável, não faz muito sentido plotar um gráfico com longos períodos, pois é bem provável que a própria variação da informação “polua” visualmente o gráfico e dessa forma, não é possível analisar visualmente o gráfico, reflita um pouco sobre isso.

Para ilustrar bem esse conceito, abaixo está representado o gráfico de tendência de algumas horas, sendo que neste gráfico estão plotadas as 3 informações. Veja o quão poluido está o gráfico.

 Curva de tendência com as 3 informações ao longo de algumas horas

Por esse gráfico, simplesmente não é possível determinar o que aconteceu no processo, logo não seria prático nesse caso, plotar esse gráfico com o período utilizado, independente de qual curva queria se analisar.

Logo, vamos dar um zoom num período qualquer e analisar as 3 curvas ao mesmo tempo.

Curva de tendência com as 3 informações aplicando-se o zoom durante um curto per�odo

Perceba que agora fica mais evidente as variações sobre as informações. Lembrando que as 3 informações apontam para o mesmo tag, o que muda é a forma com as mesmas estão sendo aquisitadas e armazenadas.
Observando-se a curva Tensão_Continuos, é possível observar as variações durante todo o período de aquisição.
Observando-se a curva Tensão_Média, é possível observar que existiram variações em determinados momentos do processo. Evidentemente que toda média, ou tecnicamente falando, todo filtro de média atrasa a variação sobre uma informação, este atraso vai depender de como a média está implementada e a taxa de variação dessa informação. O importante aqui, é observar que foi possível constatar a variação da informação, mesmo com o atraso.

Alguém deve estar se perguntando, mas está faltando uma curva, a curva Tensão_Evento. E a grande sacada dessa configuração esta em avaliar que esta informação só é armazenada quando o valor da informação fica entre 13500 e 13700, logo esta curva esta sendo representada no gráfico, porém como a taxa de aquisição  dessa informação é a mesma da Tensão_Continuos, elas estão sobrepostas, irei provar isso no próximo gráfico, veja você mesmo.

Curva de tendência com as informação de Tensão_Evento aplicando-se o zoom durante um curto per�odo

Se o intuito da configuração do SCADA era registrar quando o valor da informação ficava no período entre 13500 e 13700, essa seria a melhor configuração, pois otimiza o banco de dados, visto que o sistema somente irá armazenar informações no período exato da ocorrência e principalmente facilita e muito a visualização e análise dessa ocorrência por qualquer pessoa.

Só por curiosidade, com a configuração proposta o espaço necessário à aquisição de dados desse cliente despencou de 17GBytes (Não se engane, seriam 17GBytes por ano) para 1.4 GBytes, e olha que nem foram implementadas todas as sugestões que nós propomos.

Sim! Se você está achando que seria só isso que o sistema tem a oferecer, eu te digo, esqueça! Tem muito mais, seria possível cadastrar um grupo com várias informações, e com a simples mudança de um tag todos os valores desse grupo seriam salvos, ou seja, pode-se utilizar o SCADA como um Oscilopertubografo. Será que estou exagerando? Não, não estou, pois o WinCC aceita informações, qualquer que seja ela, com resolução de 1ms, logo, eventos, curvas de tendências e qualquer outra informação nas tabelas do WinCC, poderia auxiliar no processo de um trip/ocorrência. E para tanto não é necessária nenhuma licença adicional, nenhum software adicional. Estou falando do core básico do WinCC.

É possível até mesmo o WinCC receber estes dados prontinhos do CLP, na forma de buffer, restringindo o envio do buffer à 64kB por send!!!. Tá bom ou quer mais? Quer mais? É possível que o CLP leia o buffer de um datalogger, de um oscilopertubográfo e disponibilize no supervisório, tudo isso com resolução de 1ms real e não por polling. O que você prefere, polling ou change of state. Eu sempre fico com change of state, como nós programadores, gostamos de dizer, é o sistema mais elegante. Mais elegante e eficiente.

Bom, eu poderia parar por aqui, mas com eu sempre me empolgo quando o assunto é analise de informação ou tecnologia de informação, eu vou cutucar mais um pouquinho. E se você quisesse disponibilizar essas informações na web, ou mesmo verticalizar o acesso à essas informações, ou em último caso, se você quisesse simplesmente disponibilizar estas informações numa planilha Excel.

 Bom, agora eu paro por aqui, até por que ainda estou fazendo meus testes com alguns  Web Services, por outro lado existem algumas formas de retirar as informações do banco de dados que alguns já usam e outros não conhecem, porém tudo isso fica para um próximo post.

 É importante frisar que as informações apresentadas nas curvas de tendência não possuem nenhum tratamento gráfico, como filtros gráficos, ou consultas especiais em SQL, são dados puros, direto do banco. Se eu fosse apresentar as formas como podem ser realizadas estas funções no WinCC, além de escrever um post muito grande, sendo que este já é um exagero, os usuários de outros sistemas iam ficar chateados de ter que usar SCADAS somente como gerenciadores de telinhas. Um pouco de diversão não faz mal à ninguém.

Abraços,

Márcio Roberto

Publicado em CLP, PLC, SCADA, WinCC. 2 Comentários »

Quanto vale a sua informação? Parte 1 de ∞.

Senhores, lanço aqui um desafio, e peço que definam agora um peso para aquele sinal (booleano ou inteiro) que é gerado no seu processo e é disponibilizado na sua IHM, seja ela qual for. Peço também, que compare ao final deste post se o seu sinal realmente tinha o peso que você imaginava.

De cara, por que ainda chamamos um sinal de processo apenas de sinal, por que não utilizamos um conceito mais atual, algo como informação. Um sinal quase sempre é associado a uma lógica, enquanto uma informação talvez encaixe-se melhor nos conceitos de fluxo e está imerso num contexto. Dentro deste contexto encaixam-se as etapas de lógica, bem como as etapas de visualização e análise dessa informação.

Há alguns meses eu venho conversando com outras pessoas do meio industrial, e discutindo como são implementadas as rotinas de aquisição, visualização e análise das informações em seus projetos.
Quase sempre, 90% dos casos, usa-se sempre a aquisição por polling, sendo os dados classificados em prioritários e não prioritários, onde os dados prioritários possuem uma frequência de polling maior e os não prioritários possuem uma frequência de polling menor. Com isso, praticamente as necessidades do projeto tendem a ser atendidas. Será?

Não é raro encontrar aplicações que aquisitam informações, por exemplo, com intervalos de 500ms, e disponibilizam as mesmas em gráficos de tendência.
Nesses casos, para não sobrecarregar o sistema, o gráfico de tendência é configurado para exibir os últimos 5 minutos, o que matematicamente representaria 600 registros no banco de dados. Não vou entrar no mérito se estes registros serão compactados ou não no servidor de banco de dados.
Caso o usuário precise de uma informação histórica, que foi registrada no dia anterior, e o usuário não sabe o horário exato dessa ocorrência, é comum o usuário solicitar as últimas 24 horas de dados no gráfico de tendência, o que representa 172800 registros.
Se estiverem associadas nesta curva de tendência mais 3 informações, serão aquisitados do banco de dados 518400 registros.
O tempo necessário para aquisitar estes 518400 registros vai depender de como os mesmos estão sendo armazenados, ou o termo técnico mais correto, persistidos.
Se estiver sendo usado um servidor de banco de dados SGBD, com index nas tabelas, cache em memória RAM e otimização de SQL o tempo necessário será muito, mas muito menor que uma busca pura e simples a um arquivo TXT ou XML, porém será necessário um tempo para realizar esta consulta.

Muitas pessoas podem estar afirmando que neste caso, uma boa máquina servidora, talvez um servidor dedicado somente às informações históricas utilizando um SGBD parrudo (MS-SQL, ORACLE, POSTGREE ou mesmo o MY-SQL) poderia resolver este problema, diminuindo o tempo necessário à consulta no banco de dados. E a resposta é, provavelmente sim.
E se ao invés de apenas um usuário, o acesso sobre estas informações fosse realizado concorrentemente por 5, 10 usuários? Se fossem 10 usuários, seriam aquisitados 1728000 registros, logo, se incrementarmos a memória RAM do servidor, implementarmos um cache mais esperto e em último caso aumentarmos o poder de processamento do servidor, com dois ou mais processadores, esta necessidade não seria um fator complicante em nossos projetos, há não ser que caímos na lei de Moore e ajudariamos a engordar a fatura de empresas como Intel, Oracle e Fujitsu.

Talvez o ponto a ser analisado seja outro.
Você precisa dessa informação na sua IHM com intervalos de aquisição de 500ms?
Se você ainda precisa dessa informação com esta taxa de aquisição, será que ela precisa ser continuamente aquisitada e armazenada?
Será que se ela fosse aquisitada somente quando necessário já não atenderia as necessidades do seu projeto?

Como disse, a situação descrita acima não é fictícia, ela é real. Exemplificando, podemos considerar algumas grandezas elétricas, tais como tensão, corrente e potência. É comum que nossos clientes solicitem que essas grandezas sejam aquisitadas com uma frequência que permita registrar algumas perturbações leves em sua rede. Observe, que usei o termo leve no sentido de uma pequena variação, como nos momentos que uma determinada carga é ligada, e acaba por provocar variações nas grandezas citadas. Evidentemente, se queremos uma oscilografia real, com formas de ondas, detecção de surtos e sequenciamento de eventos, uma aquisição de dados por polling de 500ms seria totalmente inviável. Nestes casos, fala-se de interlavos menores a 1ms, e nesse ponto, somente relés de proteção, osciloperturbografos e poucos SCADAs/PLCs conseguiriam atender as necessidades.
Voltando no caso de nosso cliente, que só quer saber e registrar que algumas mudanças em seu sistema ocorreram, é bem provável que o SCADA fique aquisitando essas informações durante 24 horas, 7 dias por semana e 365 dias no ano, para simplesmente registrar informações que só serão úteis em 10 ou 20% dos casos, os outros 80% das informações serão consideradas puro lixo.
Lixo este, que só vai encarecer o custo de manuteção do seu sistema, que vai sobrecarregar o acesso às informações realmente importantes, e principalmente, que pode aumentar suas previsões durante a fase de proposta, e fazer com que o valor de sua proposta fique muito, mas muito superior ao do seu concorrente.

Na contra-mão dos nossos pensamentos, estão os nossos concorrentes. Eles não se preocuparam com essas peculiaridades, pois é bem provável que eles vão “desconsiderar” os fatos acima, e simplemente configurem o SCADA para aquisitar as informações em frequências menores. Com isso, toda a infra-estrutura necessária será menor, inclusive os tempos para aquisitar as informações no banco de dados. Alías, será que eles vão usar um banco de dados, ou vão gravar as informações um arquivo texto?
E o cliente, nisso tudo? O cliente, meus amigos, só vai descobrir isso quando precisar das informações no SCADA, e ai pode ser tarde demais.

Por isso, agora eu peço pra vocês analisarem. Aquela sua informação de processo, ainda tem o mesmo peso, ainda tem a mesma importância, ou até o mesmo, o mesmo custo-benefício que você definiu ao iniciar a leitura desse texto? Reflita sobre isso.

Nos próximos posts, eu vou citar alguns exemplos de como contornar esses pequenos inconvenientes, e quem sabe tentar demonstar por que alguns supervisórios servem para somente criar telinhas, e outros, além do fazer o trivial de qualquer sistema SCADA, ainda permitem criar sistemas de informações complexos e realmente úteis. Fica ao gosto do freguês.

Bom feriado a todos.

Publicado em CLP, PLC, SCADA, WinCC. 1 Comentário »

Horário de verão, o meu pior pesadelo.

Os estados das regiões Sul, Sudeste e Centro-Oeste, além do Distrito Federal, adiantaram os relógios em uma hora desde a meia-noite do sábado (04/11). É o início do horário de verão. Ficam de fora as regiões Norte e Nordeste. Isso porque estudos já comprovaram que a economia de energia nessas regiões é insignificante. O retorno do horário normal será apenas em 2007, no dia 25 de fevereiro.

Pois bem, esquecendo os aspectos econômicos e sociais, o que sobra para nós, desenvolvedores e mantenedores de sistemas que possuem base de dados?
Na minha opnião, somente dor de cabeça. Dor de cabeça, pois nossos clientes vão nos ligar correndo para adiantar os relógios de todos os sistemas (PLC, SCADA, IHM..) da planta.
Se a planta ainda não usa uma ferramentas de sincronização de tempo, como servidores NTP, GPS e outros, o trabalho pode ser bem árduo. Caso a planta tenha algum destes sistemas instalados, é bem provável que você possa configurar os dias para a troca do summertime/wintertime. Dessa forma você pode ficar tranquilo, curtindo as happy hours que agora tem mais uma hora de Sol.

Analisando tecnicamente o que está acontecendo nas bases de dados, podemos verificar que na mudança para o horário de verão, a sua base de dados terá um gap (salto/buraco) de 1 hora, o que não é problema, visto que sistemas de supervisão mais inteligentes podem indicar a existência do gap.
O grande problema é quando voltamos para o horário normal, ou seja quando atrasamos/voltamos o relógio em 1 hora. Nesse momento, teremos um overlap (sobreposição/reescrita) dos dados de 1 hora, o que é um problema, e somente alguns sistemas de supervisão indicam a existência do overlap. E todos os dados que foram armezenados à 1 hora, podem ser sobrescritos ou mesmo perdidos, dependendo do seu sistema. E se estes dados perdidos representavam informações importantes, como uma oscilografia, os dados de produção ou um log de eventos?

Em todo caso, eu utilizo e compartilho do mesmo pensamento de muitos DBAs(Database Administrators). “Nunca altere o horário da base de dados de um servidor”. Inclusive muitas concessionárias de energia utilizam esse conceito, visto que para efeito de tarifação o horário de ponta/fora de ponta é alterado, mas nenhum medidor de energia tem o seu relógio atualizado.

Reflitam sobre isso. No final quem deve decidir o que fazer é o cliente, mas ele pode ser melhor acessorado.

Abraços,

Márcio Roberto

10 motivos pra escolher Siemens

Eu aprendei a não entrar em certas discussões. Times, Política, Religião e principalmente fornecedores de automação, principalmente se for do tipo quem é melhor que quem.

A última vez que participei de uma discussão como essa, foi mais para me divertir, mas como a coisa tomou outro rumo expus os meus pensamentos, tudo começou assim:


Alguém já viu o CLP da Saia Burges ser programado com o STEP7? Crise de identidade? Talvez, mas por parte de quem? E pq será que a linguagem do SucoSoft da Moeller tem tantas funções semelhantes ao do STEP7.Não sei, to começando a achar que o mercado de programadores na Alemanha é meio restrito, isso se não for tudo farinha da mesma Índia, Paquistão…Mas vamos tentar.
1.Confiabilidade;
2.Versatilidade;
3.Liberdade;
4.Performance;
5.Possibilidade de ser tornar um sistema híbrido;
6.Conectividade;
7.Expansibilidade;
8.Real Redundância e HotStand-By;
9.Por ser alemão e não americano;
10.Incomodar a Rockwell.
11.Pq vc é programador de verdade e gosta de ser o senhor do seu destino. Me senti o Morpheus agora
Tá as últimas 3 eu forcei a barra.Sem criar polêmicas.Abraços,Márcio Roberto


Bom, não precisa nem dizer que criou polêmica, o que é bom. Acontece que foi exaltado as “vantagens” de um fornecedor nacional em relação a um fornecedor mundial. Tire as suas próprias conclusões, aqui vão as minhas:Respondendo de forma genérica algumas colocações.

1. O Brasil, assim como qualquer outro país pode participar sim do desenvolvimento de qualquer produto, mesmo estado o staff de desenvolvimento em outros países. Existem diversos produtos que foram desenvolvidos em conjunto com as matrizes. O que acontece, é que eu já vi filiais brasileiras quebrarem a cara, reclamando que precisavam de desenvolvimento de produtos que atendam o mercado interno, e a matriz trucar, bancando o desenvolvimento e no final das contas, não sair nada, ou sair a mesma coisa que seria feita fora.

2. Pode ser que eu não tenha participado efetivamente do desenvolvimento de produtos da Siemens, mas já relatei alguns Bugs no WinCC, que foram corrigidos em Service Packs, com certeza outras pessoas também encontram essas falhas, agora o que muda é a posição do desenvolvedor. Tentar corrigir o problema com soluções caseiras, ou relatar o problema e assim participar do desenvolvimento e melhoria do produto. Na Netdel, nos desenvolvemos diversos módulos para a área de energia, principalmente com Siemens, e nós já vimos alguns destes módulos serem reutilizados em outras empresas.

3. Faço minhas as palavras de um integrador do interior de SP, que com muita propriedade, afirma que seus clientes estão procurando mais soluções baseadas em Siemens e outras ditas “caras” ou “inviáveis” em outras épocas, pois com a queda do dolar, a briga por competitividade, as empresas vêem estes investimentos como a solução para a sua subexistência e se manterem competitivas. Logo a balaça do custo-benefício tende a se tornar mais equilibrada. Tanto é que empresas nacionais estão sendo forçadas a implementar novas funcionalidades e melhorias em seus produtos. Posso estar dizendo besteira, mas a Atos implementando a 61131-3 nos seus CLPs, quer brigar por um mercado que não é dela, ou manter um mercado que pode estar sendo invadido por empresas de fora?

4. Em relação aos manuais em outros idiomas, apesar de não ter inglês fluente, não vejo problemas nisso. Como se explica o fato da Índia ser umas das maiores potências em software, e eles não falam inglês. Mercado Globalizado, ame-o ou deixe-o.

5. Desculpe, mas por força do hábito, todas as vezes que eu preciso de suporte da Siemens mando e-mail pra Alemanha, e em 5 horas no máximo, devido ao fuso, eles respodem a minha solicitação, e quase sempre resolvem de primeira. Sendo que as dúvidas mais rotineiras, a Siemens Brasil mantém o mesmo padrão de atendimento.

6. Todos são iguais perante a justiça e olhe lá. Comparar técnicamente CLPs de grande porte importados (independente de fabricante) com os CLPs nacionais é um absurdo, não existem comparações. E mesmo entre CLP importados a linhagem européia é diferente da linhagem americana.

7. Custo, no meu ver, que é bastante limitado por trabalhar com poucos sistemas restritos na área de energia, está deixando de ser o diferencial na hora da aquisição de novos sistemas.


Pode ter certeza, o fórum ainda continua em aberto…