ESTE BLOG COMENZÓ A PUBLICARSE EN 2008, POR LO TANTO MUCHOS DE LOS TEMAS HAN QUEDADO DESACTUALIZADOS U OBSOLETOS. LOS LECTORES QUE DESEEN UTILIZAR ALGUNO DE LOS ELEMENTOS AQUI DESCRITOS DEBERÏAN ASEGURARSE DE BUSCAR LAS REFERENCIAS MAS MODERNAS DE LOS TEMAS DE SU INTERÉS. EL BUSCADOR INCLUIDO SERÄ UNA AYUDA PARA ESA BÚSQUEDA

jueves, 30 de mayo de 2013

Mousecab




En mi último artículo, anticipé que estaba pensando en construir un mando portátil al estilo Multimaus, para manejar manualmente los trenes, con la posibilidad de alejarme del puesto de control.

Así que, dicho y hecho: la imagen de la cabecera muestra el aspecto de este elemento que he construido y al que le he dado el nombre de "Mousecab" . Evidentemente el nombre proviene de que tiene el aspecto de un "mouse" y emula la función de una Cabina de control de mi programa.

Como se puede ver, en la parte inferior hay tres pulsadores, en colores verde, negro y rojo que realizan las funciones de Adelante, Paro, y Atrás, duplicando así los botones "virtuales" que aparecen en la pantalla de la Cabina. Además, por supuesto, hay un mando giratorio que regula la velocidad del tren, y que como veremos en el vídeo, su movimiento se refleja en el control de velocidad de la ventana de la cabina.

En la esquina superior derecha hay un display que muestra el número de la cabina sobre la que está actuando el Mousecab. Evidentemente podemos cambiar la conexión a cualquier otra cabina, pulsando el botón de "Manual" en la Cabina. El cambio se señaliza en la pantalla porque el número de cabina pasa de verde a rojo, y en el Mousecab porque el display muestra, el número de cabina al que se ha conectado. (¡Para esto era el número de cabina  grande que puse recientemente en la esquina superior derecha!)

Hay un botón azul, previsto ara actuar sobre un desenganchador, y facilitar así las maniobras, pero todavía no he modificado el software para que los desenganchadores obedezcan a este botón.

Técnicamente es relativamente sencillo, ya que me he limitado a seguir la misma técnica usada en el resto de controles y sensores de la maqueta. Por ejemplo, los cuatro botones funcionan exactamente igual que las balizas que detectan el paso de los trenes. Al pulsar uno de los botones se pone a masa una entrada de un circuito multiplexor, en este caso un 74HC148 que envía un código de tres dígitos a la entrada de una de las placas Velleman que se encarga de transmitir esta señal al ordenador. El programa está haciendo polling sobre esa entrada, de manera que cuando se reconoce un dato el programa lo detecta y sabe cómo actuar. Es el programa el que sabe sobre qué cabina hay que actuar en cada momento, ya que el dispositivo es "tonto"; se limita a decir, por ejemplo se ha pulsado el botón 3 y todo lo demás, es decir que función hay que hacer sobre qué cabina, es por software.

Análogamente, la visualización en el Mousecab del número de cabina sobre la que actuará en cada momento, es fundamentalmente por software, de manera que es el programa el que controla que cabina está conectada al mouse en cada momento, si es que hay alguna conectada. Así que el programa produce una señal permanente (tres bits) que se envía a la misma placa Velleman y que genera en la salida la señal correspondiente, que se lleva hasta el Mousecab. Como sólo envío tres bits el display sólo puede visualizar los dígitos 0 a 7, de modo que el 8 y el 9 no pueden aparecer. Realmente no los necesito, porque el máximo número de cabinas en mi programa es de 6, correspondientes a los seis controladores PWM que tengo instalados. Podía haber previsto los cuatro bits que se necesitan para mostrar el 8 y el 9, pero al ahorrarme un bit he podido utilizar cables y conectores de 9 vías, es decir, he utilizado los cables y los conectores que se emplean (más bien se empleaban) para las conexiones por puerto serie de los ordenadores.

