¿Debería normalizarse el término de error de PID?

2

Por "normalizado", quiero decir +/- 1 ~ = el error máximo que el sistema puede esperar razonablemente experimentar, o dividido por el punto de ajuste.

Antecedentes: estoy trabajando en un controlador PID para un calentador SSR que es muy sensible (5 ° C / s, 0.5-1 ° C / s de enfriamiento). El punto de ajuste está en el rango de 100-400 ° C. En el código, esto se implementa como:

$$ u (t) = K_pe (t) + K_i \ sum_ {t} e (t) dt + K_d [e (t) -e (t _ {- 1})] dt ^ {- 1} + K_k $$

(La suma es solo un acumulador y Kk es una pequeña corrección de estado estable)

Este formulario es bastante común en muchos de los códigos PID de código abierto que hay. Sin embargo, se me ocurrió que si tuviera que cambiar a ° F, de repente, mis términos K se desactivarán en 1.8. Esto no me parece matemáticamente "puro". Además, cuando intenté hacer que Ziegler-Nichols lo sintonizara, mi oscilación crítica es de ~ 24s, pero cuando pongo esto como Ki, tengo fluctuaciones descontroladas. Después de algunas excavaciones, encontré la ecuación en la lista como

$$ u (t) = K_c \ left (e (t) + \ frac {1} {T_i} \ sum_ {t} e (t) dt + {T_d} \ Delta e (t) dt ^ { -1} + K_k \ derecha) $$

Y tuve un momento bombilla. ¿Es esta la forma más "pura" de usar? Esto tiene más sentido cuando se trata del análisis de la función de transferencia y similares.

    
pregunta DeusXMachina

2 respuestas

2

Si e (t) yu (t) no están dimensionalizados, Kp no tiene unidades, Ki tiene unidades de tiempo ^ -1 y Kd tiene unidades de tiempo. De lo contrario, tienen unidades del proceso.

En la segunda formulación has cometido un error. Este es el que hay que usar.

$$ u (t) = K_c \ left (e (t) + \ frac {1} {T_i} \ sum_ {t} e (t) dt + T_d \ Delta e (t) dt ^ {- 1 } \ derecha) + K_k $$

Entonces Kc tiene unidades del proceso y Ti y Td tienen unidades de tiempo. Esto es bueno porque Ti y Td están en la misma escala y solo Kc tiene unidades de proceso. e (t) y u (t) no necesitan normalizarse porque solo Kc relaciona sus unidades.

    
respondido por el τεκ
0

Para propósitos de simulación y comparación, la normalización puede ser útil. Cambiar de ° C a ° F dentro del circuito de control no tiene sentido para mí. Trate de usar unidades SI siempre que sea posible. Si tiene un sensor curioso que entrega ° F, simplemente convierta la medida a ° C antes de introducirlo en el bucle de control.

Para la implementación depende de la arquitectura de destino. Si tiene un DSP de punto flotante puede mantener la normalización. Con un microcontrolador más pequeño, debe usar cálculos de enteros (por ejemplo, como puntos fijos) para mejorar el rendimiento y reducir el costo de memoria.

El control de temperatura, como en esta aplicación, suele ser lento. La velocidad no es un gran problema, por lo que probablemente no utilice un DSP, pero tampoco desea bloquear otras partes del programa con cálculos demasiado complicados.

Sugerencia para un código más pequeño y más rápido: ya puede incluir una escala en su \ $ K_C \ $ de la ecuación de control que se ajusta a su control de salida (por ejemplo, el registro de comparación de un módulo PWM). Sin embargo, esto le cuesta la portabilidad, así que solo hágalo si tiene recursos de hardware muy limitados.

También evita usar el formulario con la división por \ $ T_i \ $. La división cuesta muchos más ciclos que la multiplicación, ya que rara vez se implementa en hardware.

    
respondido por el Grebu

Lea otras preguntas en las etiquetas