Entendendo o básico antes de mexer no código
O programa de climatização via CLP (controlador lógico programável) não é complicado quando você para de complicar. A ideia central é simples: ler temperaturas, humidade, status de válvulas e motores, e escrever saídas que mantenham o ambiente dentro de uma faixa definida. O problema é que todo mundo tenta fazer um sistema universal e acaba com um código que não consegue debugar.
prg climatização: estrutura funcional mínima
Você precisa de pelo menos quatro blocos rodando em ciclo fechado. Entrada de sensores de temperatura PT100 ou 4-20mA. Entrada de sensores de humidade. Saídas para válvulas de água gelada, resistências, ventiladores e dampers. E um laço de controle que compara o setpoint com o valor atual e ajusta as saídas proporcionalmente. Isso é tudo. Tudo o que vem depois disso é refinamento ou luxo. O erro mais comum que vejo é programar cada equipamento como um bloco independente. Ventilador aqui, válvula ali, resistência num canto. Aí quando a condição muda, ninguém sabe quem decide o quê. Em vez disso, separe por função: blocos de leitura, blocos de lógica de proteção, blocos de controle PID, blocos de sequência. Quando algo quebra, você sabe exatamente onde procurar.
Lembro de um caso específico onde um cliente tinha um quarto limpo de hospital que ficava ora muito seco ora muito húmedo, e eu levei três dias para descobrir que o problema estava num bloco de proteção que truncava o sinal PWM da válvula sem notificação nenhuma. O sensor de humidade batia certo, o setpoint estava correto, mas a válvula nunca abria mais que 60%. A solução foi remover o truncamento e adicionar um alarme de saturação que avisasse quando a válvula chegava ao limite. O cycle time do programa ficou quase idêntico, a diferença foi só colocar os alarmes nos lugares certos.
Como construir o programa passo a passo
Comece pela lógica de segurança. Antes de escrever qualquer PID, defina o que acontece quando algo sai do controle. Alta temperatura, baixa temperatura, perda de comunicação com sensores, falha de ventilador. Anote isso em papel primeiro, senão você esquece alguma condição nas pressas. No meu workflow, gero entre 30 a 45 minutos definindo cenários de falha antes de abrir qualquer IDE. Depois vem a aquisição de dados. Mapeie cada entrada física para um endereço de memória. Não pule essa etapa. Já vi gente passar horas debugging porque misturou endereços analógicos com digitais no mesmo scan. Coloque registradores de escala separados para cada sensor. Um registrador para o raw value, outro para o valor escalonado em graus Celsius ou porcentagem de humidade. Manter isso separado evita que uma mudança de escala quebre um PID que estava funcionando.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O controle PID em si não precisa ser um mistério. A maioria dos CLPs modernos tem blocos PID nativos. Use-os. Os parâmetros iniciais que eu sempre parto são: ganho proporcional entre 0.5 e 2.0, tempo integral entre 10 e 60 segundos, e derivativo entre 1 e 5 segundos se o sistema tiver inércia térmica baixa. Sistema com muita inércia como uma sala grande com muito volume de ar? Derivativo alto atrapalha mais do que ajuda. Reduza para zero nessa situação. Seção de saídas merece atenção especial. Ventiladores geralmente precisam de escala gradual para não causar picos de corrente no painel elétrico. Válvulas motorizadas precisam de um tempo mínimo de atuação para não ciclar rápido demais e danificar o atuador. Eu costumo colocar um deadband de pelo menos 30 segundos entre comutações de válvula. Isso reduz o desgaste e também estabiliza a leitura de temperatura, que senão fica oscilando porque a água gelada ainda está percorrendo o tubo.
Depuração e testes
Nunca suba o programa num ambiente operacional sem simular primeiro. A maioria dos softwares de CLP tem modo de simulação. Use. Simule variações de temperatura bruscas, falhas de sensor, mudanças de setpoint. Se o seu CLP não tem simulação, pelo menos monitore as variáveis internas com o software conectado via cabo serial ou Ethernet. Passe pelo menos 20 minutos rodando cenários antes de liberar para o campo. Quando subir no equipamento real, monitore durante as primeiras 48 horas sem ajustar nada. É tentador começar a afinar o PID no dia seguinte, mas isso mascara problemas reais. Ajuste só se houver violação persistente de setpoint após essas 48 horas. Na prática, eu vejo sistemas estabilizarem em torno de 3 a 5 dias após a instalação, dependendo da carga térmica real versus a projetada.
Limitações que ninguém conta
Programas de climatização via CLP funcionam bem em ambientes fechados com carga térmica previsível. Se o seu sistema lida com variação brusca de ocupação, portas abrindo frequentemente, ou carga solar variável sem compensação, o PID puro vai sofrer. Nesse caso, considere adicionar feedforward: use a corrente do compressor ou a posição do damper de ar externo como variável de avanço no controle. Isso melhora significativamente a resposta a perturbações externas. O outro ponto cego é a deriva dos sensores. PT100s e sensores de humidade capativos perdem calibração com o tempo. Humidade relativa especialmente tende a deslocar 3 a 5% após dois anos de operação contínua. Se o sistema não tiver calibração periódica documentada, o controle pode parecer estável mas estar desviado do setpoint real. A solução é simples: agende verificação trimestral com referência conhecidade e ajuste o offset nos registradores de escala quando necessário. Leva 10 minutos por sensor e evita dor de cabeça futura.
Se o seu projeto é muito simples, como apenas aquecer ou arrefecer um espaço pequeno sem necessidade de controle preciso de humidade, um termostato diferencial com timer pode ser mais econômico e confiável que um CLP inteiro. CLP faz sentido quando você precisa de sequenciamento complexo, integração com BMS, ou controle de múltiplas variáveis simultaneamente. Para o resto, estar programando um CLP é Overengineering disfarçado de sofisticação. Para quem quer baixar um template funcional como ponto de partida, costumo usar estruturas baseadas em IEC 61131-3 padrão, com organização em POUs separados por função. O código em si não tem segredo, mas a organização é o que diferencia um programa que funciona de um que continua funcionando quando alguma variável muda inesperadamente.