La imagen siguiente muestra el aspecto del circuito que he montado, en vista frontal y trasera. En la cara delantera  vemos los tres circuitos integrados que lleva, y que son el multiplexor 74HC148, que ya he comentado, el decodificador 75HC4511 que genera las señales para los siete segmentos del display, y un inversor  74HC14, porque como siempre la señal que generan las placas Velleman está invertida.

 
En la cara posterior se aprecia que se trata de un circuito impreso bastante compacto, pero ha quedado de un tamaño muy apropiado, como para meterlo en un caja que cabe en la mano cómodamente.
 
En el vídeo que aparece a continuación vemos las primeras pruebas de este elemento. Inicialmente vemos como los controles que se visualizan en la pantalla del ordenador responden a los movimientos de los mandos del mouse. Realmente, es curioso este efecto, porque salvo el ratón, no estamos acostumbrados a ningún dispositivo que interaccione de esta forma con la pantalla del ordenador. Luego vemos ya como manejamos un tren con el Mouse y realmente se hace una buena demostración de movimientos lentos del tren que aparece en la imagen.
 



Y ahora voy a contar una historieta, que ha sido la que mayores quebraderos de cabeza me ha dado en todo este tema. El mando giratorio que tenemos en el centro y con el que manejamos la velocidad, no es un potenciómetro, sino un encoder. Concretamente lo que se llama un encoder incremental mecánico. Ya en mi artículo Encoder mencionaba yo, que esta palabra se empleaba también para designar unos dispositivos que detectan la posición o al menos el giro de un eje.
 
Efectivamente este es un dispositivo que tiene tres terminales, de los cuales el central es de masa, y los otros dos se conectan a masa momentáneamente según el eje gira, de manera que si movemos el eje constantemente se producen una serie sucesiva de puestas a masa, en definitiva de impulsos, que se pueden llevar a un dispositivo que los interpreta y actúa en consecuencia.
 
Mi problema fue que pensé que girando el mando en un sentido se producían estos contactos a masa en uno de los terminales, y girando en sentido contrario, se producían en el otro terminal. Hice una prueba rápida con un polímetro y me convencí de que así era, pero debió ser una prueba demasiado rápida, porque me llevó a engaño. Lo malo fue que diseñe y construí todo el aparato con esta idea.
 
Así que cuando lo probé, me encontré con que no funcionaba como yo esperaba. Después de unas cuantas pruebas y de investigar por Internet, me enteré que estos elementos funcionan de la siguiente forma:  Cuando el eje gira, se producen en efecto, puestas a masa de los terminales, pero tanto si giramos en un sentido como en otro, se producen en ambos terminales. La diferencia está en que una de las series de "puestas a masa" está desfasada respecto de la otra, de modo que girando en un sentido la serie del terminal 1 va por delante de la del terminal 2 y girando en sentido contrario, la serie del terminal 2 va por delante.
 
La verdad es que me parece una cosa supercomplicada, y parece ser que la razón está en que el origen de estos aparatos está en elementos industriales destinados a controlar el movimiento de un eje que gira. Si leemos solamente uno de los terminales tendremos una serie de pulsos, ya sea el giro en un sentido o en otro, y sólo con ese dato ya podemos calcular la velocidad. Si además queremos conocer el sentido, entonces leemos el segundo terminal y por el desfase conocemos el sentido. Vale, pero eso es correcto para decoders industriales que se conectan al eje de una maquinaria, y que por cierto no son mecánicos sino ópticos o magnéticos. Pero cada vez se emplean mas estos decoders mecánicos en sustitución de los potenciómetros, fundamentalmente porque su salida es de tipo digital, con lo cual se adaptan mucho mejor a la tecnología digital. No se si existen decoders mecánicos que funcionen como yo pensaba, pero me parece que no, así que he tenido que pensarme cómo utilizaba esa complicada señal para saber algo tan sencillo como el determinar el sentido de giro del mando.
 
 

 
En la figura previa, vemos el tipo de señal generada por uno de estos encoders según se hace girar el eje. La señal A es la que aparece en uno de los terminales, y la B la que aparece en el otro terminal. Si el eje gira en un sentido las señales aparecen tal como las vemos leyendo de izquierda a derecha, así que la señal B está retrasada respecto de la A. Si giramos al revés es como ver la imagen de derecha a izquierda, así que la señal A es la retrasada respecto de B.
 
