Lógica de CLP de alarme de primeira falha (first-out): desafio de especialista

Qual falha aconteceu primeiro de verdade? O que o seu código deve fazer

Três defeitos se escondem em um rascunho que compila. Os operadores veem um código de falha diferente depois de reconhecer, e movimentos curtos da válvula às vezes disparam o alarme. Várias causas podem chegar em uma varredura. Conserte juntos o tempo, a captura da causa e o reconhecimento.

Partida e vazão

Uma nova borda de Start trava ValveCmd com Permit, sem Stop e sem Alarm. PumpOn é TRUE só com ValveCmd AND ValveOpen. A perda de Stop/Permit remove os dois comandos na hora; a restauração exige um novo toque em Start.

Três causas

TripCode 0 = limpo; 1 = Fault; 2 = Level >= 95%; 3 = ValveCmd sem ValveOpen continuamente por 500 ms. Chame Delay a cada varredura; sua primeira chamada verdadeira começa em zero. A chamada seguinte, em 500 ms, desarma. Uma varredura para mais ou para menos é aceita, porque o lugar da chamada de Delay a desloca em uma varredura. Um curso interrompido reinicia o atraso.

Primeira causa e prioridade

Se mais de uma causa aparecer na mesma varredura, Fault vence, depois nível alto, depois tempo limite da válvula. Depois da captura, preserve TripCode mesmo que outra causa apareça. Alarm = TripCode <> 0. Os dois comandos de processo devem estar OFF na varredura do desarme.

Horn e Ack

Uma nova captura faz Horn soar. Uma borda de subida de Ack silencia só Horn. Segurar Ack durante um reset válido não pode silenciar a próxima falha nova. Solte e pressione de novo.

Reset

Reset limpa TripCode, Alarm e Horn só com Start solto, Fault FALSE, Level < 95% e ValveStuck FALSE. A válvula continua fechada e um novo Start é necessário. Um Reset durante uma causa ativa não pode limpá-la.

Resete a simulação e selecione ValveStuck antes de pressionar Executar e Start. Veja ValveCmd e ValveOpen discordarem enquanto a válvula fica fechada. Teste e reproduza o limite exato do tempo limite. Use Entradas para segurar Ack enquanto limpa e reaciona uma falha; um novo evento ainda deve fazer Horn soar.

Qual falha aconteceu primeiro de verdade? Entradas e saídas

Seu programa lê 9 entradas e define 5 saídas. Os nomes são os mesmos no editor de qualquer fabricante.

No SCL da Siemens, escreva as tags do próprio bloco com # na frente, como faz o TIA Portal: #Start. Rockwell e TwinCAT use só o nome: Start.

O que as verificações testam

1. T1TripCode captura a primeira causa e não muda antes de um Reset válido.
2. T2A realimentação de abertura tem 500 ms; um comando interrompido começa uma nova espera.
3. T3Um Ack segurado não pode silenciar um evento posterior. Alarm, Horn, PumpOn e ValveCmd são verificados a cada varredura.

As verificações executam 7 testes na máquina, varredura por varredura: Uma planta saudável não pode resetar enquanto Start ainda está segurado; A primeira causa sobrevive a falhas posteriores; prioridade simultânea definida; No limite de nível alto, um Ack segurado não pode silenciar o próximo evento; Realimentação logo antes do limite evita um tempo limite; Um timeout de 500 ms desarma, trava e recusa um reset inseguro; Um curso interrompido recebe um novo tempo limite; A volta da permissão nunca religa um Start segurado.

Onde você encontraria isto

Um tanque de cervejaria para de encher depois de um alarme. O engenheiro precisa saber qual falha veio primeiro, antes que falhas posteriores a escondam.

Se falhas posteriores sobrescreverem o código da primeira falha, o engenheiro vai até o equipamento errado. Usar Ack para limpar o alarme poderia religar um equipamento que ainda está com defeito.

Resolveu ou travou? Converse sobre isso no Vestiário.