domingo, 30 de outubro de 2011

Migrando drivers antigos para drivers do IOKit - Elipse

Já escrevi aqui há algum tempo sobre o modelo de comunicação dos softwares da Elipse: o E3 e o Scada. 

E um problema bastante comum hoje é como migrar de versões antidas de drivers Elipse para as versões mais novas, programadas no IOKit. Os passos são comuns aos dois softwares e o que importa, antes de começar o processo, é tomar alguns cuidados que facilitarão a migração. 

Entre esses cuidados estão:
1 - Ter em mãos o manual de usuário do driver antigo e do driver no IOKit. Esse passo é importante pois na maioria dos casos os parâmetros N1 a N4 são atualizados na migração do driver. E como instalações antigas de supervisórios raramente são documentadas adequadamente, será preciso traduzir as informações do driver antigo para extrair os endereços de memória acessadas pelo projeto, antes de codificar esses endereços novamente para o padrão do driver IOKit;

2 - Por segurança, se os parâmetros N1 a N4 são diferentes, faça "em papel" a tradução dos códigos antigos para endereços de CLP e depois do endereço de CLP para os novos N1 a N4;

3 - Um problema comum é que os drivers antigos podiam acessar vários equipamentos ou várias redes IP simultaneamente, bastando para isso cadastrar diferentes redes para serem acessadas. Com o IOKit isso não é mais possível: é possível acessar vários equipamentos desde que estejam em uma mesma rede IP. Dessa forma, é necessário conferir em cada tag qual o IP acessado por cada tag, de modo que seja possível criar novos drivers com os seus tags cadastrados nos endereços corretos; 

4 - Como novos tags terão de ser criados na aplicação (no Elipse Scada isso não será necessário), é importante que as informações de escala e tempo de scan sejam copiadas corretamente;

5 - Uma vez criada a lista de tags, com seus endereços, escalas e tempos de varredura, é hora de criar os drivers que serão configurados no aplicativo. Esse passo será diferente no E3 e no Scada, mas o objetivo em ambos é ter um driver para cada endereço IP que será acessado. Para maiores informações, verifique os artigos sobre modelo de comunicação no E3 e no Scada;

6 - Crie os tags de cada um dos drivers utilizando o novo padrão de endereços que foi criado no item 3. A partir daí, faça o teste de leitura e escrita dos tags no ambiente de desenvolvimento. Com isso você conseguirá garantir que cada um dos drivers funciona adequadamente. Nessa altura, se tudo estiver correto os drivers estarão funcionando e todos os tags estarão configurados corretamente e com leitura/escrita funcionando corretamente;

7 - Um detalhe importante e que foge ao escopo estritamente técnico: verifique quantos drivers estão habilitados a funcionar na sua licença de runtime. Isso por que, como já discutidos nos artigos sobre modelo de comunicação, a Elipse cobra separadamente pelas licenças de driver. Para isso, você precisará do arquivo .hsp que identifica a licença Elipse. Envie esse driver para o setor comercial da Elipse mais próxima e aproveite para informar qual o número de drivers da sua aplicação (todos os drivers, não importa o tipo ou versões de drivers); 

8 - Se a licença Elipse não permitir que se execute todos os drivers simultaneamente, apenas os primeiros drivers da lista serão habilitadas e os tags serão lidos. Negocie um upgrade das licenças com o comercial da Elipse e execute o proesso de atualização da licença;

9 - Depois de todas essas etapas, verifique se o projeto será executado adequadamente e os tags serão lidos de modo correto. Se concluir que sim, problemas clássicos como travamentos de tela, erros de leitura e outros estarão solucionados. 

Se em algum momento dessas verificações você tiver problemas ou dificuldades, entre em contato com o suporte técnico que poderá te ajudar gratuitamente. Se não for no primeiro contato, não se preocupe: alguém entenderá seu problema e o ajudará a encontrar a solução. 

Links:

segunda-feira, 17 de outubro de 2011

É sério: não desistam do blog!

Apesar de distante e de já ter me explicado por aqui, volto a selar um compromisso de continuar a escrever no blog, com uma periodicidade minimamente praticável. 
Não serão 4 artigos por mês, mas pelo menos um post por semana com assuntos rápidos e um artigo completo por mês. 

Entre os assuntos pendentes de um artigo completo, estão:
- Modelo de Comunicação do Indusoft;
- Modelo de Comunicação do Pulse;
- Introdução ao WebFactory e ao Silverlight: nisso estou começando, mas o conjunto das duas ferramentas parece muito promissor;
- Aplicação de Automação ao segmento Têxtil; 
- Controle de Produção com Pulse;
- Programação em PLCs Step7-300
- E muitos outros.
Entre os posts rápidos, vou começar a colocar alguns assuntos das edições Nacional e Internacional da InTech, revista editada pela ISA. E também comentar algumas das vantagens de ser um associado da ISA, com um custo ínfimo e uma rede de contatos poderosa para iniciantes ou para profissionais experientes. 

Compromisso reiterado, vamos lá! É hora de trabalhar.

terça-feira, 6 de setembro de 2011

Melhores do mês e um novo começo

Pessoal, um pouco atrasado, mas saiu a lista do mês de Agosto/2011. Mais uma vez, a lista variou e novos artigos surgiram na lista, embora não tenha sido produzido um artigo novo no mês.

Como todo mês, a lista com o link para os mais lidos:
1 - Modelo de Comunicação Elipse Scada;

2 - Softwares Supervisórios - Todos são ótimos!!! Mas...;

3 - Programação de PLCs Mitsubishi;

4 - Download de drivers Elipse;

5 - Comunicação com S7-300 usando PC-Adapter na USB;

Novos tempos!
O blogueiro está ingressando num novo mundo: o da programação em Microsoft Blend para criação de sistemas supervisórios. Por esse motivo, está passando por um treinamento na Dinamarca, para aplicação dos conhecimentos a um poderoso sistema de controle de bagagens em aeroportos. 

A nova ferramenta vem ao encontro da reportagem da última revista InTech nacional, que é a de supervisórios integrados aos sistemas de TI das empresas, ao mesmo tempo que traz a facilidade de programação de softwares como Visual Studio e Expression Blend para o mundo da automação.

Vamos colher os resultados desse treinamento!

sexta-feira, 19 de agosto de 2011

Novo Artigo na Revista Mecatrônica Atual

Saiu agora na Mecatrônica Atual um artigo meu com 7 páginas sobre a instalação e uso do MS SQL Server 2005 em conjunto com o Elipse E3.

Do básico (onde baixar o software) até a conexão com o Elipse E3, está tudo descrito com passos e imagens! Confira nas bancas e depois comente aqui no blog!

Boa leitura!

segunda-feira, 1 de agosto de 2011

Mais lidos de Julho/2011

Mais um mês correu rápido! E o movimento do blog continua a toda! Nesse mês de Julho, os posts mais lidos foram, na sequência: 

- Modelo de Comunicação do Elipse Scada;
- Comunicação com Impressora Zebra;
- Modelo de Comunicação do Elipse E3;
- Roteiro de Treinamento do Elipse E3;
- Roteiros de Treinamento do Indusoft.

Isso aí! E durante esse mês que se inicia, virão novos artigos para quem está aprendendo ou procura soluções para uso em supervisórios. 
Até as próximas!

quarta-feira, 20 de julho de 2011

Comunicação com Impressora Zebra