Lo que he hecho es considerar estas dos señales como dos dígitos de un código binario, siendo la A el bit más bajo y el B el más alto. Así que si empiezo a girar el mando en un sentido, se genera la secuencia de códigos binarios 00  01  11  10  00  01  11  10  00 ........... o bien si lo expresamos en decimal, la secuencia es 0 1 3 2 0 1 3 2 0 ..............
 
Por el contrario si lo hacemos girar en sentido inverso, la secuencia que se genera es 0 2 3 1 0 2 3 1 0...
 
Como estoy haciendo la lectura por polling, voy haciendo lecturas con una frecuencia dada y comparo cada lectura con la anterior. Si ha habido un cambio de valor, determino cuales son losvalores consecutivos leídos. De modo que si las parejas de valores consecutivos leidos es una de estas: 0-1  o 1-3  o  3-2  o 2-0  está claro que se está generando la primera de las secuencias, así que el mando está girando hacia la derecha. Por el contrario si leo cualquiera de las siguientes parejas de valores consecutivos: 0-2  o  2-3  o  3-1  o  1-0  será porque se está generando la segunda secuencia, así que el mando está girando hacia la izquierda.
 
Naturalmente si la lectura del polling es mucho más lenta que la frecuencia con la que cambian los valores, se perderán muchos valores intermedios, con lo cual el método deja de funcionar. Lo malo de esto, es que la frecuencia de los valores depende de lo deprisa que se gire el mando, así que si giramos el mando muy rápidamente la frecuencia supera la del polling y se pierden lecturas.
 
Afortunadamente he podido comprobar que con una frecuencia de polling de 15 milisegundos y moviendo el botón con calma el sistema funciona muy bien, tal como se comprueba en el vídeo. No tiene sentido mover rápidamente el mando porque eso supondría querer cambiar la velocidad de la locomotora de una forma excesivamente rápida.
 
De modo que al final he salido airoso de mi primera incursión en el mundo de los decoders. Pienso que posiblemente haya algún tipo de circuito integrado que interprete las señales del decoder y presente una salida más tratable, pero desde luego yo no lo he encontrado.
 
 

lunes, 20 de mayo de 2013

Nuevo vídeo




Hoy he subido otro vídeo a YouTube, y lo he colocado como cabecera de este artículo. En realidad no hay ninguna novedad respecto del anterior, pero es un vídeo de mucha mejor calidad que los anteriores, tanto en el aspecto estético como en el técnico, ya que hay tomas variadas desde varios puntos de vista de los trenes, y los detalles de las imágenes del programa de ordenador se ven con gran claridad.

Esto indica algo importante, y es que cuando lo grabé, me pude dedicar por completo al vídeo, buscando los mejores ángulos y moviéndome alrededor de la maqueta mientras los dos trenes funcionaban. Esto es la muestra palpable de que los trenes están funcionando solos sin requerir ninguna atención, y realmente funcionaron continuamente durante todo el tiempo que estuve dedicado a grabar el vídeo sin que se produjera ningún alcance ni ningún otro problema. Asi que el sistema está funcionando "como un reloj"

Aparte de las tomas de los trenes, he incluido también unas imágenes de detalles de la pantalla del ordenador, captados en video durante el funcionamiento, con un programa de captura de pantallas. Ya había utilizado muchas veces este programa de captura de imagen de pantalla, pero últimamente estaba teniendo graves problemas. La razón no es otra que este programa, cuando graba la totalidad de la pantalla, sobre todo de una pantalla de 1920 x 1080 pixels como la que tengo ahora, se apodera de los recursos del ordenador de tal forma, que el programa de control de trenes empieza a ralentizarse, y a perder información, con lo que se puede grabar una preciosa catástrofe.

