Manual dicas tecnicasavancadasdesenvolvimentosoftwareclp

Dicas e técnicas avançadaspara programação de CLPs

Documento número: 3.0018.01.02

Outubro de 2014

Dicas e técnicas avançadas paraprogramação de CLPs

ÍndiceIntrodução...............................................................................................3Dicas de boas práticas..............................................................................4

Utilizando nomes ao invés de códigos secretos.........................................4Semântica dos nomes de sinais..............................................................6Versionamento de código.......................................................................7

Exemplo de identificação de um sistema de automação..........................7Regra para alteração do valor da versão e da revisão.............................7

Histórico das alterações.........................................................................8Técnicas avançadas de estrutura..............................................................10

Proteção do núcleo..............................................................................10Máquina de tampar potes..................................................................12Configuração de I/O da máquina de tampar potes................................12

Saídas Digitais da máquina de tampar potes....................................12Entradas digitais da máquina de tampar potes.................................12

Exemplo de código sem proteção do núcleo.........................................13Exemplo de código com proteção do núcleo........................................13

Intertravamento por alarme.................................................................15Níveis de alarmes................................................................................17

Nível 4 - Interrompe todos os movimentos da máquina........................17Nível 3 - Desliga equipamentos..........................................................17Nível 2 - Interrompe o início do próximo ciclo automático.....................17Nível 1 - Somente informativo...........................................................18Classificação dos alarmes em níveis...................................................18

Sequenciador automático.....................................................................19Estrutura básica de cada passo do sequenciador..................................20Ciclo automático da máquina de tampar potes.....................................21Utilização dos sinais do sequenciador.................................................22

Controle de Revisões...............................................................................23

www.branqs.com.br Página 2 de 24


Introdução

É com grande satisfação que entregamos a você este conjunto de dicas e técnicas paraa escrita de software para Controladores Lógicos Programáveis (CLP). Procuramosreunir neste documento um resumo de algumas técnicas aperfeiçoadas em mais de 25anos de experiência na construção de software para a área de automação industrial.

Sabendo que este documento certamente chegará às mãos de excelentes profissionaisda área de automação industrial, e que certamente muitos deles terão inúmerasrecomendações a fazer e dicas a acrescentar, nos colocamos à disposição para discutiras técnicas aqui apresentadas através dos contatos publicados no site da Branqs(www.branqs.com.br).

Agradecemos pelo interesse e esperamos que este conteúdo possa ajudar váriaspessoas a criar sistemas cada vez mais confiáveis e fáceis de realizar manutenção.

Equipe de desenvolvimento da Branqs Automação

Nota: Este documento é totalmente original e de propriedade intelectual do autor. Nenhuma parte pode ser copiada oureproduzida de alguma forma sem a autorização por escrito da Branqs Automação LTDA.



Dicas de boas práticas

Utilizando nomes ao invés de códigos secretosUtilize sempre nomes elucidativos para os sinais existentes na lógica de seu programa.Infelizmente muitos desenvolvedores não respeitam esta regra simples e acabamgerando código de difícil interpretação. Como resultado, obtemos um programa maissuscetível a erros que fatalmente provocarão o incorreto funcionamento de umequipamento.

Para exemplificar, segue abaixo um trecho de código obtido a partir de um site queensina programação de CLP na Internet:

Perceba que mesmo representando uma lógica "aparentemente" simples, fica difícilsaber o efeito final da execução deste código em um equipamento. Isso ocorre pois nãopodemos facilmente interpretar o significado dos sinais “I3.1, I3.2, Q4.2 e Q4.11”.

Na mesma página da web, o autor apresenta uma tabela que descreve o significado decada sinal:

Address Description

I3.1 Forward pushbutton

I3.2 Front limit OK

Q4.2 Reverse solenoid

Q4.11 Forward solenoid


I3.1 I3.2 Q4.2 Q4.11


Sem dúvida nenhuma a tabela ajuda bastante. Mas vamos ver agora o mesmo códigoutilizando nomes melhores diretamente no diagrama. Por exemplo:

É fácil perceber que o aumento da clareza se torna evidente. Infelizmente esseproblema muitas vezes é motivado por limitações do próprio ambiente dedesenvolvimento de sistemas de automação. Alguns ambientes não permitem utilizarnomes longos, e por isso comprometem significativamente a qualidade do código.

