Programación de PLC

Herramientras de diseño

Este libro está es sus inicios, por favor espere antes de leerlo! Los gráficos en arte ASCII serán reemplazados en un futuro cercano.

Especificación de requerimientos

Los requerimientos normalmente están escritos en lenguaje humano y se pueden extender con gráficos, por ejemplo tablas de verdad, casos de uso, diagramas de estado, etc. Vamos a definir varias versiones de requerimientos escritos en lenguaje humano y veremos como las podemos implementar sin otras herramientas de análisis, intencionalmente haremos implementaciones que cumplan los requerimientos pero que sean inadecuadas para el uso práctico.

Requerimientos:

El motor deberá ser controlado por un contactor
El contactor deberá ser comandado por el PLC
Dos botoneras deberán ser conectadas al PLC, una NA que cumplirá las funciones de botonera de arranque y una NC que cumplirá las funciones de botonera parada.
Al presionar la botonera de arranque el PLC debe energizar la bobina del contactor.
Al presionar la botonera de parada el PLC debe desenergizar la bobina del contactor.

Circuito eléctrico:

    24V ----------------------------------------------------------------
                                   |   |                               |
                               NA --- --- NC                           |
                                       /                               |
                                  --- ---                              |
                                   |   |                               |
				|----------------------------------------|
				|  0   0   0   0   0   0   Entradas    + |
				|  E0  E1  E2  E3  E4  E5                |
				|                                   QPLC |
				|  S0  S1  S2  S3                        |
				|  0   0   0   0   Salidas             - |
				|----------------------------------------|
	                           |                                   |
                                   |                                   |
				-------                                |
                                |  C  |                                |
				-------                                |
                                   |                                   |
                                   |                                   |
     0V  ----------------------------------------------------------------

Como vemos el circuito cumple los requerimientos a, b y c. Estamos obviando intencionalmente seguridades eléctricas necesarias en el circuito eléctrico como ser parada de emergencia, fusibles, guardamotor, etc.

Programa:

| | |----| |--------------------------------------------( )----| | I0 | S0 | | | | | | | |----| / |----| |----| | | I1 S0 | | | Prueba del hardware y software:

1) Presionar y soltar la botonera de arranque, la salida S0 se debe activar y quedar activada [Si/No]. 2) Presionar y soltar la botonera de parada, la salida S0 se debe desactivar y quedar desactiva [Si/No].

Luego de comprobar el hardware mas el software vemos que cumple con todos los requerimientos, mas ahora vamos a analizar el circuito y veremos que pasa si presionamos ambas botoneras, la respuesta es que el motor arranca (ejecutar la prueba 3 para comprobarlo). Puede que el resultado sea el correcto mas los requerimientos resultaron insuficientes, en realidad la implementación realizada sería considerada insegura en la mayoría de los casos, salvo posiblemente un bomba contra incendio.

Requerimientos adicionales:

f) Si ambas botoneras están presionadas el PLC debe mantener desenergizada la bobina del contactor.

Programa 2:

| | |----| |---------| / |------------------------------( )----| | I0 | I1 S0 | | | | | | | |----| |----| | | S0 | | |

Prueba del hardware y software 2:

3) Presionar ambas botoneras, mientras ambas botoneras están presionadas la salida S0 debe mantenerse desactivada [Si/No].

Vemos que el nuevo circuito cumple los requerimientos, o al menos cumple las pruebas con las que intentamos verificar los requerimientos, mas ahora vamos a analizar el circuito y veremos que pasa si la botonera de arranque tiene un problema mecánico y queda cerrado su contacto, la respuesta es que estando el motor en marcha, al presionar la botonera de parada se detiene mas al liberar la botonera de parada vuelve a arrancar (ejecutar la prueba 4 para comprobarlo). Repitiendo mas no sin razón, puede que el resultado sea el correcto mas los requerimientos resultaron insuficientes, en realidad la implementación realizada sería considerada insegura en la mayoría de los casos.

Programa 3:

| | |----| + |---------| / |------------------------------( )----| | I0 | I1 S0 | | | | | | | |----| |----| | | S0 | | |

El contacto ----| + |---- indica un contacto que se cierra por un scan con el flanco positivo de I0

Programa 4: otra posibilidad de evaluación de flanco de la entrada

| | |----| |---------| / |------| / |-------------------( )----| | I0 M0 | I1 S0 | | | | | | | |----| |----------------| | | S0 | | | | | |----| |--------------------------------------------( )----| | I0 M0 |

