¿Qué es la tabla de imagen de I/O de un PLC?

Volver al glosario

Dos tablas: la imagen de entrada y la imagen de salida

La imagen de proceso son en realidad dos tablas. La imagen de entrada, llamada PII en la terminología de Siemens, contiene un bit o una palabra por cada punto de entrada física. Al inicio mismo de cada barrido el controlador lee todos sus módulos de entrada y copia sus estados a esta tabla, de modo que la imagen de entrada se vuelve una fotografía del campo tomada en ese instante. La imagen de salida, la PIQ en la misma terminología, contiene un bit o una palabra por cada punto de salida física, y el programa escribe sus resultados aquí en lugar de directamente a los módulos.

Durante la porción de resolución de lógica del barrido, cada contacto que el programa examina lee de la imagen de entrada, y cada bobina que el programa energiza escribe a la imagen de salida. Los módulos físicos no se tocan en absoluto durante esta fase. Esto es deliberado: le da a todo el programa un solo conjunto invariable de valores de entrada con el que trabajar, para que una señal no pueda parecer que tiene un valor en el renglón 5 y un valor distinto en el renglón 200 dentro del mismo barrido solo porque el campo parpadeó en el intermedio.

Al final del barrido el controlador copia toda la imagen de salida hacia los módulos de salida físicos en una sola actualización, y los dispositivos de campo por fin ven los resultados que el programa calculó. Solo entonces empieza el siguiente barrido refrescando la imagen de entrada de nuevo. Esta disciplina de leer una vez y escribir una vez es lo que hace determinista y repetible un barrido de PLC convencional, y es por lo que las tablas de imagen se ubican en el centro de cómo cualquier programa de escalera o estructurado interactúa realmente con el mundo.

Por qué el controlador trabaja sobre una copia congelada

Trabajar sobre una copia congelada en lugar de la I/O viva resuelve un problema real. Si el programa leyera cada entrada física en el momento exacto en que encuentra esa entrada en el código, una señal de cambio rápido podría tomar valores distintos en puntos distintos del mismo barrido, y la lógica que compara dos entradas, o que usa una entrada varias veces, podría producir resultados inconsistentes o incluso autocontradictorios. Congelar todas las entradas al inicio del barrido garantiza que todo el programa vea una sola imagen coherente del campo durante ese barrido.

El mismo razonamiento aplica del lado de las salidas. Escribir las salidas de forma continua conforme la lógica se resuelve dejaría a una salida parpadear encendida y apagada varias veces dentro de un solo barrido conforme los resultados intermedios se agitan, castañeteando una bobina o válvula real. En cambio el programa asienta la imagen de salida a sus valores finales y los empuja todos a la vez, de modo que cada salida física cambia a lo sumo una vez por barrido y solo refleja el resultado terminado de la lógica. Esto hace más limpio y fácil de razonar el comportamiento de la máquina.

El costo de este esquema es un retardo incorporado entre el mundo físico y el conocimiento que el controlador tiene de él. Una entrada que cambia justo después de la lectura de inicio de barrido no es vista por el programa hasta que el siguiente barrido la captura. Una salida que el programa calcula no se aplica al campo hasta la escritura de fin de barrido. Para la mayoría del control de procesos estos retardos son triviales frente a las constantes de tiempo del proceso, pero siempre están presentes, y son el mecanismo detrás del comportamiento de temporizado que atrapa a la gente.

La trampa de temporizado a mitad de barrido y las consecuencias de campo

La sorpresa clásica es una entrada física que cambia a mitad de un barrido y simplemente no se nota hasta el barrido siguiente. Como la imagen de entrada se congeló al inicio del barrido, cualquier cambio que llegue después de esa lectura es invisible para el programa que corre en este momento; solo aparece cuando el siguiente barrido vuelve a leer las entradas. Un programador que espera que un botón rápido o un pulso corto se atrape en el instante en que ocurre puede quedar perplejo cuando la lógica parece ignorarlo, cuando en realidad el pulso simplemente llegó y se fue entre dos lecturas de entrada.

Esto es justamente por lo que existen las instrucciones de detección de flanco y de un solo disparo, y por lo que las señales muy rápidas pertenecen a hardware que no depende del barrido, como los canales contadores de alta velocidad o las entradas de interrupción. También explica por qué un pulso debe mantenerse verdadero por al menos un barrido completo para garantizar que se vea: cualquier cosa más corta que un barrido puede caer enteramente dentro de la ventana en la que las entradas no se están leyendo. Entender la tabla de imagen convierte estos de errores intermitentes misteriosos en comportamiento predecible y diseñado.

En una RTU remota en un pozo el efecto es el mismo pero las apuestas pueden sentirse más altas, porque los problemas son más difíciles de observar a distancia. Un cierre de contacto corto de un interruptor de nivel o un pulso de estado de un medidor debe condicionarse para durar lo bastante como para sobrevivir un barrido, o capturarse por hardware, o puede que nunca entre a la imagen de entrada en absoluto. Los programadores nuevos de RTU que asumen que el controlador vigila el campo de forma continua, en lugar de muestrearlo una vez por barrido, escriben lógica que funciona en el banco con un dedo lento en un interruptor y luego pierde eventos de campo reales y rápidos. Saber que el controlador vive sobre una copia congelada es el arreglo.

Preguntas frecuentes