Nesse artigo será apresentado um roteiro para comunicar o software Elipse E3 com uma impressora Zebra, que deve ser acionada através de comandos na linguagem ZPLII, bem simples, por sinal.

Ferramentas para a Comunicação

- Ao adquirir a impressora, ela terá um disco de instalação do driver e utilitários. Mantenha esse disco;
- O software Zebra Setup Utilities pode ser baixado pelo site da impressora (www.zebra.com.br);
- Um cabo USB para impressoras;
- Um cabo serial NULL-modem, como o mostrado na figura abaixo;
- Elipse E3 com o driver Zebra instalado.

Cabo para Comunicação com Impressora Zebra





Parametrizando a impressora

           É necessário ligar e instalar o ribbon da impressora, quando for o caso. Essa não é a tarefa mais fácil de fazer, mas com o manual, dá conta de se resolver depois de um tempo apanhando (experiência própria). Siga o roteiro de instalação e comece a se acostumar: essa impressora não vai imprimir A4...

          O primeiro software a ser instalado é o Zebra Setup Utilities. Com ele é possível parametrizar a impressora para ser acionada via USB ou serial. Como esse software e o Zebra Design servirão para ajustar a impressora mesmo depois de iniciado o projeto no E3, instale a impressora para ser acionada via USB. 

          O próximo software a ser instalado é o Zebra Designer. Com ele os drivers da impressora será possível manusear arquivos no formato da impressora, realizar uploads de imagens, testar o código ZPLII que você acha que sua impressora executará de primeira, etc). No CD, existem duas versões: ZD e ZD Pro, que não deve ser instalada: a versão Zebra Designer é suficiente e gratuita. 

           O próximo passo é instalar o Elipse E3 e o driver. Nesse ponto o driver da Elipse e seu manual ajudam a começar o programa: a documentação do driver é acima da média e pode te ajudar nos primeiros passos. Os incrementos podem ser testados diretamente com o Zebra Designer, que ao final dos testes, dará um código ZPLII funcional no E3.


           O código abaixo mostra uma etiqueta construída na linguagem ZPLII e consta do manual do Elipse, já com a inclusão de alguns tags de interesse (data, hora, etc). 
^XA
// ^XA – Indica o início da formatação de etiqueta
^LH&0,&1
// ^LH – Ajusta a posição inicial da etiqueta para &0 pontos para a direita e &1 pontos partindo
// borda superior da etiqueta (&0 e &1 são variáveis definidas no Elipse no momento da impressão)
^FO&2,&3^AD^FDZEBRA^FS
// ^FO&2,&3 – Ajusta a origem do campo para &2 pontos para a direita e &3 pontos abaixo partindo
// da posição inicial (definida pela instrução ^LH) (&2 e &3 são variáveis)
// ^AD – Seleciona a fonte “D”
// ^FD – Início dos dados do campo
// ZEBRA – Os dados propriamente ditos (palavra “ZEBRA”)
// ^FS – Fim dos dados do campo
^FO&4,&5^B3^FDAAA001^FS
// ^FO&4,&5 – Ajusta a origem do campo para &4 pontos para a direita e &5 pontos abaixo partindo
// da posição inicial (definida pela instrução ^LH) (&4 e &5 são variáveis)
// ^B3 – Seleciona a fonte de código de barras “Code 39”
// ^FD – Início dos dados do campo para o código de barras
// AAA001 – Dados propriamente ditos (“AAA001”)
// ^FS – Fim dos dados do campo
^XZ
// ^XZ – Indica o fim da formatação de etiqueta
          Um exemplo de etiqueta que foi construído por mim por solicitação de um cliente é mostrada na figura abaixo. 

Etiqueta criada com ZPLII e impressa no E3
Resumindo...
          Trabalhar com impressão Zebra não é tão simples quanto outras impressoras comuns. Para acioná-las corretamente:
- Instale os softwares necessários;
- Instale a impressora para ser configurada e parametrizada pela porta USB;
- Deixe a porta serial da impressora livre, pois o supervisório só comunica pela serial ou Ethernet (poucas Zebras tem essa opção);
- Crie algumas etiquetas de exemplo, simples, para entender a sintaxe dos comandos;
- Use o Zebra Designer a seu favor. Ele consegue testar antes o que você vai usar no supervisório;
- Teste o driver do supervisório pela porta serial o quanto antes no projeto, mesmo que a etiqueta não esteja pronta;
- Resista à idéia de que qualquer cabo serial serve. Ambiente de escritório é legal para usar aquele cabinho que está por ali, mas na fábrica um cabo completo pode fazer diferença;
- Prepare-se para cuspir etiquetas enquanto desenvolve o projeto. Consiga um ribbon novo e um ou dois rolos de etiqueta para serem testados;
- Certifique-se quanto aos modelos de códigos de barras que você usará. Isso é fundamental para encontrar a etiqueta que servirá ao seu cliente;

E algumas boas notícias...
- Você não precisa exatamente do Elipse E3 para imprimir etiquetas. O Elipse Scada pode utilizar o mesmo driver (e é mais barato);
- Você não precisa de um driver Zebra para que seu supervisório imprima etiquetas. Se houver um driver ASCII decente, você já vai conseguir imprimir nelas;
- Melhor ainda: se seu CLP ou IHM tem uma porta serial sobrando, é possível programá-los para cuspir comandos por essa serial e imprimir etiquetas sem um supervisório. Basta usar o Zebra Designer e depois migrar o código para o CLP ou IHM. 

Espero que esse artigo o ajude quando se deparar com uma impressora estranha, que é tão padrão de mercado que sua marca é sinônimo do produto. Quase como Bombril, Gillette, SBP, Coca-Cola e outros.

Links interessantes
Impressora Zebra - www.zebra.com.br
Elipse Software - www.elipse.com.br
Download de Drivers Elipse - Post aqui

terça-feira, 12 de julho de 2011

Software para programação PLCs Panasonic

A ferramenta para programação de PLCs Panasonic se encontra nesse link. O manual de programação, aqui.

A Panasonic é representada no Brasil pela Metaltex, que disponibiliza no seu site informações e download sobre esses PLCs. A licença para execução do software também é distribuída pela Metaltex.

A versão exposta aqui não é a versão mais atual, mas dá para realizar manutenções em PLCs com software já instalado, tranquilamente. E em caso de necessidade, sempre é fácil falar com o pessoal de engenharia de aplicação da Metaltex. 

Por enquanto, boa diversão!

quinta-feira, 7 de julho de 2011

Programação de CLPs Mitsubishi

Na nossa série que trata de ferramentas para PLCs, é a vez dos PLCs da Mitsubishi, que são comercializados em São Paulo pela CIM Automação. Como já discutido anteriormente, não tenho cracks ou licenças, apenas as mídias para instalação. 

No caso do Melsec, que programa os PLCs da Mitsubishi, o programa está na versão 8 e existem algumas extensões disponíveis e a que está no link é o upgrade para 8.45. O upgrade deve ser instalado depois de instalado o ambiente Melsec e de instalado o software na versão 8.

Ok, eu nunca havia visto um PLC da Mitsubishi até trabalhar com eles. Mas sendo assim, o melhor a fazer é saber onde procurar. E se precisar, é só fazer bom proveito dos links abaixo!


http://www.4shared.com/file/wxEB4-iK/GX_Developer_Update_to_v8_45.html
http://www.4shared.com/file/k9jr9ywf/GX_Developer_8.html

Enjoy!

segunda-feira, 4 de julho de 2011

Software PL7

