En esta ocasión revisaremos el simulador de semáforo dentro del software “LogixPro 500” de Allen Bradley (actual filial de Rockwell Automation). A primera impresión resulta extraño y quizá ilógico pensar en que se pueda adquirir un PLC y realizar su instalación y puesta en marcha para un par de luces secuenciales, sin embargo, este ejemplo trata de tener un carácter didáctico donde aprenderemos una forma de realizar activaciones secuenciadas de distintos elementos de campo, esto podría transponerse en algún proceso donde se lleve la cuenta de elementos o, que como veremos a continuación, que su activación dependa de un temporizador.
Descripción del sistema
 |
Fig. 1: Simulador de luces de tráfico (semáforo) |
Como podemos observar en la ilustración anterior, el sistema a resolver resulta muy sencillo, sin embargo, hay un par de consideraciones que nos llevarán a proponer una solución. Uno de estos detalles son las casillas de verificación (también llamadas “checkbox”) con la leyenda “Park”, las cuales, al ser marcadas, evitarán que el transito fluya en ese sentido, es decir que, podemos tener un cruce sin autos, un cruce en un sentido o bien una intersección. Además de esto, podemos observar que un par de entradas del sistema corresponden a botones que servirán a los peatones para solicitar el cruce.
Considerando lo anterior, en esta ocasión vamos a proponer las siguientes tres soluciones:
- Semáforo para un solo sentido de cruce
- Semáforo de dos sentidos
- Semáforo de dos sentidos con interrupción peatonal
Si desarrollamos la solución en ese orden encontraremos un avance progresivo de tal forma que evitaremos realizar cambios drásticos a la solución previa.
Empezamos identificando las variables del sistema:
| Entradas | Salidas | Variables de estado | Timers |
| Cruce Izq I:1/00 | Luz roja izq O:2/00 | Control izq B3:00 | Timer maestro T4:00 |
| Cruce Der I:1/01 | Luz amarilla izq O:2/01 | Control der B3:01 | Timer solicitud T4:01 |
| Sensor Izq I:1/02 | Luz verde izq O:2/02 | Timer izq T4:02 | |
| Sensor Der I:1/03 | Ind peatonal izq O:2/03 | Timer der T4:03 | |
| Luz roja der O:2/04 | |||
| Luz amarilla der O:2/05 | |||
| Luz verde der O:2/06 | |||
| Ind peatonal der O:2/07 |
Semáforo de un solo sentido
Nuestra propuesta inicia con un timer que será el maestro del sistema y el accionamiento secuenciado de las luces dependerá de la acumulado que lleve. Cabe resaltar que, considerando que estamos utilizando el software LogixPro, no es posible cambiar la base de tiempo, por este motivo utilizaremos décimas de segundo, además de que esto permite tener una mejor resolución en el conteo temporal que realiza el software. Sin embargo, en plataformas de desarrollo equivalentes como RSLogix 500, Studio 5000, TIA Portal o KV Studio y dependiendo de nuestro controlador; podremos cambiar dicha base hasta milisegundos.
 |
| Fig. 2: Reloj maestro del sistema. |
En este caso opté por un preset de 25 segundos para que la activación y desactivación de las luces tenga un carácter más realista pero fácilmente puede ser cambiado por cualquiera que resulte de su preferencia.
Los siguientes tres peldaños de nuestro diagrama ladder corresponden directamente a la activación de la luces y, como podemos apreciar en la imagen siguiente, se utilizan comparadores del tipo “LIM” (o límite) para definir un rango de valores que deberá cumplir el acumulado del reloj maestro para realizar dicha acción.
 |
| Fig. 3: Activación de las luces izquierdas. |
En este caso definimos el siguiente patrón de activación:
| Luz verde | Luz amarilla | Luz roja |
| 8 segundos | 4 segundos | 13 segundos |
Algo a destacar es que, estrictamente, las etapas no cumplen el tiempo mencionado anteriormente pues se considera la adición (o substracción) de una décima de segundo con la finalidad de que el sistema no active dos luces al mismo tiempo, quizá para la percepción humana esto puede ser interpretado de forma correcta en torno a la secuencia típica de un semáforo, sin embargo, el controlador no tiene esa capacidad de razonamiento y puede llevar a errores en el simulador, además de que, al transponer este tipo de soluciones a otros procesos, resultaría en errores de interpretación de indicadores por parte del PLC en cuestión. Cabe resaltar que este problema podría ser solucionarse mediante la utilización de otro tipo de comparadores como son “mayor o igual que”, “mayor que”, “menor o igual que” y “menor que” (GEQ, GRT, LEQ y LES; repectivamente), sin embargo, mantendremos la instrucción LIM por ahora.
Finalmente, solo queda hacer un reset al reloj principal cuando termine su cuenta para otorgar un carácter cíclico a nuestro sistema.
 |