He descubierto que ese programa, en vez de grabar toda la pantalla puede grabar solo una zona, y en esas condiciones si que se puede grabar vídeo mientras el programa de control funciona. Naturalmente en todo esto entra en juego la poca capacidad del ordenador que utilizo, que es poco más que un juguete.

Bueno, después de todo eso, he conseguido grabar algunos detalles de zonas de la pantalla funcionando y he incluído unas rotulaciones que indican lo que estamos viendo. En particular hay una toma donde vemos el "log de mensajes", es decir una ventana, que normalmente no está visible, pero en la que van apareciendo con una serie de mensajes la indicación de todas las acciones que realiza el programa. También vemos detalles de la pantalla principal con el trazado de vías, en la que vemos las etiquetas que indican el paso de los trenes por las distintas balizas, y al final vemos una de las ventanas de una Cabina, en la que se aprecia muy bién el funcionamiento de la conmutación de cantones.

Como conclusión de todo esto, la situación actual es que el hardware funciona perfectamente, por lo que lo doy por concluído, con sólo dos reservas que luego comentaré. Por lo tanto ha llegado el momento de poner a disposición de los interesados el diseño de los circuitos electrónicos que he construido y que a partir de ahora podrán descargarse desde la página de Descargas de este blog, o directamente en este Enlace.

Además hay también una explicación completa y detallada de cuales son los principios de funcionamiento del sistema, de manera que se tiene una explicación ordenada  y concreta de todo el sistema, sin necesidad de leer una serie de artículos de este blog que se han publicado a lo largo de muchos meses. El enlace para esta descripción del sistema está en este Enlace.  Todos estos documentos son accesibles también desde mi Página Web.

Decía antes que doy por terminado el hardware con alguna reserva. La primera es que he notado que los reguladores de tensión que están montados en disipadores de calor en la placa CABCON00 se calientan bastante. El problema es que si se calientan con dos trenes circulando, si hago funcionar más trenes simultáneamente se calentarán más, asi que es posible que tenga que utilizar disipadores mayores, o incluso poner un ventilador. Lo malo es que el diseño de la placa está hecho contando con esos disipadores y no me hace ninguna gracia tener que rediseñar y construir una nueva versión de esta placa por este tema.

La otra reserva es un tema recurrente: En algunos artículos he hablado de la posibilidad de tener un mando manual para manejar los trenes, es decir una especie de consola, con mandos mecánicos que permitiera manejar los trenes girando estos mandos en lugar de tener que usar el ratón sobre la pantalla del ordenador. Casi todo el que tiene un sistema digital y ha conectado un ordenador a la central digital, continúa manejando los trenes con los mandos mecanicos de la central, en lugar de actuar sobre la pantalla del ordenador con el ratón, porque resulta más cómodo.

Cuando compré el gran monitor (Vease Puesto de Mando) quedé tan impresionado de la imagen que obtenía, y de la facilidad de manejo que esto me aportaba, que decidí que no necesitaba ninguna clase de mando mecánico. De paso me di cuenta que la rueda del ratón podía actuar como mando mecánico sin hacer nada especial, simplemente porque el control slider de Visual Basic que utilizaba en las Cabinas para controlar la velocidad, responde al giro de esa rueda del ratón.

Sin embargo, luego me he dado cuenta de que en muchas ocasiones puede venir bien tener un mando manual, sobre todo un mando portátil, al estilo de un Multimaus, que me permita desplazarme con el mando en la mano, y manejar un tren manualmente desde una posición muy cercana, por ejemplo si estoy haciendo maniobras con desenganches. No es exactamente lo que yo había pensado inicialmente, que era algo asi como una central digital fija y con mandos para controlar dos o incluso más trenes manualmente. La nueva idea es una pequeña caja, que pueda llevarse en la mano, y con ella manejar no solo la velocidad, sino el sentido de movimiento, y también activar un desenganchador, de modo que se tenga en la mano todo lo que se necesita para hacer maniobras, y poder situarme con este mando en una posición muy cercana al tren que estoy manejando. Este "telemando" podría asociarse a cualquiera de las Cabinas, de manera que cuando lo asociamos a alguna de ellas, pasamos a manejar el tren desde el mando en vez de actuar sobre los controles de la Cabina en pantalla.