Ainda analisando o exemplo da Internet, podemos perceber que as descriçõesoferecidas na tabela também não estão suficientemente completas. Considere aseguinte definição:

Forward pushbutton

Em português significaria :

Botão de avanço

Se considerarmos a existência de vários atuadores que poderiam provocar o avanço dealguma parte do equipamento, chegamos à conclusão de que esse nome ainda pode sermelhorado. Que tal se inseríssemos o nome do movimento específico na descrição dosinal. Exemplo:

Quanto mais aplicado este tipo de prática, mais robusto seu software irá se tornar.


botaoAvançolimiteAvanço

solenoideRecuo

solenoideAvanço

botaoAvançoCilindro

Fechamento


Semântica dos nomes de sinaisAlém da utilização de nomes mais completos e elucidativos, é muito importantetambém incluir o significado do estado representado pelo sinal. No exemplo anteriorobtido da Internet, a descrição do sinal I3.2 era “Front Limit OK”. Neste momento podesurgir uma grande dúvida, afinal, o que o autor quis dizer com “OK” ?

Para não depararmos com situações deste tipo é muito recomendado utilizar nomes queesclareçam o estado lógico que o sinal vai assumir em determinada condição física doequipamento. Supondo que o sinal I3.2 representasse um sensor que informa que ocilindro está avançado, poderíamos melhorar sua descrição utilizando o seguinte nome:

Perceba que o nome utilizado acrescenta várias informações:

Primeira informaçãoO sinal representa uma entrada digital

Segunda informaçãoPodemos concluir que o sinal é referente a um “sensor”

Terceira informaçãoO sinal deixa bem claro que estamos falando do movimento do cilindro

Quarta informaçãoO sinal terá o estado lógico "verdadeiro" quando o cilindro estiver"avançado"

A falta de preocupação com nomes provoca situações que induzem ao erro, pois podemexistir diferentes interpretações da função de cada sinal. Por exemplo, considere osseguintes nomes de sinais:

● motor● protetor● segurançaHidráulica

Podemos identificar potenciais problemas nos nomes acima: Perceba que é difícil saberse estes sinais representam atuadores ou sensores. É difícil também determinar emque situação estes sinais serão acionados ou desacionados. Por exemplo, mesmoconsiderando que o sinal do motor representasse uma entrada, ainda assim seria difícilsaber se o sinal representa que o motor está ligado, desligado ou com problema.Seguem abaixo alguns exemplos de nomes de sinais com melhor qualidade:

● entradaSensorMotorLigado● entradaSensorMotorDesligado● entradaSensorProtetorCompletamenteAberto● entradaSensorProtetorFechado● entradaSensorProtetorNãoFechado● saídaFechaProtetor● saídaAbreProtetor● saídaAtivaSegurançaHidráulica


entradaSensorCilindroAvançado


Versionamento de códigoO versionamento de código representa outra prática extremamente importante para acriação de sistemas de software de automação. Ao desenvolvermos softwaresembarcados “de prateleira”, que são utilizados em vários equipamentos ao longo dotempo, a adoção dessa prática impede grandes dores de cabeça ao se realizaratualizações.

Com o passar do tempo, é muito comum haver a necessidade de implementarpequenas melhorias e realizar a inclusão de novos recursos no software. Neste segundocaso, quando a implementação do novo recurso implica em alterações físicas noequipamento, muito cuidado deve ser tomado, pois o novo software possivelmente nãopoderá ser mais aplicado aos equipamentos antigos, já que estes não possuem asalterações físicas necessárias para aceitar o novo programa.

Dessa forma consideramos uma boa prática adotar um mecanismo de registro e gestãode todas as diferentes versões e revisões de código gerado. Segue abaixo um modomuito simples e interessante de realizar esse tipo de controle.

Exemplo de identificação de um sistema de automação

idVxxRyy

Onde:

● id = representa o código de identificação do equipamento● Vxx = Número da versão do software● Ryy = Número da revisão do software

Regra para alteração do valor da versão e da revisã o

Se a alteração a ser realizada permitir que o software seja utilizado em equipamentoscom revisões anteriores, então aumentamos somente o número da revisão.

Se a alteração a ser realizada impede que o software seja utilizado no lugar de revisõesanteriores, então aumentamos a versão, zerando o número da revisão. Exemplos:

Número original Alteração realizada Novo número