Mais uma ferramenta útil para quem precisa programar PLCs e de uma hora para outra, não tem o software.
Segue nesse link o arquivo de instalação do PL7 V4.4, para PLCs Schneider de diversas famílias.

O software está completo, mas não dispõe de licença. A idéia do blog não é promover pirataria, por isso só divulgamos os arquivos de instalação e não os cracks para os softwares que disponibilizamos.

Aproveite bem!

sexta-feira, 1 de julho de 2011

Próximos posts!

Tivemos mais um mês com crescimento de visitação ao site em Junho! Isso é bem bacana, pois o crescimento tem sido grande desde o início do ano e os artigos novos estão sempre trazendo novos leitores.

Assim, durante o mês de Julho, devo trabalhar nos seguintes posts:
- Ferramenta para programação de PLCs Panasonic;

- Ferramenta para programação de PLCs Mitsubishi;

- Ferramenta para programação de PLCs e IHMs Unitronics/Dakol;

E o mais importante, talvez: um post sobre o Modelo de Comunicação do Indusoft, para continuar com a série Modelos de Comunicação, que está dando um ibope muito bom!

Isso aí, pessoal! Um bom mês de trabalho a todos!

quinta-feira, 30 de junho de 2011

Mais lidos de Junho-2011

Fim de mês chegando e segue a lista dos posts mais lidos! Vou tentar fazer isso mensalmente, para mostrar como anda a visitação do site e ver se os assuntos variam muito mês a mês.

Modelo de Comunicação - Elipse Scada: disparado na dianteira;

Modelo de Comunicação Elipse E3: ainda falando sobre Elipse e comunicação, ajuda também a aumentar a leitura sobre o Scada, que está mais completa que a do E3;

- Comunicação com Siemens S7-300 usando PC-Adapter na USB: software e nome do módulo USB usado para comunicação em rede MPI via USB;

- Softwares supervisórios - todos são ótimos!!! Mas...: campeão absoluto de audiência do blog, dá uma visão de como os fabricantes nos apresentam seus produtos;

- Download de Drivers Elipse - driver mesmo, não tem. Mas mostra como fazer para conseguí-los no site da Elipse.

Sim, senhores, esses são os campeões do mês de Junho/2011. Aproveitem e deixem seus comentários!

quarta-feira, 22 de junho de 2011

Blogs a serem lidos

Falta do que fazer nesse feriado que Deus lhe deu?  Segue lista com três blogs e um fórum para se antenar:

Automação BR (Bonito nome, por sinal!)
Engenheirando 
Denis Leite

E ainda tem o fórum do Automatoes, que está iniciando: automatoes.forumeiros.com

Alguns mais atualizados que outros, mas todos com informações úteis. Divirta-se!

segunda-feira, 20 de junho de 2011

Utilitário de Calibração do módulo ADAM 5000-485

A Advantech é conhecida no Brasil mais pelos módulos ADAM que por qualquer outro produto. Os "módulos azuis" têm funções as mais variadas, como conversores de serial, serial/ethernet, módulos de I/O de diferentes tipos, e por aí vai. A concorrência (ICPCon, por exemplo) tem módulos semelhantes, mas o mais comum de se encontrar são mesmo os módulos da Advantech. 

Feita a apresentação assunto, é bom saber que o módulo ADAM 5000/485 é um super-módulo, com cara de CLP, mas que só faz aquisição dos dados e ajuste de saídas (sem funções de CLP ou lógicas). Uma base suporta múltiplos tipos de IO e gerencia a comunicação entre esses IOs e um supervisório, como mostrado abaixo.
Advantech ADAM 5000/485

O software e manual para parametrizar e calibrar os módulos RTD que podem ser instalados no ADAM 5000 estão disponíveis nos links abaixo. Com esse software é possível se conectar à base, parametrizá-la e calibrar cada um dos seus módulos. 





O procedimento para calibração vou tentar postar num futuro próximo, para completar a informação. Por enquanto, guarde esse link, pois pode haver um ADAM 5000 escondido em algum painel que você terá que abrir. 

terça-feira, 14 de junho de 2011

Ferramenta essencial - Step 7 completo

Segue link para download do software Step7 Professional 2006 da Siemens. O link é para o arquivo de instalação, não contendo licenças ou cracks. As licenças são vendidas pela Siemens, pela central da empresa em São Paulo. Os cracks são de conhecimento público e não serão publicados nesse blog.

Espero que consigam desfrutar bem do software quando necessário. O link é esse aqui e tem cerca de 900MB no formato .RAR, sem senhas ou truques.

segunda-feira, 13 de junho de 2011

Ferramenta para Comunicação Serial

