$\times$ Controladores Digitais

Note: a equação genérica de um controlador digital pode ser:

C(z)=\dfrac{K(z-a)}{(z-b)}

Este controlador para ser implementado num sistema computacional deve ser modificado para equações de diferença.

Quando este controlador é incorporada num sistema de controle, sua equação fica:

U(z)=E(z) \cdot C(z)

$U(z)$ $u[ktT]$ $E(z)$ $C(z)$ é a equação do controlador.

Então podemos escrever:

C(z)=\dfrac{U(z)}{E(z)}=\dfrac{K(z+a)}{(z+b)}

$z^{-1}$ teremos:

\dfrac{U(z)}{E(z)}=\dfrac{K(1+a z^{-1})}{(1+bz^{-1})}

desenvolvendo mais:

U(z) \cdot (1+bz^{-1})=E(z) \cdot K (1+az^{-1})

U(z)=E(z) \cdot K (1+az^{-1}) - bz^{-1}U(z)

$z^{-1}F(z)$ $f[k-1]$ (uma amostra atrasada), podemos reescrever a última equação como:

u[k]=K \cdot e[k] + K\cdot a \cdot e[k-1] - b \cdot u[k-1]

$u[k]=$ $u[k-1]=$ $e[k]=$ $e[k-1]=$ $a$ $b$ $K$ correspondo ao ganho geral deste controlador.

E assim obtemos a equação ou lei de controle que pode ser implementada num sistema digital.

Note que evidentemente, não implementamos a equação anterior usando arrays numa linguagem de programa. Se associa uma variável escalar comum para cada um dos termos anteriores, gerando um código final como:


u = K*e + K*a*e1 - b*u1

u $u[k]$ ; K corresponde ao ganho genérico do controlador; a corresponde ao zero do controlador (no plano-z) ; b e $e[k]$ e1 $e[k-1]$ u1 $u[k-1]$ ou valor da amostrada passada do sinal de controle.

Esta equação (ou lei de controle) deve ficar dentro da rotina de controle em tempo realtask síncrona $T$ que correspondeo ao perído de amostragem usado no projeto do controlaor. Algo como por exemplo:

OU ainda esta lei de controle pode ser ainda implementada na foram de uma rotina de tratamento de interrupção que é disparada a cada instante de tempo que ocorra o overflow de certo temprorizador (timmer) ou contador exclusivamente dedidacado para isto num sistema microprocessado simples. O programador neste caso, deve reservar certo timmer ou contador e programar a habilitação da rotina de tratamento de interrupção assim como a carga inicial deste timer (o equivalente à algo como Control_task.start, de forma que um overflowtimer $T$ adotado no projeto do controlador seja alançando e que seja disparada uma interrupção por software que chama automaticamente esta rotina de tratamento de interrupção que neste caso é a própria rotina de controle.

Note que estas abordagens dão uma liberadade e facilidades muito grandes na programação de um sistema embarcado específico, uma vez que uma vez haibilita a "task síncrona" de controle ou rotina de interrupção que corresponde ao controlador, a lei de controle é automaticamente chamada.

Ao contrário da técnica de pooling, o programador não necessita incorporar a lei de controle dentro do programa principal de uma máquina mas condicionar sua execuçao ("IF's") sempre que se cumpra determinada passagem de tempo correspondete ao perído de amostragem desejado. Este último caso implica ler um "relógio do sistema" (tiks) do sistema, gravar o estado em certa variável e mais adiante no código, ler novametne o relógio do sistema e calcular a diferença ente o valor acumulado anteriormente o o valor atual e testar e esta diferença de tempo (perído passado), coresponde ao período de amostragem desejado.

Note que a técnica de poolingnão garante $T$ período de tempo. Como o bloco de controle está dentro do programa principal, se esta mesma rotina principal desviar seu processametno para rotinas de tratamento de comunicação (que pode implicar em atrasos por perda de sinal, timeout), ou porque na rotina principal está previsto a leitura de um teclado para permitir que o usuário altere parâmetros como curva de setup (referência), ganhos do controlador ou outros parâmetros, quaisquer atrasos na leitura destes dados, implica em "pausar" o algorito de controle enquanto este tratamento de leitura de um teclado não é completado (provavelmente uma sub-rotina de leitura e tratamento de teclado), e neste caso, é muito provável que somento ao fim do tratamento da leitura de um teclado, surja uma oportunidade para a rotina principal voltar a testar o perído de tempo passado e constatar que o perído de amostragem já foi ultrapassado. Isto pode deixar o sistema sob controle instável, caso seu programador ainda tenha adotado ganhos elevados no seu controlador (a margem de ganho de controle baixa a medida que aumenta o período de amostragem).

Este problema também costuma ocorrer quanto na rotina principal que testa intervalos de tempo transcorridos entre passagens no código, para saber se deve ou não rodar a lei de controle, está incluída uma rotina (ou chamada para uma sub-rotina) de atualização de um display com informações do estado atual do processo (eventualmente gráficos) e/ou parâmetros do controlador. Lembrar que sistemas microprocessados simples, usam displays LCD cujo temo de escrita na memória do mesmo pode ser comparável em valor com o período de tempo que deve ser adotado para a lei de controle (poderia dizer-se que estão na "mesma escala"). Neste caso, a rotina de atualização de um display vai acabar exigindo un tempo considerável para completar sua execução (depende da quantidade de informações que se pretendem que devam ser mostradas), acabando por atrasar a execução da lei de controle e então, muito possivelmente, o período de amostragem especificado no projeto do controlador (e para o qual seus ganhos foram planejados), deixa de estar sendo respeitado.

Estes fatos justificam porque dentro da rotina de controle sem atualização de display ou leitura/tratamento de dados. Nesta rotina não pode ser prevista nenhum leitura e/ou tratamento de teclado e nem atualização de dados num display. Estas tarefas consomem tempo que, dependendo do caso, ultrapassam em duração o próprio valor adotado para o período de amostragem do sistema. Por este motivo, recomenda-se fortemente o uso de interrupção ou task síncronas em sistema de tempo-real se houver esta disponibilidade.

O códifo que deveria etar dentro da rotina (ou task) de Controle acaba ficando semelhante à:


xxxxxxxxxx
y = ReadAD(canalA);
e = ref - y; // calculando erro atual (instantâneo)
u = K*e + K*a*e1 - b*u1;
WriteAd(canalB, u); // passa sinal de controle para "fora"
// Atualiza variáveis para próximo ciclo de controle:
e1 = e; // amostra passada de erro = erro atual
u1 = u; // amostra passada sinal de controle = controle atual

Nonte que K, a e b devem ser preferencialmente variáveis globais, isto é, outra rotina fora do tratamento de interrupção pode modificar estes valores.

Equações de Diferença \times Controladores Digitais

$\times$ Controladores Digitais