| Fig. 4: Reset del reloj maestro. |
Semáforo de dos sentidos
Como mencioné anteriormente, la idea de esta solución progresiva consiste en ligeros cambios a nuestra propuesta anterior, por lo que, para poder resolver la intersección solo bastará con agregar tres peldaños más a nuestro diagrama Ladder donde los comparadores de tipo LIM estarán intercalados con la secuencia anterior.
 |
| Fig. 5: Secuencia de actuación para luces de la derecha. |
Un detalle que salta a la vista es que existen dos condiciones de encendido para la luz roja derecha, esto se debe a que, en ciertas ocasiones, cuando un auto está circulando y en el otro sentido hay otro auto esperando el cruce, éste último comenzará su movimiento sin importar que el primero esté a la mitad de su recorrido.
 |
| Fig. 6: Accidente ocasionado por activación inmediata de luces contrarias. |
Después de lo anterior, el reset del reloj principal mantiene las mismas condiciones.
 |
| Fig. 7: Reset del reloj maestro. |
Semáforo de dos sentidos con interrupción peatonal
Si bien hemos mantenido una estructura similar en nuestro programa, la propuesta que se hace a continuación cambia ligeramente los peldaños definidos anteriormente pues se agregan timers y variables de estado que servirán como indicadores cuando un peatón solicite el paso. En este caso, no se interrumpirá la secuencia principal pero sí las condiciones de encendido de las luces en caso de presentarse la solicitud mencionada anteriormente.
Nuevamente iniciamos con el reloj maestro que definirá la secuencia principal de activación:
 |
| Fig. 8: Reloj principal. |
Procediendo con las luces del paso izquierdo, notamos que aparece una condición adicional que el la variable “TT” de otro reloj, que será definido en peldaños siguientes. Su presencia significa que la activación se realizará (o no se realizará) cuando dicho timer esté realizando un conteo temporal:
 |
| Fig. 9: Condiciones de activación para luces izquierdas. |
De una forma similar, definimos las condiciones para realizar la activación de las luces del sentido derecho, las cuales estarán sujetas al conteo del timer maestro y de un timer adicional:
 |
| Fig. 10: Activación de las luces del sentido derecho. |
A continuación, aparecen las condiciones para la solicitud del paso peatonal. Se empieza con un enclavamiento cuando se detecta que el peatón presiona el botón para solicitar el cruce, en este caso utilizamos las instrucciones “Latch”.
 |
| Fig. 11: Enclavamiento al recibir la pulsación del peatón. |
Seguido de esto, arranca un timer con un preset de 1.5 segundos, tiempo empleado para cambiar el estado actual de la luz del semáforo (típicamente la luz verde) a luz roja, ésta permanecerá encendida durante otros 5 segundos para que el peatón pueda cruzar.
 |
| Fig. 12: Timers para cruce peatonal. |
Finalmente, agregamos condiciones de reset para el reloj principal (el cual se ha mantenido igual a lo largo de las distintas soluciones que hemos desarrollado) y para los relojes de cruce, además de que dichas condiciones son utilizadas para regresar a su valor inicial a las variables de estado:
 |
| Fig. 13: Reset de relojes y final del programa. |
En el siguiente vídeo podemos observar el funcionamiento del sistema:
Conclusiones
A lo largo de las soluciones propuestas pudimos comprobar que, a través de cambios graduales, podemos incrementar el alcance de nuestro sistema y aunque el controlador del que dispongamos se vea limitado en cuanto a poder de procesamiento o memoria, siempre hay una alternativa a la forma en que visualizamos la información, tal fue el caso de la base del tiempo en los timers utilizados.
Retomando el caso de los timers y ligándolo con las instrucciones “LIM”, debemos tener en cuenta la forma en que el controlador interpreta la programación pues, como mencioné en el primer caso, si llega a presentarse un cruce en los indicadores o alarmas de un sistema, puede tener consecuencias muy graves para el equipo o, peor aún, para los usuarios.
Por último, estoy consiente de que las propuestas que realicé aquí no son las solución definitiva a este sistema y es que, además de no haber utilizado los sensores de autos, existen un sinfín de posibilidades para dar respuestas alternativas como pueden ser el uso de subrutinas, el uso de otro tipo de comparadores o incluso reducir los tres timers de cruce a uno solo, sin embargo, preferí manejarlo de esta forma por un carácter didáctico que, espero, resulte más sencillo de entender.
¡FELIZ DÍA DEL INGENIERO! (en México)
-AHN
0 Comentarios