2017v01r00 Corrigido um erro que existia no código 2017v01r01

1013v02r05 Implementado um novo recurso no software,que poderá ser usado nas máquinas com as

revisões de software antigas

1013v02r06

1015v01r00 Implementado um novo recurso quenecessitou incluir um novo sensor na máquina

1015v02r00



Histórico das alteraçõesO controle sobre as alterações realizadas em um software de automação também éoutra prática muito importante. O registro adequado das alterações permite evoluirnosso conhecimento sobre os equipamentos e sobre o resultado de modificações feitasao longo do tempo.

Porém dependendo da ferramenta utilizada, este tipo de registro pode se tornarbastante trabalhoso. Nos exemplos abaixo iremos demonstrar uma forma muitointeressante de manter o registro do histórico das alterações realizadas em um código,gerando assim uma boa base de conhecimento a ser consultada em situações futuras.

Considere o seguinte código:

A primeira coisa a fazer é inserir um cabeçalho no arquivo do programa, descrevendoinformações a respeito das alterações realizadas. Perceba que para cada alteraçãocriamos uma TAG de identificação do motivo. Ex:

/////////////////////////////////////////////////// ////////////////Programa: 1003//Versao: 02//Revisao: 01//Data: 16/02/2010//Autor: Fernando//Descricao: Alteracoes no comportamento do avan ço do cilindro////10030201.0 O cilindro deve continuar avançando ao final do curso

Em seguida, as alterações seriam realizadas no código, e faríamos a citação dosindicadores dos motivos descritos no cabeçalho. Por exemplo:


tag

tag

botaoAvancoCilindro

Fechamento

entradaSensorCilindro

FechamentoAvancado

saidaSolenoideAvancoCilindro

Fechamento

10030201.0

botaoAvancoCilindro

Fechamento

entradaSensorCilindro

FechamentoAvancado

saidaSolenoideAvancoCilindro

Fechamento


É importante dizer que este tipo de registro é mais facilmente realizado em ambientesque fazem uso de lista de instruções. Considere abaixo o mesmo código do exemploapresentado em LADDER:

SEL (botaoAvancoCilindroFechamento)EN (entradaSensorCilindroFechamentoAvancado)MEMO (saidaSolenoideAvancoCilindroFechamento)

Onde:SEL = “Se ligado”EN = “e não”MEMO = “Memoriza”

Após realizar as mesmas alterações, o código ficaria com o seguinte aspecto:

SEL (botaoAvancoCilindroFechamento)//10030201.0 EN (entradaSensorCilindroFechamen toAvancado)

MEMO (saidaSolenoideAvancoCilindroFechamento)

Quando uma TAG é inserida antes da linha, indica que a linha foi retirada. Perceba quedessa forma, mesmo após realizarmos as alterações, é possível ver como o softwareera antes de haver a intervenção. Com certeza isso irá ajudá-lo muito durante toda avida útil desse sistema.


tag


Técnicas avançadas de estrutura

Proteção do núcleoQuando desenvolvemos software para automação de um novo equipamento, é muitocomum e saudável aproveitarmos um código previamente elaborado para outroequipamento semelhante. Existem inúmeras vantagens em se trabalhar assim. Éimportante perceber porém, que a falta de adoção de algumas técnicas podetransformar tais vantagens em grandes problemas. Resumindo, podemos transformaraquilo que era uma vantagem, em uma grande desvantagem.

Muita gente já passou por isso. Se conversarmos com alguns amigos profissionais daárea, é muito comum revelarem que já tiveram o seguinte sentimento:

“Caramba, esse software tá ficando muito complicado. Dá até vontade de jogar tudofora e começar novamente do zero”.

Percebeu? Aproveitar um código previamente elaborado e testado, que sem dúvidanenhuma seria uma vantagem, pode virar um pesadelo. Isso acontece porque ao longode várias alterações necessárias, o software pode se tornar muito confuso e cada vezmais propenso a apresentar erros que podem comprometer o correto funcionamento doequipamento e conseqüentemente a segurança de pessoas.