Uma ferramenta que sempre vai ser necessária para quem trabalha com programação de CLP`s ou supervisórios é um software que monitore o que está passando pela serial. Desde que se conheça o protocolo em comunicação, enxergar o que está sendo trafegado pela serial ajuda a entender eventuais problemas no sistema que está sendo desenvolvido. Nesse sentido, uma ferramenta que cumpre o que promete é a RComSerial, que está nesse link.

Já utilizei esse software em duas ocasiões principais:
- Para programar um CLP para receber dados de uma estação metereológica da Vaisala. A central cospe informação em um protocolo de caraceteres e uma IHM com CLP incorporado da Dakol faz a leitura e tradução dos dados para um supervisório capturar e registrar; 
- Ao implementar um sistema de impressão de etiquetas para um fabricante de lanternas, onde o supervisório cospe uma string quando uma peça é aprovada. Para ter certeza que o micro de impressão recebia corretamente as mensagens, usei o software para disparar a string esperada, ajustei as propriedades da serial e garanti que a configuração enviada para impressão seria a correta. 

Esses são dois casos em que usei o software para disparar informações em um formato conhecido. Você vai encontrar outros usos para ele, facilmente! Divirta-se! 

terça-feira, 7 de junho de 2011

Os top do SupervisórioBR

Passados pouco mais de 2 anos, os artigos mais lidos do blog são, na ordem:

1 - Softwares Supervisórios - todos são ótimos!!! Mas ...

2 - Modelo de Comunicação - Elipse Scada

3 - Roteiros de Treinamento do Elipse Scada

4 - Download de Drivers Elipse

5 - Aprender o quê, mesmo?

6 - Roteiros de Treinamento Indusoft

O mais lido e o quinto da lista foram publicados em 2010. Já os outros, são todos da nova fornada que mandei ao ar desde Março/2011, quando a visitação do site cresceu mais de 6 vezes nas contagens mensais.

Se ainda não leu algum dos posts, vale a pena. E deixe seus comentários.

segunda-feira, 30 de maio de 2011

Parâmetros de Tags no protocolo MPI

Por muito tempo (uns 9 anos, para ser mais preciso) fiquei me perguntando de onde viriam os formatos de dados a serem lidos em tags quando se usa o formato MPI da Siemens. E tudo foi resolvido quando tive que consultar o modelo de comunicação e arquivos de help do Indusoft, que será assunto de novo post, provavelmente na semana que vem. 
E aí está um caso que mostra que não importa se um manual está em português, inglês ou russo: basta ter qualidade e informar o que preciso ser informado. O trecho foi retirado do manual do driver MPI:


Com esse padrão mostrado acima, fica fácil decodificar os seguintes endereços:
- M:W340
- DB120:DBW120
- M:B100.1
- DB120:DBF220

E por aí vai. Mas é certo também perceber que é impossível ler uma variável MDxxx. Mas essa é outra história que qualquer um que já programou Siemens consegue resolver com um MOVE...

O  link para o manual completo é esse aqui!

Comunicação com Siemens S7-300 usando PC-Adapter na USB

Um caso clássico de problemas ao adquirir um novo notebook é a questão das portas seriais. Notes novos não tem mais esse item pré-histórico já tem algum tempo? Afinal, tudo hoje suporta USB, de pen-drives a telefones celulares. Certo?
Nem tanto!
Num mundo cheio de sistemas de automação com necessidades de disquetes e portas-seriais, as portas USB trazem facilidade, mas também alguns problemas.
No caso de comunicação MPI para acessar e programar CLPs Siemens famílias S7-300 e S7-400, o cabo USB de nome 6ES7972-0CB20-0XA0 é uma mão na roda. Além de se conectar com quase qualquer notebook, ainda por cima deixa a comunicação mais estável. Pronto! Só que se você precisar do driver ou tiver perdido o CD de instalação, o software desse link pode te ajudar. É só baixar e executar.
O restante continha igual: para comunicar, vá ao Set PG/PC Interface e selecione, ao invés de porta serial, a porta USB. Simples!

quinta-feira, 26 de maio de 2011

Roteiros de Treinamento do Elipse E3

O link para os roteiros de treinamento do Elipse E3 estão nos links abaixo:


http://www.4shared.com/file/xRFZ_A3M/e3tutorial_ptb.html

http://www.4shared.com/file/sdUaFU6E/e3tutorial_advanced_ptb.html


Recomendo que se façam todos os exercícios do roteiro. Apesar do modelo adotado (de arquivo de ajuda do Windows) atrapalhar quem gosta de aprender olhando o todo e fazendo o que considera importante (nisso o formato de apostila pdf é imbatível), é possível realizar os exercícios sem dificuldades. 

Primeiro faça o tutorial e se achar necessário, faça o tutorial avançado. Have fun!

quarta-feira, 25 de maio de 2011

Modelo de Comunicação Elipse E3

Informações preliminares
As informações preliminares para os drivers Elipse são praticamente as mesmas para o Scada e o E3. Vale lembrar a diversidade de versões incompatíveis entre si, a documentação externa ao driver (se você for descuidado e tiver que retornar ao projeto depois de meses pode ter problemas), a cobrança por licença de driver, entre outros tópicos não muito abonadores. Pelo lado positivo, a diversidade de drivers para equipamentos nacionais é grande, assim como as de uso comum de origem estrangeira.

Configuração de Drivers
Para iniciar, é necessário criar um projeto, um domínio e etc, como etapas anteriores à instalação de um novo driver. Depois, é só selecionar Objetos de Dados e no grupo Drivers e OPC, clicar com o botão direito e ir para "Inserir driver de comunicação em", selecionando o projeto onde o driver será instalado. Vamos lembrar que no E3 o ente que agrega um ou mais projetos se chama domínio (é o domínio quem é executado e por consequência, seus projetos). 
A janela de localização de drivers será exibida, para que se selecione onde está o arquivo .dll correspondente ao protocolo desejado. 
Figura1: Adição de Novo Driver no Elipse E3
Feita a inserção e localização do driver, será criado o driver no projeto indicado. Se necessário, é possível alterar a localização do driver a partir da propriedade Driver Location, na janela de propriedades do E3 Studio.  

Figura 2: Alteração do driver ou de sua localização - DriverLocation
Partindo desse ponto, a configuração do driver é idêntica à mostrada no artigo sobre o Elipse Scada (aqui), sendo útil acompanhar essa informação por aquele post. 

Configuração de Tags
A parte que diferencia o Elipse E3 do Scada é a configuração de tags: não pelos drivers (que são compatíveis) ou pelas tags que precisam ser configuradas de modo bem parecido (estão lá os parâmetros P1 a P4, os tipos de tags, etc). Mas sim pelos recursos do Elipse E3 Studio. Toda a configuração de tags pode ser feita de modo centralizado e isso traz uma série de vantagens ao se pensar em tempo de desenvolvimento. 

A janela de configuração de tags é mostrada abaixo, e depois dela são apresentadas algumas discussões sobre seus recursos. 
Figura 3: Janela de Configurações de Tags
A janela de configuração de tags permite que eu comente:
- Os tags são desenvolvidos em uma planilha (inclusive, podem ser importadas de um Excel). Nessa planilha, todas as características relacionadas a endereços, permissões de escrita ou leitura, escalas e varredura são apresentadas no modo de edição;
- Os tags no Elipse E3 são configuráveis tanto nos blocos como nos tags individuais. É possível nomear qualquer endereço acessado no PLC;
- Não é possível nomear bits! É isso mesmo: se você economizar tags e acessar uma Word para usar seus 16 bits, eles não serão nomeados. Você terá que se lembrar que o bit00 é o botão de emergência, sempre! 
- Na área de botões da planilha, é possível adicionar novos tags, eliminá-los, configurar o driver, usar um "tag browser" (algo que funciona apenas para alguns drivers recentes), habilitar a comunicação e contar o número de tags desse driver. 
- Acessando o botão de configurar driver, você terá as opções de parametrização descritas no artigo sobre o Elipse Scada, já citado aqui; 
- Ao habilitar a comunicação, a planilha se modifica e passa a exibir o resultado da comunicação com os equipamentos a serem acessados pelo driver. Dessa maneira, é possível verificar se a comunicação está ok (tags em azul), se há falhas em algum tag (em vermelho) ou se a comunicação falhou com todos os tags. O E3 usa uma designação de status semelhante ao OPC, com valores entre 0 e 255, no parâmetro Quality; 

E persiste a dúvida: se não é possível acessar os bits de uma palavra com um nome próprio, pelo menos como podemos acessar esses bits? A janela abaixo mostra como realizar essa configuração. 
Figura 4: Janela de Propriedades do Tag
A janela acima mostra algumas informações importantes: 
- O parâmetro UseBitFields mostra se o tag permitirá ou não o acesso ao seus bits (se estiver false, qualquer acesso aos bits será mostrado como errado);
- O parâmetro AdviseType é importante para sintonizar a comunicação: ele indica se o tag será lido sempre ou apenas quando estiver em tela. Para bits, o normal é usar o valor 0-Always em Advise, pois eles poderão ser usados em alarmes, scripts ou objetos de servidor sem correr o risco de se perderem variações de status;
- O parâmetro EnableDeadBand é utilizado para que o timestamp do tag seja alterado apenas quando houver variação de valor. Isso era importante para sistemas que eram executados em computadores com limitações de desempenho, algo difícil de encontrar hoje. Além disso, para sistemas de medição e contabilização, por exemplo, é um desastre: se você não desabilitar esse parâmetro, vários valores serão perdidos, pois o consumo pode não variar por longos períodos de tempo (ou por vários ciclos seguidos). Fique atento!

Bem, já habilitamos a leitura dos bits, mas como acessá-los? É o que mostra a figura abaixo.
Figura 5: Acessando bits de uma word
Como é possível notar, é possível acessar todas as propriedades do tag (que foram configuradas na planilha de tags) e também os até 32 bits possíveis de um endereço (isso varia conforme o driver, o protocolo, o equipamento e a configuração do endereço), sem que seja possível dar nomes a eles. 
Esse acessos servem tanto para escrita quanto para leitura, desde que o tag esteja configurado para leitura ou escrita. 

Vantagens do Modelo Elipse E3
- A construção da planilha de tags em um único ambiente é interessante. Você consegue construir os tags, testar a comunicação e setar parâmetros em uma mesma janela. Isso agiliza eventuais correções e testes;

Desvantagens do Modelo Elipse E3
As desvantagens são basicamente as mesmas já citadas no artigo sobre o Elipse Scada:
- Drivers implicam em custos adicionais à licença de runtime;
- 3 Categorias distintas de drivers trazem ainda mais custos, quando se utilizam equipamentos de marcas top do mercado (como Siemens e Rockwell/Allen Bradley);
- Dependendo do projeto e da negociação, uma licença de drivers pode liberar até 4 drivers para execução: isso não é muito transparente para o usuário;
- Modelo baseado em parâmetros N1 a N4 implica em codificar ou decodificar o endereço recebido pelo PLC antes de implementar a comunicação;
- Não é possível criar tags bit: uma palavra tagueada pode ter seus bits acessados através dos nomes bit00 a bit31 (o que convenhamos, é muito intuitivo para o desenvolvedor);
- Excesso de padrões de configuração implica em ter de aprender cada driver e seus truques quando se vai iniciar um projeto novo. São pelo menos três modelos: drivers básicos com o SDK, básicos que usam o módulo IOKit e drivers especiais (alguns com IOkit e outros ainda com o SDK);
- Por ficarem "livres" no HD, é possível que falte o arquivo do driver no momento de transportar o projeto de um micro a outro. Fácil de resolver em ambiente de escritório, pode ser bem enrolado para resolver em campo;
- Drivers mais recentes (os baseados no IOKit) só acessam um canal de comunicação por vez (uma porta serial, um endereço IP) o que exige a criação de mais de um driver para projetos mais complexos;
- A formatação de endereços em códigos P1 a P4 torna qualquer manutenção ou mesmo o desenvolvimento pouco amigáveis: é necessário decodificar cada endereço ao tentar entender de onde vem aquela seqüência de tags medida1 a medida200 que o pessoal do PLC te passou como sendo a documentação do projeto. 

terça-feira, 10 de maio de 2011

Download de Drivers Indusoft

O download de drivers é algo que os fabricantes tentam de uma maneira ou outra controlar. Seja pela garantia de oferecer a versão mais recente do driver (quando os drivers mudam muito ao longo do tempo ou não estão completos ao serem lançados) ou simplesmente para rastrear onde estão potenciais usuários, é comum que se exijam cadastros e aprovações para acessar os arquivos de drivers. 

Com a Indusoft, é diferente: todos os drivers estão disponíveis aqui, e podem ser acessados sem qualquer tipo de cadastro.

Como é possível observar no link, os drivers têm as mais diversas "idades", de 1999 a 2010, o que indica que o modelo de tags não deve ter sido alterado significativamente ao longo dos tempos. Para quem desenvolve ou dá manutenção, isso é uma mão-na-roda. 

quarta-feira, 4 de maio de 2011

Download de Drivers Elipse

Complementando o post anterior, o link para download de drivers da Elipse é o http://www.elipse.com.br/drivers.aspx?idioma=1. Nesse endereço é possivel baixar todos os drivers da Elipse, que são compatíveis com o Elipse Scada e com o E3. Só que para isso, é necessário um cadastro a ser aprovado pelo pessoal de suporte técnico. Nada demais, certo?
Apenas tome o cuidado de guardar o seu login e senha, pois se precisar dela no futuro você pode precisar se cadastrar novamente (e aguardar a aprovação), pois a tela de login não ajuda muito a quem precisar de ajuda. 

Enjoy!

quinta-feira, 28 de abril de 2011

Modelo de Comunicação - Elipse Scada

Informações preliminares
           A Elipse Software dispõe de cerca de 250 tipos diferentes de drivers, cobrindo uma grande parte dos protocolos utilizados em indústrias e no setor de energia. Entre esses drivers destacam-se aqueles que são praticamente exclusivos: os drivers para equipamentos nacionais (como CLPs Altus e Atos). 

           Para conseguir um driver Elipse é necessário ter um cadastro no site (moderado pelo suporte técnico deles) ou solicitar via e-mail para alguém do suporte técnico. 
           Dentre os drivers disponíveis, a Elipse os divide em três categorias (os nomes sou eu quem dei, mas a lógica é a deles):
           - Comuns: normalmente dependentes de porta serial RS232 ou Ethernet;
           - "Premium" ou "Especiais": servem para se comunicar com PLCs de marcas mais famosas (Siemens, Allen-Bradley, GE, por exemplo) ou dependem de interfaces específicas - como KTX da Allen-Bradley ou CP-5412A2, da Siemens;
           - Drivers Elétricos: drivers mais elaborados e com recursos utilizados no setor elétrico de potência.

           Além disso, existem alguns modelos diferentes de configuração de drivers, que serão mostrados a seguir. Mas para começar, podemos citar os drivers em grupos:
           - Drivers mais antigos: seguem a configuração padrão criada no Elipse Scada, onde toda a ajuda necessária depende de arquivos de ajuda que acompanham o driver;
           - Drivers intermediários: um pouco mais elaborados, mas que dependem fortemente do documento de ajuda (principalmente para configurar os tags);
            - Drivers baseados no IOkit: drivers com melhores recursos (e padrão entre eles), onde é possível configurar a maior parte do processo de maneira padronizada. A proporção deles no total de drivers tem aumentado, mas nem todos foram portados para o novo modelo (ou mantiveram a padronização de tags ao serem portados). 
           
Configuração de Drivers
             A configuração de drivers no Elipse Scada começa ao se abrir o Organizer e acessar o item "Drivers". Ao clicar nessa opção, surgem as opções padrão mostradas na Figura 1: Novo (para criar novo driver no aplicativo), Deletar para eliminar o driver (mas não os seus tags), Configurar (para abrir a aba de configuração do driver) ou Ajuda (que funciona apenas para drivers antigos que têm os arquivos de ajuda internamente a eles). 

Figura 1: Criação de Drivers no Scada

               Ao selecionar um novo driver, é solicitado que se selecione o arquivo .dll do driver, que não tem limitação de localização por parte do Scada, podendo ser colocado onde o programador melhor entender. 

           Uma vez instalado o driver (e dependendo do modelo e da idade do driver), o procedimento de configuração pode tomar um dos caminhos abaixo. 

Drivers mais antigos
Figura 2: Configuração via P1 a P4

            Os drivers clássicos da Elipse têm sua configuração dividida em parâmetros P1 a P4, cujo significado varia de driver a driver. O importante é que eles sempre se referem ao modo como o driver vai se comunicar e não a endereços (que serão mostrados adiante), ou seja, fala sobre o meio físico, velocidade de comunicação e etc. Um modelo de configuração de driver é mostrado abaixo:
            P1 - Porta COM (0=COM1, 1= COM2, etc);
            P2 -BaudRate (10 = 9600, 20 = 19200, etc.)  + Paridade (0 = None, 1 = Even, 2 = Odd)
            P3 - não usado
            P4 - timeout

            Fácil, simples e tranquilo de se enrolar, não?

Drivers intermediários
           São drivers nem tão recentes que trazem algumas facilidades adicionais na hora de se configurar o driver, como a Figura 3 mostra. 
Figura 3: Configuração de Drivers intermediários

                   Nesse padrão, ao clicar sobre o botão Extras é aberta uma janela com um conjunto de opções pré-definidas, eliminando a necessidade (pelo menos parcialmente) de se decodificar uma informação em P1 a P4. 

Drivers com o IOKit
                     Esses drivers são os mais recentes da Elipse e trazem recursos de flexibilidade muito bacanas na hora de se configurar o driver. Com ele, pode-se por exemplo, migrar de uma rede serial para Ethernet apenas configurando parâmetros do próprio driver, sem ter que substituí-lo, como normalmente era feito nos drivers mais antigos. A Figura 4 mostra as opções para um driver Modbus baseado no IOKit.
Figura 4: Driver Modbus no IOKit
                 O IOKit tem cinco abas que são padrão para todos os drivers: Setup, Serial, Ethernet, Modem e RAS, mais uma ou duas abas relacionadas ao protocolo. A aba Setup é responsável por habilitar uma das outras quatro, dependendo da escolha que se faça. 
                Um recurso interessante do IOKit é que alguns tratamentos de erros podem ser definidos aqui: como número de retentativas de conexão, timeout de comunicação de tags, timeout sem resposta do driver que precisa ser respeitado antes de nova tentativa de comunicação, configuração de logs, entre outras. É uma solução boa, muito embora nem todos os drivers suportem as quatro opções de configuração (serial, modem, ethernet e ras) ou os drivers mais antigos ao serem portados nem sempre respeitem a configuração de tags (o que inviabiliza a sua atualização sem horas de engenharia). 

                   Assim, uma vez configurado o driver por um dos três tipos comentados acima, é a hora de configurar os tags de comunicação. 


Configuração de Tags
                     Os tags de comunicação do Elipse Scada podem ser de dois tipos: tags PLC ou tags Bloco. Eles se diferenciam pela organização e funcionalidade: enquanto o tag PLC pega um endereço por consulta ao CLP os tags Bloco solicitam (como o nome diz) uma série de tags consecutivos. 
                      Antes de se configurar um tag, algumas considerações a serem feitas:
                      - Os tags de todos os tipos no Elipse Scada podem ser distribuídos por pastas de maneira a ser definida pelo programador;
                      - Todos os tipos de tags podem conviver em uma mesma pasta;
                      - Dessa forma, toda a organização do aplicativo fica por conta do programador, para o bem ou para o mal. 

               Voltando ao tópico, a configuração dos dois é semelhante, então vou comentar apenas o tag PLC, ressalvando as diferenças para o bloco, ok?

Figura 5: Configuração de Tags PLC

            Os tags PLC ao serem criados, precisam ser nomeados (conforme regra de nomes comuns a arquivos do Windows - sem as extensões, claro). Depois disso, o driver deve ser selecionado na lista ao lado do botão Ajuda. Para desativar o tag, basta não selecionar um driver.

                A seguir, o tag deve ser parametrizado pelos parâmetros N1 a N4 (se for um tag bloco, B1 a B4). Esses parâmetros, assim como os dos drivers, dependem de uma codificação para serem estabelecidos. Um exemplo de tag Modbus pode ser:
                   N1: número do PLC na rede;
                   N2: índice do endereço IP cadastrado no Extras;
                   N3: endereço do tag no PLC;
                   N4: não usado.

                Existem exemplos mais complexos conforme o protocolo torna-se mais complexo. Mas o principal é que para versões diferentes de drivers do mesmo protocolo (por exemplo, o próprio Modbus) os parâmetros N1/B1 a N4/B4 podem ser alterados. Portanto, mantenha junto ao projeto todos os arquivos de ajuda de drivers que forem úteis, pois no futuro você pode ficar na mão por não saber o significado de cada parâmetro. 

                    Uma pergunta que vem logo à cabeça: como posso acessar uma Word no PLC e usar os seus bits de maneira independente? 

                 O Elipse Scada tem uma maneira inteligente de fazer isso, como mostrado na Figura 6. Para acessar os bits de um tag, clica-se sobre o tag e depois em Acessar Bits. 

Figura 6: Seleção de Bits de um tag
                  Cada um dos bits criados poderá receber um nome, o que significa que você pode taguear um bit de maneira bem interessante. Mas isso não economiza tags na licença de runtime pois os tags bit também são contabilizados na licença.

                 Os parâmetros de leitura e escrita automática foram criadas para economizar recursos dos antigos computadores. Já a habilitação de leitura pelo scan determina se o tag será lido por varredura ou apenas por scripts. 

                   O parãmetro Scan é importante ainda, visto que muitos sistemas utilizam portas seriais a 9600 ou 19200 bps. Ajustar quais tags devem ter prioridade sobre outros é algo muito importante para o Elipse Scada funcionar corretamente.  

                 Os botões de Ler e Escrever são o único modo de testar se o tag está configurado corretamente. E isso só pode ser feito com apenas um tag por vez. 

Vantagens do Modelo do Elipse Scada
- No Elipse Scada é possível criar tags bit a partir de uma palavra lida do PLC ou outro equipamento de campo;

- Existe no Scada uma referência cruzada que ajuda bastante na construção do aplicativo (ao alterar o nome de um tag, por exemplo); 


Desvantagens do Modelo do Elipse Scada
- Drivers implicam em custos adicionais à licença de runtime;

- 3 Categorias distintas de drivers trazem ainda mais custos, quando se utilizam equipamentos de marcas top do mercado (como Siemens e Rockwell/Allen Bradley);

- Dependendo do projeto e da negociação, uma licença de drivers pode liberar até 4 drivers para execução: isso não é muito transparente para o usuário;

- Modelo baseado em parâmetros N1 a N4 implica em codificar ou decodificar o endereço recebido pelo PLC antes de implementar a comunicação;

- Excesso de padrões de configuração implica em ter de aprender cada driver e seus truques quando se vai iniciar um projeto novo. São pelo menos três modelos: drivers básicos com o SDK, básicos que usam o módulo IOKit e drivers especiais (alguns com IOkit e outros ainda com o SDK);

- No Scada não é possível fazer comunicação com todos os tags ao mesmo tempo, apenas testar a comunicação isoladamente em cada tag (através de botões Ler e Escrever). O resultado é que fica difícil verificar se a comunicação funciona corretamente quando todos os tags são acionados;

- Por ficarem "livres" no HD, é possível que falte o arquivo do driver no momento de transportar o projeto de um micro a outro. Fácil de resolver em ambiente de escritório, pode ser bem enrolado para resolver em campo. 

quarta-feira, 20 de abril de 2011

SupervisórioBR - 2 anos!!

Apesar de não ser muito movimentado no início, faz dois anos que o blog está no ar.

E podemos comemorar que nos últimos meses a coisa decolou: sempre a cada mês mais visitantes aparecem, e estamos completando um novo recorde esse mês.

Fiquem à vontade para comentar ou questionar quando discordarem de algo, ok?

Nesse período registramos visitantes brasileiros, claro. Mas também já veio gente de Israel, EUA, Canadá, Argentina, entre outros. Se todos falam português, não sei! Mas os nomes e produtos comentados no blog são internacionais, o que facilita a visita, certo?

Vamos lá! Ainda temos muito a fazer para tornar o blog uma referência em informações sobre SCADA, no Brasil e fora dele. Quem sabe?

segunda-feira, 18 de abril de 2011

Modelo de Comunicação - Sequência de Etapas

Para realizar comunicação com equipamentos, a sequência a ser adotada em praticamente todos os supervisórios é semelhante. Desse modo, antes de comentar algum supervisório específico, vou abordar essa sequência para que seja mais simples entender quando chegar a vez de comentar cada um dos softwares específicos.
Vou padronizar os posts de comunicação para facilitar a comparação entre diferentes softwares e cada item abaixo será um modelo do que será discutido posteriormente. 

Informações preliminares
       Algumas informações são importantes quando se fala em drivers, ou quando se questiona um fabricante se seu software se comunica com algum equipamento. Ou mesmo quando a resposta do fabricante é um "sim" desejável, mas cheio de "senões" questionáveis. 
       Ao iniciar a conversa com um fabricante, é necessário verificar alguns pontos, que considero importantes:

- Existe um driver para o equipamento que pretendo comunicar?
    Um fator importante para um software supervisório é a quantidade de equipamentos com que ele se comunica. Imagine desenvolver um projeto, instalá-lo, usá-lo por um período e na primeira ampliação do sistema, ter de trocar e começar tudo de novo pois não existe um driver disponível? Isso não faz muito sentido, embora possa ser remediado com outras perguntas, como as comentadas abaixo. 

- Esse driver (se existir) está atualizado e completo?
    Ótimo, você conseguiu um driver para uma rede de seu interesse, mas na hora de comunicar, entra alguém do suporte na linha e diz que "esse driver não funciona com esse equipamento" ou então "precisamos finalizar o driver pois o protocolo só foi feito parcialmente". Isso pode aumentar seu custo depois de iniciado o projeto ou deixá-lo aguardando por um prazo que não faz sentido no seu projeto. Se for iniciar um projeto com uma ferramenta desconhecida (e portanto uma empresa desconhecida para você), exija comunicações por escrito nesse ponto. 

- Qual a capacidade máxima do driver em termos de equipamentos? 
     Protocolos têm padrão para o número máximo de equipamentos em uma rede. Modbus por exemplo, suporta até 254 escravos. Mas e o driver de seu supervisório: ele suporta todas as portas seriais usadas em seu sistema de rádio ou celular?

- Qual a quantidade de redes diferentes que posso acessar com esse driver?
     Outra dúvida: quantas redes de equipamentos meu equipamento pode se comunicar, se eles estiverem pendurados em mais de um varal RS-485? Usar mais de uma cópia do driver pode ser uma solução, mas é a ideal para você?

- Qual a quantidade de IPs de uma mesma rede posso acessar com esse driver?
     Problema bastante comum nos dias de hoje, quantos IPs seu driver pode acessar? Se seu PLC tiver um endereço IP próprio, em uma rede de 5 PLCs quantos drivers deverão ser utilizados?  

- Se não existir o driver, qual a política de desenvolvimento de drivers?
     Existe uma equipe de desenvolvimento de drivers dedicada a novos protocolos? Os últimos prazos para desenvolvimento de drivers foram cumpridos? Existe um custo para o desenvolvimento ou isso é feito dentro do escopo das licenças de software?

- Existe um SDK para desenvolvimento de drivers de maneira gratuita e irrestrita?
     Se você tem alguém na equipe que programa C/C++ você conseguiria desenvolver seu próprio driver, se o fabricante disponibilizar um SDK. E se houver esse SDK, ele é o mais recente em termos de tecnologia existente no fabricante?

- Existe suporte para o uso do SDK disponibilizado?
    Se houverem dúvidas com o uso do SDK, existe um canal para eliminar dúvidas?

- Tags internas contam como pontos para determinação de licenças de execução?
    Ponto importantíssimo, reflete a organização e o cuidado que se deverá tomar na hora da especificação da licença de execução. Ainda assim, só será possível contabilizar tags internos ao final do desenvolvimento. 

- O custo dos drivers está embutido na licença do software ou drivers são cobrados à parte, conforme forem necessários?
   Outro ponto importantíssimo pois reflete custos: os drivers são livres para serem usados em qualquer aplicação ou trazem um custo adicional ao software que você não esperava ter quando especificou sua licença? Esse ponto é reflexo das questões sobre a capacidade máxima do driver (quanto a redes, IPs e quantidade de equipamentos possíveis). 

Configuração de Drivers
     O primeiro passo para colocar a comunicação em execução é a configuração de drivers. As perguntas anteriores trarão o reflexo imediato nessas etapas. Como cada software tem sua lógica de configuração, serão expostas aqui as etapas para configuração de um driver padrão Modbus TCP, com todas as possibilidades existentes em cada uma das famílias a serem apresentadas. 

Configuração de Tags
      Uma vez configurados os drivers de comunicação, começa-se a construir a base de tags. E como essa configuração é distinta entre os supervisórios, mais uma vez os passos serão seguidos e apresentados para construção do projeto. 

Vantagens do Modelo de Comunicação
      Certo, não queremos simplesmente comparar e dizer qual o melhor, mas... Se são diferentes, uns têm características melhores que outros em certos pontos. É aqui que vamos discutir essas vantagens. 

Desvantagens do Modelo de Comunicação
       O que te fará perder a cabeça ao utilizar o software? Qual a justificativa furada para uma falha do software que você precisará saber? Nessa seção, as deficiências serão comentadas comparativamente a outras ferramentas. 

Conclusões
      Considerando que programadores são diferentes e têm preferências por diferentes ferramentas, as soluções para uma mesma questão podem ser muito diferentes. Por esse motivo, os próximos posts serão interessantes ao comparar diferentes métodos de comunicação. 

quarta-feira, 6 de abril de 2011

Roteiros de Treinamento do Elipse Scada

Tenho o roteiro de treinamento e o manual de referência do Elipse Scada para download nos links abaixo.

Mas se você estiver pensando em começar agora, nem comece! O Elipse Scada está em decadência, pois o E3 assumiu a condição de melhor software da Elipse, já faz alguns anos.

Mas...
Se achou o Elipse E3 difícil e caro, tente o Indusoft. Ele é fácil e tem um preço inicial bacana, mas não tem todos os recursos do E3.

Se achou o E3 bom e caro, tente o Pulse. Ele tem um ótimo nível de recursos e um preço bacana.

É, concorrência é tudo! De qualquer modo, seguem os links para o Elipse Scada.

http://www.4shared.com/document/xtJJ3jHv/manual.html
http://www.4shared.com/document/cOTjEOA_/tutorial.html

Divirta-se!!!

Roteiros de Treinamento Indusoft

Consegui com a Indusoft duas versões do roteiro de treinamento no software. O primeiro está em português e o segundo em inglês.  O terceiro é um documento com informações genéricas da versão 6.1, que não é mais a atual.

Eles estão no link abaixo, onde pretendo colocar mais coisas assim que for possível. Por enquanto, seguem os links para os roteiros.

http://www.4shared.com/document/jVG1eQ1y/Apostila-PTBR.html

http://www.4shared.com/document/SxpvHHnq/Apostila-ENUS.html
http://www.4shared.com/document/aoE6D1gp/Datasheet_V61.html

Divirtam-se!

quarta-feira, 23 de março de 2011

Modelos de Comunicação - Tags, Drivers e Meios Físicos

Vamos falar mais um pouco sobre modelos de comunicação, abordando os temas Tags, Drivers e Meio Físico. Essas definições são importantes pois impactam a maneira como os supervisórios realizam a comunicação com os equipamentos de campo. 

Meio Físico: meio físico é o tipo de ligação entre um equipamento e o computador onde o software supervisório é executado. Entre os meios físicos mais comuns estão:


  • Portas RS-232: porta de comunicação mais comum em computadores desktop, raramente são vistas nos notebooks atuais. Esse meio de comunicaçaõ serve para ligar um mestre a um escravo, ou seja, um equipamento ou software a outro equipamento ou software. Normalmente, quando se usa uma porta RS-232 o supervisório é o mestre na comunicação, ou seja, é dele que partem os questionamentos que chegam ao PLC. Redes que utilizam esse tipo de porta têm alcance limitado (a alguns metros, dependendo do ambiente); 
  • Portas RS-485: permitem a ligação entre dois ou mais equipamentos, através de um varal de dois fios. Essa rede pode ser usada também para aumentar o alcance de uma rede RS-232, utilizando-se nas terminações um ou dois conversores RS-232/RS-485. Cabeamento simples e longo alcance, mas os computadores não têm portas RS-485 (é necessário utilizar conversores);
  • Rede Ethernet: os modelos mais recentes de PLCs costumam trazer portas de comunicação Ethernet, o mesmo padrão físico utilizado em redes de computadores. Isso é interessante, visto que todos os computados vendidos atualmente dispõem de uma porta desse tipo. Mas para sistemas mais antigos, essa opção é inexistente;
  • Meios físicos dedicados: alguns protocolos e equipamentos exigem meios físicos dedicados. Por exemplo, os equipamentos da Siemens exigem placas especiais que criam meios físicos próprios para os protocolos criados pela empresa. Outro fabricante que costuma usar essa abordagem é a Allen-Bradley/Rockwell.  


 Tags: é a menor unidade de comunicação de um sistema supervisório e reflete, normalmente, um equipamento ou um conjunto deles (quando associados). Um tag, reflete, por exemplo, uma bomba (ligada ou desligada), a velocidade dessa bomba, as suas condições de alarmes. A forma como um tag é construído e acessado difere entre os supervisórios. O importante é poder diferenciar que existem dois tipos de tags que influenciam na especificação de um supervisório: tags de comunicação e tags internos. 


  • Tags de Comunicação: São aqueles usados para resgatar ou parametrizar informações em um equipamento externo (PLC, controladores de temperatura, etc). 
  • Tags Internos: são aqueles que são usados exclusivamente no supervisório, para contagens, cálculos diversos, entre outras funções. 

A maneira de construir esses dois tipos de tags será analisada posteriormente, quando cada supervisório for comentado em separado. 

Drivers de Comunicação: como já comentado anteriormente, são os responsáveis por implementar a comunicação entre um supervisório e um equipamento, implementando um protocolo de comunicação comum aos dois lados. Esses drivers normalmente trazem limitações que devem ser observadas. Por exemplo, em uma rede Ethernet, quantos equipamentos conseguirei acessar se cada um deles tiver um IP diferente. Ou então, qual a máxima porta RS-232 do micro que consigo acessar usando esse driver.

Essas questões relacionadas aos drivers, implicam na especificação da licença do seu supervisório, e conseqüentemente, o custo final da licença de runtime.


Links interessantes


terça-feira, 15 de março de 2011

Modelos de Comunicação

A principal função de um sistema supervisório é exibir ao operador de um processo os valores atuais de variáveis importantes da planta a ser operada e ao mesmo tempo, permitir interação com esse processo através de comandos e setpoints. Todo os recursos restantes são consequência de como a comunicação é executada. 

Colocando dessa maneira, existe uma questão que se deve analisar ao pensar em sistemas supervisórios: como eles são capazes de se comunicar com sistemas em campo? Como é possível se conectar a diferentes equipamentos e medidas e manter uma interface única com o operador? Como um sistema pré-formatado consegue acessar novos equipamentos instalados na rede industrial, sem que sejam necessários grandes períodos e volumes de dinheiro investido nessa atualização?

A resposta é comum a todos os supervisórios do mercado: existem módulos responsáveis por essa comunicação que podem ser integrados ao sistema supervisório, sejam eles desenvolvidos pela própria fabricante do supervisório ou por fabricantes que adotam padrões abertos de comunicação. 

Sendo assim, para compreendermos o que chamei de "Modelo de Comunicação" vou pontuar alguns termos relacionados ao processo de troca de dados entre um supervisório e equipamentos de campo. 

Modelo de Comunicação: processo de configuração de um sistema supervisório para extrair dados de um equipamento de campo (seja ele um CLP, uma UTR, um controlador de temperatura, uma rede de dispositivos, etc). Esse modelo varia de supervisório para supervisório e é um dos pontos mais importantes no aprendizado de qualquer ferramenta desse tipo; 

Protocolo de Comunicação: conjunto de regras a serem seguidas para que a comunicação entre dois pontos aconteça. Na área industrial os protocolos mais comumente utilizados são Modbus, Profibus, MPI, DeviceNet, entre outros. Esses protocolos podem ser de domínio público (ou protocolos abertos) ou de domínio privado (protocolo fechado). Nesse último caso, é necessário pagar royalties para os donos da tecnologia de forma a ter acesso às suas definições de protocolo;

Definições de protocolos: normalmente englobam: tipos de meio físico, tipos de variáveis existentes, quantidades de mestres na rede, valores válidos para perguntas, sinalização de erros de comunicação ou perdas de mensagens, tipos de pontos de verificação existentes na mensagem, etc;

Driver de Comunicação: em todos os supervisórios existem os drivers de comunicação, que são módulos desenvolvidos com a função de permitir a comunicação com um equipamento de campo em um protocolo específico. Algumas características dos drivers de comunicação:
- São dependentes do supervisório: isso significa que não conseguem trabalhar sozinhos, pois devem ser parametrizados pelo supervisório;
- Não são intercambiáveis entre supervisórios de diferentes fabricantes: o modelo de desenvolvimento de um driver de comunicação varia de um supervisório para outro. Dessa forma, é virtualmente impossível que um driver criado por um fabricante seja compatível com o de outro fabricante. 
- São compatíveis entre versões diferentes de supervisórios de um mesmo fabricante: normalmente, ao substituir uma versão antiga por uma mais atual, é possível migrar os aplicativos para a nova ferramenta. E isso é repetido com os drivers, que costumam manter compatibilidade com drivers antigos nas novas ferramentas;
- São softwares especializados: normalmente um driver de comunicação implementa um único protocolo de comunicação. Mais que isso, quanto mais específico for o driver, mais fácil será sua configuração. Mas será mais difícil de manter esse driver atualizado caso ocorram alterações no protocolo ou equipamento sendo lido;

Kit de desenvolvimento de drivers: alguns fabricantes permitem que se utilizem esses kits para a implementação de novos protocolos, mas a responsabilidade por essa criação é inteiramente do cliente;

Protocolo OPC: é um padrão de comunicação que substitui a necessidade de um driver de comunicação, pois um software (servidor OPC) faz a tarefa de comunicar com os equipamentos de campo e traduzir essa comunicação para o padrão OPC. Esse protocolo será discutido em um post ainda a ser escrito;

Em resumo, a idéia aqui não é discutir a fundo o funcionamento das redes industriais existentes, mas apresentar nos posts subsequentes o modo de se configurar a comunicação em diferentes supervisórios. Pelo menos 3 famílias serão abordadas (e se possível, mais delas serão acrescentadas com o tempo): Elipse E3, Afcon Pulse e Indusoft. São três famílias de software existentes há mais de 10 anos, uma brasileira e duas estrangeiras, com uma grande abrangência no mercado brasileiro. 

Links interessantes
Protocolo Modbus: www.modbus.org
Protocolo Profibus: www.profibus.org
Protocolo OPC: www.opcfoundation.org