No es algo elemental, porque se trata de construir un "periférico" para el ordenador que incluya una serie de mandos y controles que al accionarlos actúen sobre controles del programa, lo mismo que hacemos con un ratón cuando clickamos sobre un botón en la pantalla. No es fácil como digo, porque hay que resolver no sólo la parte de hardware sino el software que consiga que los controles de Visual Basic obedezcan a este nuevo periférico, conectado por USB, pero creo que tengo la forma de hacerlo.


jueves, 16 de mayo de 2013

Lo que faltaba






El vídeo que encabeza este artículo, es el que faltaba: Seguramente los que siguen este blog se habrán dicho más de una vez: Pero bueno, ¿cuándo vamos a ver el sistema de Ignacio funcionando con varios trenes? La respuesta es: HOY.

Efectivamente, los que ya me conocen, se habrán dado cuenta de que siempre voy avanzando pasito a pasito y normalmente avanzando en paralelo el hardware con el software. Así, que hasta ahora, todas las pruebas que he efectuado han sido siempre con un solo tren, por la razón de que hasta que no funcione todo perfectamente con un solo tren, es inútil meter dos, porque ante cualquier problema es mucho más difícil localizar dónde está el fallo.

Hasta hoy no me he convencido de que el sistema funcionaba perfectamente con un solo tren, y entonces me he atrevido a meter dos. La diferencia es notable, porque naturalmente un solo tren puede funcionar ininterrumpidamente, pero al meter dos tiene que actuar el sistema de acantonamiento para evitar que los trenes se alcancen.

Menos mal que he actuado con esta prudencia, porque efectivamente al meter dos trenes, han empezado los fallos, y concretamente uno que se producía en la asignación de cantones y que me ha vuelto loco, porque el programa hacía lo que debía, pero la conmutación de cantones no funcionaba de forma correcta. Esto me preocupó mucho porque pensé que el problema podía estar en el hardware y pensar ahora en volver a tocar en los circuitos electrónicos después de haber funcionado más de un mes sin detectar fallo alguno, me daba pánico.

Afortunadamente me he dado cuenta de que el problema era de software y aunque el programa actuaba como debía, la orden que salía hacia las placas de comunicaciones producía un código erróneo, que naturalmente el hardware ignoraba. Es curioso que este fallo no haya salido hasta ahora, pero es que solo se producía cuando un tren quedaba en espera a que el siguiente cantón quedase libre, circunstancia que naturalmente no se da con un solo tren.

En fin, que después de detectar y corregir el fallo TODO ha empezado a funcionar como debiera, y pongo TODO con mayúsculas porque es increíble la cantidad de cosas que tienen que funcionar bien para que el resultado sea el esperado. Por supuesto está todo el software, tanto el de control como el de comunicaciones, el sistema de control de aparatos de vía, que es el que mueve los semáforos y los desvíos, el sistema de detección de trenes, que es importantísimo para tener localizada cada locomotora y detectar los pasos por las balizas, y por supuesto el sistema de conmutación, el famoso EPCC.

Hay algo que no me creo ni yo, y es lo bien que funciona todo el tema de hardware. Como ya comenté todo el sistema está en la balda en cuya parte frontal está el monitor, de modo que para tener acceso a toda la parte electrónica hay que quitar el monitor. Bueno, pues hace más de un mes que el monitor no se ha movido de su sitio, así que todos esos circuitos y todos sus leds encendiéndose y apagándose deben seguir allí, pero yo hace mucho que no los veo. Como decía, hoy he estado a punto de meterme en ese tema, pero al final ha sido innecesario. De hecho el error me ha convencido de que el hardware estaba haciendo lo que debía hacer ante una orden que era errónea.

Así que en el vídeo vemos dos trenes circulando, cruzándose y esperándose en los semáforos, algo que tampoco resulta especialmente sorprendente porque hay muchos sistemas de acantonamiento por el mundo de las maquetas, pero claro, pocas serán aquellas en las que el control del sistema sea por ordenador sin ser digitales.