Considerando que estamos falando de equipamentos semelhantes, significa que ascaracterísticas relacionadas ao “domínio do problema” são praticamente as mesmas. Sópara exemplificar, considere os vários modelos de automóveis que existem no mercado.Praticamente todos possuem motor (que liga, acelera, desacelera e desliga), câmbio(com relações para andar para frente e para trás), portas (que abrem e fecham),volante (que direciona o carro para esquerda ou para a direita), vidros (que abrem efecham) e etc. Todos os carros realizam estas funções, e portanto possuem propósitossemelhantes. Porém é importante lembrar que cada modelo utiliza diferentesquantidades e diferentes tipos de atuadores (válvulas, solenóides, lâmpadas, etc) esensores (contatos, pressostatos, amperímetros, voltímetros, etc).

Resumindo, o “domínio do problema” é o mesmo, porém existem diferençassignificativas na implementação, já que cada carro possui sua própria configuração desensores e atuadores.

Da mesma forma que o exemplo dos automóveis, na área industrial encontramos vários



fabricantes para tipos semelhantes de equipamentos (ex:Tornos, Prensas, Caldeiras,Empacotadeiras, Injetoras,Sopradoras, Extrusoras, etc).

Cada tipo de máquina funciona com o mesmo propósito, porém com característicasdiferentes.

E onde estas diferenças interferem no desenvolvimento do sistema de automação?Resposta: No tratamento dos sinais de entrada e saída (I/O) do CLP.

Por exemplo, para um determinado modelo de prensa, é necessário utilizar um únicoatuador digital para comandar seu fechamento (ex:uma válvula direcional). Já emoutros modelos, podem ser necessários dois atuadores digitais e um atuador analógico.Perceba porém que os diferentes acionamentos realizam a mesma função, ou seja, ofechamento da prensa.

A mesma coisa ocorre em relação aos sensores. Por exemplo: Um determinado modelode prensa pode utilizar um único sensor para detectar que a porta de proteção dooperador está fechada. Outros modelos podem utilizar dois, três ou mais sensores. Damesma forma, o propósito continua sendo o mesmo, ou seja: “Verificar se o protetorestá fechado”.

Exemplificando, quando decidimos realizar o fechamento de uma prensa somente casoa porta de proteção do operador esteja fechada, representa uma discussão de “domíniodo problema” e não deveria depender da quantidade e tipo de sensores e atuadoresutilizados.

Dessa forma, dependendo de como o software de automação foi elaborado, aadaptação do programa para inserir ou retirar sensores e atuadores pode causar grandeimpacto no funcionamento do mesmo, fazendo com que funções triviais quefuncionavam bem no primeiro equipamento, apresentem falhas inesperadas nosegundo.

Sendo assim, a proposta da idéia da proteção do núcleo do software consiste em:

Não utilizar sinais de entradas e saídas físicas na lógica de domínio doproblema, mas sim, sinais cujo estado é resultado de uma lógica elaboradapara tratar tanto o interfaceamento de entrada como o de saída.

Considerando que a definição acima ficou um pouco complicada, vamos simplificaratravés de exemplos relacionados à automação de uma “Máquina de tampar potes”fictícia.



Máquina de tampar potes

Se possível, visualize esta máquina em funcionamento entrando na área de“Treinamentos” do site www.branqs.com.br

Configuração de I/O da máquina de tampar potes

Segue a relação de atuadores, sensores e botões da máquina de tampar potes

Saídas Digitais da máquina de tampar potes● Solenóide de Avança cilindro● Solenóide de Recua cilindro● Contator Liga motor da esteira

Entradas digitais da máquina de tampar potes● Sensor Cilindro recuado● Sensor Pote embaixo do cilindro● Sensor Cilindro avançado● Botão de acionamento manual para recuar cilindro● Botão de acionamento manual para avançar cilindro● Botão de acionamento manual para ligar esteira● Botão de acionamento manual para desligar esteira



Exemplo de código sem proteção do núcleo

Vamos agora brincar um pouco com programação. Analise o código abaixo. Perceba quea lógica que decide se o cilindro irá recuar pode utilizar diretamente sinais de entrada ede saída. Exemplo:

SEL (entradaBotaoRecuoCilindro)EN (entradaSensorCilindroRecuado)MEMO (saidaSolenoideRecuoCilindro)

É importante notar que, caso ocorra uma mudança em tal equipamento que necessiteadicionar algum sensor ou atuador relacionado ao movimento de recuo do cilindro, seránecessário alterar a lógica principal dessa função. A idéia de utilizar o conceito de"proteção de núcleo" é evitar este tipo de intervenção, preservando assim todos ostestes que já foram realizados e que garantem o correto funcionamento do sistema.

