Una vez resuelto el "Software de detección " he conseguido que el programa de control, se entere de cuándo una locomotora pasa sobre uno de los sensores colocados en la vía. Pero claro, eso no es todo; ahora hay que saber que es lo que tiene que hacer el programa de control cada vez que recibe la información de uno de estos sensores.
Tradicionalmente, en una maqueta analógica, el paso de un tren sobre un detector de paso, provoca la actuación de uno o más relés que abren y cierran la alimentación de determinados circuitos, Esto puede provocar el cambio de luces de determinados semáforos, o mover relés que dejan determinados sectores de vía aislados o conectados a la alimentación. En el sistema analógico (y también en muchos sistemas digitales) esta actuación es puramente electromecánica, lo cual significa que el que un determinado relé o un determinado semáforo haga una determinada función al cerrarse el contacto de un detector depende la unión física mediante cables eléctricos entre los sensores los relés y los semáforos.
Hasta la aparición de los sistemas digitales no había otra opción, de manera que los aficionados tenían que resignarse a dos limitaciones: La primera es que en cuanto la instalación se complica un tanto, el cableado resultante es muy complicado, lo cual no sólo resulta penoso para construirlo inicialmente, sino que complica extraordinariamente cualquier modificación. La segunda es que este cableado establece de forma fija un comportamiento determinado del sistema, de modo que resulta imposible que el sistema responda alternativamente de una u otra forma, por ejemplo en función del tren que circula o a opción del modelista. En algunos casos puede incluirse alguna posibilidad de opciones alternativas, a base de conmutadores, pero siempre de forma limitada y a costa de bastante complicación
Fig 1 - Cableado de un bloqueo automático analógico |
La figura anterior recoge el cableado necesario para establecer un sistema de bloqueo automático. Realmente solo se recoge una parte correspondiente a tres cantones consecutivos. Se emplea un sector de vía aislado a la entrada de cada cantón, que se alimenta a través de los contactos de un relé biestable asociado a cada cantón.
Con la aparición de los sistemas digitales, esta "lógica cableada" puede sustituirse por una "lógica programada" Es decir, el sistema digital recibe las señales de los sensores y produce las órdenes de actuación. Las ventajas de hacerlo así están en los siguientes aspectos:
El cableado es simple ya que solamente hay que unir cada sensor, semáforo, etc a los terminales de la interfase con el sistema digital. Este cableado es bastante simple pero sobre todo es universal, es decir en ningún caso hay que modificarlo para realizar cualquier cambio. Una ampliación no supondrá más que añadir más cables de unión entre los nuevos aparatos de vía y la interfase digital
Fig 2 - Cableado de un bloqueo automático con mando por ordenador |
La figura anterior es un esquema muy genérico de lo que sería el cableado de un bloqueo automático manejado por un programa de control, en contraposición a la figura anterior para un sistema analógico: En primer lugar hemos suprimido los sectores aislados de la vía, puesto que el mando digital es el encargado de parar y arrancar los trenes ante las señales. La vía se alimenta desde una central digital conectada al ordenador. Por otra parte los sensores colocados al inicio de cada cantón, envían sus señales a una interfase que también se une al ordenador. En un sistema digital standard esta interfase está constituida por el conjunto de retromódulos S88. En mi sistema esta intefase es el CODIF32. Los semáforos, se conectan también directamente a la interfase electrónica. En mi caso son los circuitos DEMU02 y DEMU04, y en los sistemas comerciales son los decoders de accesorios. Como se ve, básicamente el cableado es más simple que en el caso analógico, pero sobre todo, como decía, ese cableado es capaz de llevar a cabo cualquier función que el ordenador envíe al sistema.
En el momento en que entra en juego un programa de control por ordenador las posibilidades se amplían de forma extraordinaria: no solamente es posible definir distintas posibilidades de funcionamiento sino hacer actuar unas u otras Pero claro, cuantas más posibilidades y opciones tenemos más complicado es definirlas.
No me considero ni mucho menos conocedor de los programas comerciales de control de maquetas, y de hecho, jamás he manejado uno, y apenas he visto funcionar alguno en alguna reunión de aficionados. Puede sorprender que me haya lanzado a desarrollar un programa de control, sin un previo conocimiento de la competencia, pero este es mi estilo, y en general prefiero resolver los problemas de la forma que me parece más lógica, sin dejarme llevar por ideas previamente adquiridas. Lo que si he leído han sido muchos mensajes en los foros relativas a los problemas que los aficionados encuentran con estos programas, y he llegado a la conclusión de que los mayores problemas están precisamente en este punto, en que el usuario debe definir qué debe hacer el programa en función de las señales que recibe. Asi que oigo hablar de schedules, de itinerarios, de rutas, de tramos, y discutir de las ventajas de unos programas respecto de otros y leo las complicadas soluciones que se dan a las preguntas sobre estos temas. La conclusión es que este tema es conflictivo y que cada programa ha adoptado una solución diferente, lo cual indica que no hay una solución perfecta.
Como por otra parte mi programa tiene que contemplar una serie de características que estos programas no contemplan, derivadas de la circunstancia de mantener el control analógico de las locomotoras, llego a la conclusión de que lo mejor es que invente mi propio sistema, basado en lo que tengo y en lo que quiero, y tratando hacerlo de una forma lógica sencilla y consistente.
Así que he organizado mi sistema en base al concepto de "Ruta" Considero que cuando un tren circula por la maqueta, lo hará siguiendo una determinada ruta. Otro tren puede estar circulando al mismo tiempo siguiendo la misma u otra ruta. Una ruta puede ser cerrada o abierta. Si es cerrada, el tren podrá recorrerla idefinidamente. Si es abierta, habrá un punto en que el tren llegue al final y se detenga. Cuando un tren circula por una ruta determinada, va pasando por una serie de sensores que en el programa se denominan "balizas" La definición de una ruta consiste en definir qué acciones debe ejecutar el programa para cada una de las balizas que el tren encontrará en su camino. Esta definición debe ser completa, es decir se debe decir qué hacer para cada baliza que el tren encuentra (aunque la acción sea no hacer nada). Si el sistema detecta que el tren ha pasado sobre una baliza que no está en su ruta, se considera que el tren está fuera de su ruta y se produce una alarma,
Así que el primer trabajo ha sido incorporar al programa una forma de definir las rutas. Para ello he programado una nueva ventana que permite crear rutas, asignarles un nombre, y definir las acciones a realizar.Es una ventana muy complicada desde el punto de vista de la programación, ya que admite un número indefinido de rutas, cada una de ellas con un número indefinido de pasos, y con la posibilidad de insertar, suprimir, modificar, borrar etc. Y naturalmente que todos estos datos se conserven en la base de datos del sistema.
En la imagen de cabecera, se ve esta ventana abierta por el programa sobre el esquema del trazado de vías, y en la imagen previa a estas líneas, vemos la imagen ampliada.
Como vemos, esta ruta se llama "Circuito principal", ya que recoge el recorrido que hacen los trenes por mi maqueta cuando circulan indefinidamente por el circuito más largo posible. En mi maqueta cuando un tren recorre este circuito pasa sucesivamente por los cantones 1, 2, 3, 5 y 6. En la entrada de cada uno de estos cantones hay (habrá) una baliza que se denominan B01, B02, B03 ,B04 y B05 y un semáforo que denominan F01, F02,F03, F04, y F05 Nótese que aunque los nombres los he escogido con un poco de lógica, los códigos de las balizas de los cantones 5 y 6 no corresponden exactamente. En realidad es indiferente y los nombres podrían ser cualesquiera.
Bueno, pues en esa pantalla vemos la programación más simple posible de esa ruta: en la línea 1 le decimos al sistema que cuando el tren active la baliza 1, ponga en rojo el semáforo F1, y también en la linea 2, con la baliza B1 se pondrá verde el semáforo F5. Así sucesivamente, de manera que tenemos el típico esquema de señales que se ponen en rojo cuando el tren entra en un cantón y se ponen en verde cuando entra en el cantón siguiente. Podemos decir que esta programación es el reflejo informático del cableado representado en la figura 1. Esta es la "lógica programada" en contraposición a la "lógica cableada" de aquella figura.
Como se puede ver, hay muchas casillas en blanco en esa pantalla, y eso es porque no es obligatorio rellenar más que la columna de Baliza y Acción. En próximos artículos veremos más posibilidades.
Pero solo con estos datos ya tendríamos un funcionamiento automático de los semáforos, Adviértase que muchas maquetas, sobre todo del otro lado del Atlántico son manejadas de forma manual, es decir, es el operador el que debe detener manualmente los trenes ante las señales, y arrancar cuando se ponen en verde. Para manejar así mi maqueta, ya tendría suficiente con esa programación.
Sin embargo el programa tiene muchas más posibilidades, incluyendo la que justifica el que le llame a esto una "ruta". Veamos el ejemplo siguiente:
Se observará que hemos insertado dos líneas más (la 3 y 4) para la misma baliza B01 de la que ya teníamos la 1 y la 2. Aquí la orden es "D02 Curva" es decir, poner el desvío D02 en posición curva. Lo mismo en la línea siguiente para el desvío D03. Análogamente en las lineas 9 y 10 vemos como se ordena a los desvíos D41 y D14 que se pongan en posición recta.
En definitiva, cada vez que el tren entra en un cantón, ordena a los desvíos que hay en ese cantón que se sitúen en la posición prevista para que el tren recorra la ruta programada. No se trata tan solo de mover los semáforos, sino también de mover automáticamente los desvíos.
No es mi intención hacer una descripción detallada de todo el funcionamiento del programa, y concretamente de la forma de definir las rutas, porque eso solo tendría objeto para personas que vayan a manejar el programa. Pero he querido extenderme un poco sobre este tema porque me parece que es una filosofía clara sencilla y suficientemente potente para el propósito deseado.
Muy interesante el contenido, gracias.
ResponderEliminarTe invito a pasar a mi web: OK Hosting