En un par de ocasiones he filmado la pantalla del ordenador, y aunque la imagen no es muy nítida se puede apreciar cómo tenemos ya dos cabinas y en ellas vemos los velocímetros moviéndose según los trenes frenan o aceleran, los repetidores de señales cambiando de rojo a verde, y por supuesto todo el movimiento de asignación de cantones que se muestra en la parte alta de cada cabina.

También se puede ver en la vista general del circuito como se van mostrando los cantones libres y ocupados y cómo aparecen las "etiquetas" que indican el paso de los trenes por las balizas.

Por cierto, en las cabinas tenemos una novedad y es la presencia del número de cabina visible en la esquina superior izquierda en un tamaño bastante grande y en un formato que imita los displays de siete segmentos. Esto tiene que ver con una nueva idea que se me ha ocurrido, pero que prefiero de momento dejar en la reserva.

Ahora tengo un tema que resolver: Hace muchos meses que dejé en suspenso la instalación de detectores de paso en la maqueta, precisamente para esperar a ver si funcionaban bien o tenía que modificar algo, y sobre todo para calibrar las distancias entre los sensores y los puntos de parada. Así que sólo están puestos los sensores en el circuito superior de la maqueta, que es donde estoy realizando todas las pruebas. Ahora ya tengo la seguridad de que todo funciona bien, así que ya puedo dedicarme a colocar todos los sensores que dejé pendientes. ¡Me va resultar raro volver a meterme debajo de la maqueta a tirar cables después de tantos meses!


domingo, 12 de mayo de 2013

PWM3A.02


Hace ya unos cuantos meses, publiqué un artículo (PWM II) en el que describía un controlador de corriente PWM, que había construido, aprovechando la información que sobre éstos elementos había recopilado en ese momento. La idea era utilizar este tipo de control, en mi maqueta hasta tanto no se pusiese en marcha el control electrónico de tracción que tenía previsto. Poco después construí un modelo doble, que fue el que realmente utilicé en mi maqueta, hasta que hace un par de meses empezó a funcionar el sistema electrónico.

Como es mi costumbre, publiqué en la página de descargas de este blog, las instrucciones necesarias para construir estos elementos, y me consta que algunos aficionados han utilizado esta información para realizar sus propios controladores.

Sin embargo, hay mucha gente que no tiene entre sus habilidades la construcción de circuitos electrónicos, y por eso en ocasiones se han dirigido a mi, para ver si les podía proporcionar uno de estos elementos ya montado. Ese ha sido por ejemplo el destino del controlador doble que había venido utilizando en mi maqueta hasta el mando electrónico. En general, no he tenido problema en atender estas peticiones, aunque no me quiero plantear este tema como un negocio.

Sin embargo, el diseño inicial, había sido hecho realmente para mi mismo, con lo cual había utilizado por ejemplo un tipo de conectores que yo uso habitualmente, pero que no son comunes en la afición maquetista. Por otro lado, el tipo de disipador que había utilizado en el diseño inicial, ha sido descatalogado en la tienda donde habitualmente lo compraba, así que pensé que debería cambiar un poco el diseño, para, evitar estos problemas.

También se daba la circunstancia de que en algún caso, algún usuario ha tenido problemas con la polaridad de la alimentación, y tal como estaba hecho, si se conectaba con la polaridad cambiada, se inutilizaba. Lo lógico era poner una protección para evitar este problema.

Todo esto me ha llevado ha hacer un cambio de diseño, utilizando un disipador más estándar, conexíón a la vía mediante clemas, y conexión a la alimentación mediante un conector de alimentación, protección contra inversión de polaridad, etc. El nuevo diseño (PWM3A.02) es el que vemos en la cabecera, y por cierto es un poco más pequeño que el anterior, gracias a la colocación vertical del disipador.

Este nuevo diseño está a disposición del que lo quiera descargar para construirlo, en la página de descargas de este blog.

Como prueba del primer prototipo, he grabado el siguiente vídeo que permite apreciar que el buen funcionamiento de la versión anterior se mantiene totalmente. Realmente electrónicamente es idéntico