Exemplo de código com proteção do núcleo

Abaixo apresentamos a mesma função agora escrita utilizando o conceito de proteçãodo núcleo. Perceba que os sinais de entrada e de saída foram substituídos por sinaisauxiliares compatíveis com o domínio do problema, ou seja, a lógica principal(núcleo) agora utiliza sinais independentes de detalhes de implementação existentesneste equipamento. Exemplo:

/////////////////////////////////////////////////// ////////Interface Entrada/////////////////////////////////////////////////// //////

SEL (entradaBotaoRecuoCilindro)MEMO (pressionouBotaoRecuoCilindro)

SEL (entradaSensorCilindroRecuado)MEMO (cilindroRecuado)

/////////////////////////////////////////////////// ////////Núcleo/////////////////////////////////////////////////// //////

SEL (pressionouBotaoRecuoCilindro)EN (cilindroRecuado)MEMO (comandoRecuoCilindro)

/////////////////////////////////////////////////// ////////Interface Saída/////////////////////////////////////////////////// //////

SEL (comandoRecuoCilindro)MEMO (saidaSolenoideRecuoCilindro)

Analisando o programa acima, podemos perceber que a qualidade do código melhorou,pois uma vez testado o núcleo que contém a lógica de “domínio do problema”, podemosimplementar adaptações relacionadas ao I/O simplesmente alterando as interfaces,sem precisar alterar o núcleo.



Para exemplificar melhor, considere que ao aproveitarmos este programa paraautomatizarmos uma máquina similar, foi necessário modificar o tratamento de cilindrorecuado, já que a nova máquina não possui mais este sensor. Decidimos então fazeruso de um temporizador para considerar que o cilindro está recuado. Segue abaixo umexemplo de como isso poderia ser implementado a partir da técnica:

/////////////////////////////////////////////////// ////////Interface Entrada/////////////////////////////////////////////////// //////

SEL (entradaBotaoRecuoCilindro)MEMO (pressionouBotaoRecuoCilindro)

SEL (comandoRecuoCilindro)MEMO (dsp_duracaoRecuoCilindro)

SEL (fim_duracaoRecuoCilindro)MEMO (cilindroRecuado)

/////////////////////////////////////////////////// ////////Núcleo/////////////////////////////////////////////////// //////


/////////////////////////////////////////////////// ////////Interface Saída/////////////////////////////////////////////////// //////

SEL (comandoRecuoCilindro)MEMO (saidaSolenoideRecuoCilindro)

Obs: O sinal “fim_duracaoRecuoCilindro” será acionado quando o sinal“dsp_duracaoRecuoCilindro” for mantido acionado por cinco segundos.

Perceba que a alteração foi feita somente na interface de entrada, mantendo assim onúcleo do sistema intacto.

É muito importante tomar cuidado ao observar este exemplo de modo isolado.Aparentemente é fácil pensar que a proteção de núcleo não gerou um resultado tãoimpressionante, e que acabou aumentando um código originalmente bem simples.Porém, quanto maior e mais complexo for o sistema, maior será o benefício oferecidopela técnica em relação à manutenção de código. O exemplo aqui serviu somente parademonstrar como aplicá-la e provar que é possível modificar o software semcomprometer a parte do código responsável pela inteligência do sistema.



Intertravamento por alarmeÉ comum encontrar no mercado várias empresas que fornecem uma listagem doprograma LADDER juntamente com a documentação de seu equipamento. É curiosorefletir porque isso acontece. O motivo mais plausível é que tal informação ajuda muitoa equipe de manutenção a identificar os motivos da "não realização" de umadeterminada função pelo equipamento. Por incrível que pareça, esse tipo de iniciativaacaba sendo necessária porque muitos programas possuem deficiências não percebidaspor seus desenvolvedores.

Para exemplificar melhor, vamos analisar o código da lógica de recuo do cilindroexistente no núcleo do programa da máquina de tampar potes:

/////////////////////////////////////////////////// ////////Núcleo/////////////////////////////////////////////////// //////


Considere que o sensor de cilindro recuado esteja “em curto”, mantendo-se acionadomesmo quando o cilindro está avançado. Visualmente o operador identifica que ocilindro não está recuado e então pressiona o botão para poder recuá-lo. O sistema nãoresponde e também não informa o motivo.