La evaluación de flanco se realiza agregando lógica que tiene en cuenta el concepto de ejecución cíclica

Prueba del software y del hardware 3:

4) Presionar y mantener presionada la botonera de arranque simulando una falla mecánica en esta, la salida S0 se debe activar y quedar activada; Presionar y soltar la botonera de parada, la salida S0 se debe desactivar y quedar desactiva [Si/No].

Vemos que el nuevo circuito cumple los requerimientos, o al menos cumple las pruebas con las que intentamos verificar los requerimientos.

Conclusiones:

Podemos aún encontrar mas fallas en el circuito, por ejemplo, no tenemos seguridad que el motor está girando, no tenemos seguridad que el contactor C realmente esté activado cuando actuamos la salida del PLC, la bobina del contactor puede tener una falla, un cable puede soltarse de una bornera, los fusibles de fuerza del motor pueden estar quemados o incluso no estar colocados. Nunca tendremos la seguridad completa aunque sigamos incluyendo más y más sensores cableados a entradas del PLC, los mismos sensores pueden fallar, es importante tener en cuesta los costos y no agregar seguridad no necesaria en hardware o en el software. Con el tiempo iremos incrementando la seguridad en software porque cada mejora puede ser aplicada sin costos o con bajisimos costos a nuevos o existentes proyectos. Podemos condiderar mejorado un software si tenemos en cuenta más combinaciónes de estados o flancos de las señales sí y solo sí realizamos pruebas para cada nueva mejora y volvemos a realizar todas las pruebas ya existentes para demostrar que la intención de mejora no modificó el correcto comportamiento de la totalidad del software. La realidad es que cada mejora puede implicar complejidad, la complejidad inicia cuando nuestras capacidades flaquean, por ello como desde tiempos inmemoriales cuando no nos son suficientes nuestras capacidades diseñamos herramientras y esas herramientas ya están diseñadas, entre ellas las especificaciones, las pruebas, las tablas de verdad, los diagramas de estado, los mapas de Karnaugh, el lapiz, etc.

Tabla de verdad

Mapas de karnaugh

Diagramas de estado

Operaciones lógicas con bytes

Vamos a ver ahora las operaciones lógicas aplicadas a bytes o conjuntos de bytes y una posible utilidad de las mismas. Supongamos que el cliente nos solicitó un sistema de alarmas para un tablero eléctrico existente, este tablero comanda una pequeña planta química que por la estabilidad del proceso requiere muy pocos automatismos, la misma estabilidad hace que el operador no necesite estar antento y pueda cumplir roles administrativos mientras opera, mas una eventual falla resulta en un largo tiempo con la planta detenida o funcionando fuera de régimen.

Descripción del sistema:

El sistema constará de un PLC con entradas y salidas booleanas, una sirena para alertar al operador, indicadores lminosos para indicar al operador el punto de falla y una botonera para callar la sirena cuando el operador haya tomado conocimiento efectivo del punto de falla. Las señales indicadoras de fallas provenientes de relevos térmicos, sensores de nivel con punto de alarma y sensores de temperatura con punto de alarma serán cableados al PLC. Los indicadores luminosos serán cableados al PLC. La sirena y la botonera para callar la sirena serán conectadas al PLC.

Requerimientos:

1) Cuando alguna de las señales indique un estado de falla en el proceso no presente en el instante anterior, el software del PLC deberá indicar este evento haciendo sonar la sirena. 2) Aún cuando alguna indicación de un estado de alarma en el proceso persista, el operador deberá poder callar la sirena presionando por un instante la botonera. 3) El indicador luminoso deberá estar encendido mientras la señal de alarma que le corresponda indique un estado de alarma. 4) El software deberá estar preparado para al menos 8 señales indicadores de fallas.

Programa 1:

| | |----| |--------------------------------------------( )----| | I0 S0 | | | | | |----| |--------------------------------------------( )----| | I1 S1 | | | | | | No muetra las otras 6 entradas e indicadores | | | | | |----| + |----------| / |-----------------------------( )----| | I0 | I8 S8 | | | | | | | |----| + |----- | | I1 | | | | No muesta las otra 6 entradas |

Ejercicio:

Mejorar el programa para que si una alarma aparece mientras la botonera de parada está presionada, igualmente el software haga sonar la sirena.

Ejercicio:

Realizar el mismo software utilizando compuertas.

Ejercicio:

Realizar los dos software anteriores utilizando operaciones lógicas con bytes.

Ejercicio:

Modificar el programa del ejercicio anterior utilizando operaciones lógicas con words.