Como en algún caso me han preguntado por la posibilidad de utilizarlo en escala N, he querido dejar constancia de que basta cambiar la alimentación de 9 a 12 Voltios para que sea válido para la escala N.



Como curiosidad, se ve en un momento del vídeo, una imagen tomada del osciloscopio, en la que se aprecia como varía la anchura de pulso de la señal PWM al actuar sobre el potenciómetro de control.


jueves, 2 de mayo de 2013

Electronic Progressive Cab Control



Seguramente el vídeo que encabeza este artículo, es el más importante, con relación a mi proyecto de todos los que he publicado hasta hoy.

La verdad es que resulta poco espectacular y suena a ya conocido, pues no vemos otra cosa que el mismo tren de siempre circulando por el mismo circuito de siempre. Hay que fijarse mucho, y la calidad del vídeo después del paso por YouTube no ayuda mucho, para descubrir lo que aquí se quiere demostrar, y que no es otra cosa que, ¡por fin! el sistema de Cab Control funcionando perfectamente.

La parte central del vídeo es un plano bastante largo que persigue al tren durante dos vueltas completas. En esa parte, se superpone sobre la imagen del tren, la imagen de la pantalla del programa que está manejando el sistema.

En cada vuelta, el tren pasa por tres cantones, que en el sistema se llaman T2, T3 y T4, identificados respectivamente con los colores rojo naranja y amarillo (a los electrónicos les sonará esta correspondencia de colores)

En el esquema de vías que vemos en la pantalla, podemos ver que cada ver que el tren pasa por una baliza, aparece un rótulo en la pantalla con el código de la locomotora "BR003" junto al punto del esquema de vías donde está la baliza.

Además podemos ver que cuando la locomotora está en un cantón, este cantón se visualiza en linea de trazos, indicando que ese cantón está ocupado. También podemos ver que los semáforos del esquema van alternando de rojo a verde según avanza la locomotora ocupando y liberando cantones. Además en la imagen real se pueden ver en muchos casos como los semáforos efectivamente se mueven a las posiciones correspondientes.

Todo esto no es más que el típico sistema de acantonamiento, y no tendría nada de especial, si no fuese porque la activación de los semáforos no es directa mediante un relé sino que es el programa de ordenador el que recibe la señal de detección de las balizas y decide (o no) actuar en consecuencia sobre los semáforos correspondientes. Tampoco esto es novedad, porque ya estaba funcionando así desde hace un año (véase Un pequeño paso ).

¿Donde está entonces esa novedad tan importante? Pues el tema es que como digo el tren va pasando por tres cantones, y en mi sistema cada cantón tiene una alimentación distinta (Una placa CABCON01) de manera que el tren  recibe la corriente desde tres placas sucesivamente, pero de forma que el control se mantiene siempre desde una única Cabina de Control, que va pasando automática y sucesivamente de un cantón al siguente para mantener siempre el tren controlado desde la misma cabina virtual.

Es más, cuando la locomotora se acerca a un cambio de cantón, hay un intervalo de tiempo en que la misma cabina controla el cantón que el tren va a dejar y el que va a tomar, de manera que el paso por el cambio de cantón se hace sin que el tren sufra ninguna alteración en su marcha. Naturalmente una vez que el tren está ya en el nuevo cantón, el anterior se libera, y puede pasar a ser controlado por otra cabina que maneje otro tren.

Todo este sistema funciona de modo completamente automático, sincronizadamente con el sistema de acantonamiento, ya que los sensores para uno y otro sistema son los mismos. Evidentemente la lógica que se requiere para manejar el sistema no puede hacerse razonablemente con medios electromecánicos, así que es el programa de ordenador el que toma todas las decisiones en cuanto a la asignación de cabinas a cantones, además de las ya comentadas respecto de los semáforos. Es pues un Cab Control Progresivo y como está controlado por ordenador hace bueno su nombre: Electronic Progresive Cab Control (EPCC)

En el vídeo podemos ver como el sistema actúa automáticamente si nos fijamos en la ventana que muestra la cabina de control. En la siguiente imagen vemos los elementos relacionados con este sistema de control:


Así es que si el espectador centra su atención en la imagen del ordenador que presenta la cabina, y se fija en los controles señalados en la figura anterior, podrá ver cómo, efectivamente, de forma completamente automática, el sistema va asignando y desasignando cantones a la cabina que controla el tren.

Como curiosidad se puede comprobar que el cantón T4 (amarillo) es mucho más corto que los otros dos, de manera que apenas el tren ha entrado en él, el sistema ya toma el control del cantón siguiente (T2 Rojo) para preparar la transición del T4 al T2

En la parte de arriba tememos siempre la indicación de a qué cantón o cantones está conectada esta cabina. Normalmente hay un solo cantón, salvo, como decía, cuando la locomotora se acerca a un cambio de cantón momento en el cual la cabina actúa sobre los dos cantones. A la derecha hay un recuadro, también en el color del cantón, que indica el cantón y el sector dentro del cantón en el que está situada actualmente la locomotora, y que también va evolucionando según la locomotora se mueve

Debajo hay otra ventana que indica cuál es la última baliza por la que pasó la locomotora. Cada vez que cambia la baliza se sitúa el rótulo de la locomotora en el esquema de vías y se cambia aquí la indicación de la baliza,

Luego tenemos dos "luces": La primera que vemos en verde en la imagen, es la repetición en cabina de la próxima señal, tal como ocurre en los trenes reales. La de más abajo se enciende cuando funciona el frenado automático, es decir en el caso de el tren vaya manejado manualmente, si el operador no detiene el tren cuando se aproxima una señal que ha encendido el aviso rojo en la cabina, actúa automáticamente el freno y detiene el tren antes de que penetre en un cantón que está ocupado. Los conocedores de los sistemas de seguridad en ferrocarriles reconocerán que esto no es ni más ni menos que el sistema ASFA (Aviso de Señales y Frenado Automático).

La mayor gracia de todo esto, es que no todos los trenes hacen la misma ruta, de modo que aunque coincidan en algunos cantones, en otros pueden tomar caminos distintos, de manera que la determinación de si el siguiente cantón está libre u ocupado pasa por saber cuál es el próximo cantón para un tren que puede no ser el mismo que para otro. Por ejemplo, el tren que vemos pasa del cantón T3 (naranja) al T4 (amarillo), pero otro tren podría tener programada una ruta en la cual del cantón T3 se pasase al T5 (verde). Todo eso se gobierna mediante las rutas, que básicamente continúa funcionando tal como lo expliqué en Software de Control.  Así que el sistema no sólo maneja la conmutación de cantones y los semáforos, sino que también mueve automáticamente los desvíos para que cada tren haga la ruta que se quiera.

Como se puede intuir fácilmente, el conseguir automatizar todo este sistema no es en absoluto una broma. De hecho, el desarrollo de software es con mucho la actividad más complicada de mi proyecto, y gracias a que ha sido mi profesión la he podido llevar a cabo. Simplemente como ilustración, se ve en el vídeo una ventana de texto por la que van desfilando mensajes que indican las decisiones y acciones que toma el programa según se van moviendo los trenes. Aunque los textos no se pueden leer en el vídeo, se puede comprobar la cantidad de mensajes que se producen, ¡y eso que sólo hay un tren circulando!

Precisamente he querido hacer este vídeo con un solo tren funcionando, para tratar de que se pueda seguir un poco el funcionamiento. Próximamente veremos más trenes, y cómo se paran y arrancan en los semáforos, pero si ya es complicado ver algo de cómo funciona con un sólo tren, si tenemos más trenes será imposible seguirlo, y menos en un vídeo.

Hoy he vuelto a leer el artículo de este blog titulado Acantonamiento electrónico escrito en Noviembre de 2010. Me he dado cuenta de que en ese artículo sentaba las bases de todo el desarrollo, que a lo largo de más de dos años me ha llevado a la situación actual, y está escrito  antes de haber siquiera conocido la existencia de los sistemas de Cab Control de los aficionados americanos. La verdad es que me he sentido satisfecho de haber tenido tanto acierto al apuntar hacia un camino que ha resultado tan productivo.