Como já dito anteriormente, este tipo de situação é extremamente comum. Emsituações como essa, a listagem LADDER é necessária para permitir ao técnicodescobrir o que está impedindo o movimento. Eles analisam o código e percebem que ocomando não é realizado porque o programa considera que o cilindro já está recuado.

Infelizmente até ser reconhecida a causa, predomina aquela sensação de problema nopainel de controle da máquina.

Para contornar essa situação, alguns desenvolvedores precisam escrever uma lógica demodo invertido, somente para poder assinalar em uma tela de alarmes o motivo peloqual a solicitação que está sendo realizada não pode ser atendida.

Uma forma mais eficiente de resolver esse tipo de problema é utilizar a técnica deintertravamento por alarme. Nesta técnica, o núcleo do código é dividido em trêsblocos:

● Solicitações● Lógicas de Alarme● Comandos

O bloco da “Solicitação” irá tratar os sinais que “solicitam” a realização de uma função(tanto em manual como em automático).

O bloco da “Lógica de alarme” irá identificar que situação deve impedir a realizaçãoda função (intertravamento).



O bloco de “Comando” irá identificar se uma solicitação foi realizada “e não” existeimpedimento por alarme. Somente nessa condição o comando é realizado.

Analise abaixo a alteração realizada no código do núcleo da máquina de tampar potespara contemplar o padrão de intertravamento por alarme.

/////////////////////////////////////////////////// ////////Solicitações/////////////////////////////////////////////////// //////

SEL (pressionouBotaoRecuoCilindro)MEMO (solicitaRecuoCilindro)

.

. Solicitações de outras funções

.

/////////////////////////////////////////////////// ////////Alarmes/////////////////////////////////////////////////// //////

SEL (solicitaRecuoCilindro)E (cilindroRecuado)MEMO (alarmeCilindroRecuado)

.

. Alarmes de outras funções

.

/////////////////////////////////////////////////// ////////Comandos/////////////////////////////////////////////////// //////

SEL (solicitaRecuoCilindro)EN (alarmeCilindroRecuado)MEMO (comandoRecuoCilindro)

.

. Comando de outras funções

.

Dessa forma, o impedimento da função é realizado através de um alarme.Considerando que alarmes tem um papel essencial em sistemas de automação, é bemprovável que essa informação seja automaticamente apresentada na IHM doequipamento, alertando assim o operador.

É importante lembrar que esta estrutura determina que as solicitações de todas asfunções sejam feitas inicialmente, seguidas do bloco de alarmes e por último o bloco decomandos.

Agora, atenção ! O "Ministério dos Curiosos em Programação" adverte: Depois quevocê experimenta essa técnica, nunca mais aceita trabalhar sem ela.



Níveis de alarmesEm um sistema de automação é muito comum percebermos que certas condiçõesinterferem no comportamento de várias funções ao mesmo tempo. Considere porexemplo a situação onde um operador pressiona o botão de emergência de umamáquina. Dependendo do equipamento, situações como esta devem impedir oacionamento de qualquer função, já que está sendo sinalizada uma situação de perigoou de prevenção. De modo informal podemos dizer que o pressionamento do botãodeve possuir um efeito em Broadcast, ou seja, todas as funções do sistema devem serinfluenciadas por esta ocorrência. De modo análogo ao botão de emergência, outrassituações podem também demandar um comportamento comum em várias partes dosistema. Sendo assim, uma técnica muito interessante que adotamos na construção desoftware de automação de equipamentos, é classificar os diversos alarmes existentesem diferentes níveis que provocam uma reação comum em várias funções.

Cada projetista pode definir seus próprios níveis de alarme, que podem variar deacordo com sua própria experiência e de acordo com as características dosequipamentos automatizados. Apresentamos abaixo quatro níveis que temos adotadoao longo dos anos em vários tipos de equipamentos diferentes.

Nível 4 - Interrompe todos os movimentos da máquina

Este nível foi criado para impedir o acionamento de qualquer função do equipamento.Para isso, deve ser inserido “em série” na lógica de “comando” de todas as funções dosistema. Exemplo:

/////////////////////////////////////////////////// ////////Comandos/////////////////////////////////////////////////// //////

SEL (solicitaRecuoCilindro)EN (alarmeCilindroRecuado)EN (alarmeNivel4)MEMO (comandoRecuoCilindro)

Nível 3 - Desliga equipamentos

Este nível normalmente é usado para desligar equipamentos que possuem energiapotencial, evitando assim a geração de trabalho em situações onde isso não édesejado. É aplicado em situações extremas de parada incondicional, onde osequipamentos bloqueados normalmente são representados por motores e circuitos dealimentação. Dessa forma, existindo algum alarme que necessite provocar odesligamento de equipamentos deste tipo, basta classificá-lo como nível 3.

Nível 2 - Interrompe o início do próximo ciclo auto mático

Este nível de alarme é usado em situações onde o alarme ocorrido não necessitainterromper imediatamente o funcionamento da máquina, mas sim evitar que um novociclo automático seja iniciado. Mais adiante iremos representar sua utilizaçãojuntamente com o método de sequenciamento automático.



Nível 1 - Somente informativo

Este nível é usado somente para classificar os alarmes que não foram incluídos nosníveis acima. Consideramos uma boa prática utilizá-lo, pois assim fica explícito nocódigo a decisão tomada pelo projetista, evitando que a “não classificação” em níveissuperiores seja interpretada como esquecimento.

Classificação dos alarmes em níveis

A classificação dos alarmes em níveis deve ser realizada imediatamente após o bloco dalógica de alarmes e antes do bloco de “comandos”. Exemplo:

/////////////////////////////////////////////////// ////////Alarmes/////////////////////////////////////////////////// //////.. Bloco de alarmes./////////////////////////////////////////////////// ////////Níveis de alarmes/////////////////////////////////////////////////// //////

SEL (alarmeCilindroRecuado)OU (alarmeCilindroNaoRecuado)OU (alarmeEsteiraLigada) MEMO (alarmeNivel1)

SEL (alarmeProducaoConcluida)MEMO (alarmeNivel2)

SEL (alarmeBotaoEmergenciaPressionado)MEMO (alarmeNivel3)

SEL (alarmeProblemaSegurancaHidraulica)OU (alarmeNivel3)MEMO (alarmeNivel4)

/////////////////////////////////////////////////// ////////Comandos/////////////////////////////////////////////////// //////.. Bloco de comandos.

A adoção desta técnica permite termos mais controle sobre as exceções que podemocorrer durante o funcionamento do equipamento. Além disso simplifica o código efacilita futuras manutenções onde é desejado a mudança do comportamento damáquina em determinadas situações de alarme, pois em vários casos, basta areclassificação de um alarme em um nível diferente para atingirmos os resultadosdesejados.



Sequenciador automáticoDesde os primórdios da adoção de CLPs pela industria, muitas técnicas foramelaboradas para ajudar a definir e implementar a lógica do funcionamento automáticode equipamentos. A seguir apresentamos algumas delas que, ligeiramente modificadase combinadas com as técnicas de “Proteção do Núcleo”, “Intertravamento por Alarme” e“Níveis de Alarme”, permitem criar uma estrutura totalmente limpa, eficiente e segurapara escrita do código de um equipamento automático.

Iniciamos a discussão apresentando um diagrama SFC simplificado, que demonstra ofuncionamento desejado para a máquina de tampar potes em automático

.

Recua cilindro

Cilindro recuado

Liga motor da esteira

Bordo de subida do poteembaixo do cilindro

Desliga motor da esteiraAvança cilindro

Terminou tempo de avanço

Pressionou START

Esperando Start

O diagrama acima representa os passos (retângulos) do ciclo automático, e ascondições de transição (linhas) entre um passo e outro. Perceba que existe um passoinicial chamado “Esperando Start”, e um retorno ao passo “Recua cilindro” apóssatisfazer a condição “Terminou tempo de avanço”.

Nossa proposta é apresentar uma estrutura que possa reproduzir “exatamente” odiagrama acima, oferecendo sinais que poderão ser utilizados nos blocos de solicitaçõesapresentados anteriormente. Dessa forma, com o mínimo de alterações no programa,implementamos o código do ciclo automático que aproveita todas as seguranças eintertravamentos previamente definidos no modo manual.

Para entendermos esta construção, apresentamos em seguida uma estrutura básica dalógica de definição de cada passo do ciclo automático. Esta estrutura é inspirada pelométodo de cadeias estacionárias, porém acrescenta detalhes referentes às técnicasanteriormente comentadas.



Estrutura básica de cada passo do sequenciador

SEL (passoAnterior)E (condiçãoTransição)EN (alarmeNivel4)OU (passoAtual)E (automatico)EN (próximoPasso)MEMO (passoAtual)

Abaixo podemos ver a mesma estrutura representada em LADDER:

Repare que neste bloco são usados sinais referentes a três passos: O “passo atual”, o“passo anterior” e o “próximo passo”.

Os dois primeiros sinais (“passoAnterior” e “condiçãoTransição”) definem a lógica deacionamento do “passo atual”. Ao ser acionado, o “passoAtual” retém seu estado porter sido utilizado em paralelo com toda a lógica inicial do bloco (normalmentechamamos isto de “selo”). O “passoAtual” só será desacionado quando a máquina sairdo modo automático ou quando a condição do “próximoPasso” for satisfeita.

Seguindo este método, apresentamos o código responsável em habilitar as variáveis(passos) que nos ajudarão a controlar o ciclo automático da máquina de tampar potesconforme o diagrama SFC.


passoAnterior

alarmeNivel4

passoAtualcondiçãoTransição

passoAtual

proximoPassoautomatico


Ciclo automático da máquina de tampar potes SEL (automatico) SUBIDA EN (alarmeNivel4) OU (autoEsperandoStart) E (automatico) EN (autoRecuaCilindro) MEMO (autoEsperandoStart)

SEL (autoEsperandoStart) E ( teclaStart ) OU (autoFimCiclo) EN (alarmeNivel4) EN (alarmeNivel2) OU (autoRecuaCilindro) E (automatico) EN (autoLigaMotorEsteira) MEMO (autoRecuaCilindro) SEL (autoRecuaCilindro) E ( cilindroRecuado ) EN (alarmeNivel4) OU (autoLigaMotorEsteira) E (automatico) EN (autoAvancaCilindro) MEMO (autoLigaMotorEsteira)

SEL (autoLigaMotorEsteira) E ( poteChegouEmbaixoCilindro ) EN (alarmeNivel4) OU (autoAvancaCilindro) E (automatico) EN (autoFimCiclo) MEMO (autoAvancaCilindro) SEL (autoAvancaCilindro) E ( cilindroAvancado ) EN (alarmeNivel4) OU (autoFimCiclo) E (automatico) EN (autoRecuaCilindro) MEMO (autoFimCiclo)

Perceba que no segundo bloco foi usada também a variável do alarme de nível 2,impedindo assim o reinício do ciclo em caso de alarme deste tipo.



Utilização dos sinais do sequenciador

Após elaborado o sequenciador, basta utilizar os sinais referentes a cada “passoAtual”diretamente na lógica de solicitação de cada função. Ex:

/////////////////////////////////////////////////// ////////Solicitações/////////////////////////////////////////////////// //////

SEL (pressionouBotaoRecuoCilindro)E (manual)OU (autoRecuaCilindro)MEMO (solicitaRecuoCilindro)

Perceba que esta é a única intervenção que precisará ser feita no código de cadafunção, pois toda a parte de intertravamento já foi construída em modo manual.

Toda essa clareza e facilidade só foi possível graças a adoção do conjunto de técnicas eboas práticas demonstradas ao longo deste documento.

Para visualizar o código completo do exemplo da “Máquina de Tampar Potes”, e podersimular seu funcionamento em um computador PC, faça o download do “Simulador damáquina de tampar potes”, disponível no site www.branqs.com.br



Controle de Revisões

Versão: 01Revisão: 02Data: 14/10/2014Elaborado por: FernandoDescrição: Alterações realizadas para distribuição na Brazil Automation 2014

Transamérica Expo Center

Versão: 01Revisão: 01Data: 12/09/2012Elaborado por: FernandoDescrição: Alterações realizadas para distribuição na SEMATEC 2012 do Senai

de Cubatão - SP e no 5º Seminário e Exposição de Novas Tecnologias em Automação Industrial - ISA Expo-CAMPINAS

Versão: 01Revisão: 00Data: 16/10/2010Elaborado por: FernandoVerificado por: Kauê Leonardo (Técnico Instrumentação - PETROBRAS)

Thiago La Pastina (Técnico Eletro-Eletrônico - BRANQS)Daniel Leite (Técnico Automação - BRANQS)

Descrição: Versão inicial criada para distribuição na Brazil Automation 2010.


Retail

Manual dicas tecnicasavancadasdesenvolvimentosoftwareclp