Un pequeño paso

Ya lo dijo Armstrong: a veces algo que parece un pequeño paso, tiene detrás un enorme esfuerzo tecnológico que no llama la atención a primera vista. Salvando todas las distancias, en este caso, distancias cósmicas, hoy he filmado un pequeño vídeo, en el que aparentemente no vemos nada extraordinario.

El que veamos en una maqueta de trenes, cómo, cuando una locomotora rebasa una señal, ésta se pone en rojo al cabo de unos segundos, no es nada sorprendente, y en la mayoría de los casos ésto se resuelve mediante un sensor que detecta el paso de la locomotora y actúa sobre el motor del semáforo, o sobre un relé en el caso de señales luminosas. En muchos casos, el sensor es un interruptor reed que se activa mediante un imán situado en la locomotora.

Sin embargo, los que hayan seguido este blog, ya sabrán que en mi caso esto es un poquito más complicado. De hecho casi la única semejanza estriba en el hecho de que efectivamente la locomotora que vemos en la imagen lleva en su parte inferior un imán, en este caso un imán de Neodimio de 3 mm de diámetro y 1 mm de espesor. En realidad, para que ese semáforo se ponga rojo, en mi maqueta pasan muchas más cosas. De hecho, todas éstas:

1. En primer lugar los sensores no son interruptores reed, sino sensores de efecto Hall. Ya comenté en un artículo anterior que estos elementos me han resultado más fiables que los reed, y además quedan muy bien entre las vías. Su tamaño parece hecho a propósito para la vía de escala Z ya que se pueden situar directamente encima de las traviesas, sin que sobresalgan por encima del carril, sin necesidad de cortar ninguna traviesa, y dejando paso libre a las pestañas de las ruedas. Quedan prácticamente invisibles, y si algo se ve, queda como una baliza en una vía real. En la foto siguiente se puede apreciar cómo quedan:

2. Estos sensores, al igual que cualquiera del resto de elementos, deben aparecer reflejados en el trazado de vías, que se maneja con el programa ControlZ. En la imagen siguiente se aprecia el semáforo que vemos moverse  en el video y la baliza, que está situada a unos veinte centímetros detrás. Está desplegada la ventana de datos de esa baliza, y vemos que el usuario le ha asignado el nombre  "B03" y la dirección hexadecimal "04"

3. Desde cada uno de esos sensores, hay un cable que llega a la placa CODIF32. Esta placa está ya situada en el armario de control de mi maqueta, y en la imagen siguiente podemos verla a la izquierda de la imagen. El mazo de cables que vemos en la parte superior es el conjunto de cables que llega de cada uno de los sensores. En total puede haber 31 sensores por placa. y vemos como se conectan a ésta por los conectores situados en la parte superior de la placa

Cada sensor debe conectarse a la entrada correspondiente a su dirección de manera que el cable del sensor que estamos considerando, se conectará a la entrada "04" y así todos los demás. La placa es un encoder de 32 a 5 bits lo cual quiere decir que es capaz de reproducir en su salida de 5 bits la expresión binaria correspondiente a la entrada activada. Así que en nuestro caso cuando se active la entrada "04", la salida mostrará la expresión binaria correspondiente al hexadecimal "04" que es "00100" Esta expresión se mantiene en la salida solamente mientras el sensor está activado, es decir durante el tiempo que tarda el imán en atravesar la zona sensible del sensor Hall, lo cual es menos de una décima de segundo si la locomotora va rápida (por eso, en el vídeo grabado durante las pruebas, vemos a la locomotora circular a toda velocidad) Como decía, esta expresión binaria aparece en la salida donde vemos el conector de seis vías situado al lado contrario de las entradas. Este conector lleva esos datos a la placa Velleman.

4. Sobre las placas Velleman, ya hemos hablado bastante en este blog. En la imagen siguiente vemos el armario de control con dos placas Velleman en primer plano:

Cada placa Velleman tiene cinco entradas digitales, así que no hay más que conectar aquí las cinco salidas de la placa CODIF32 para que la señal llegue a la placa Velleman. El funcionamiento de ésta consiste en transmitir el dato que recibe hacia el ordenador mediante la salida USB. Como ya he comentado, Velleman suministra con sus placas un software (una dll con una serie de funciones) que permite la interacción entre la placa y un programa que se esté ejecutando en el ordenador que controla el proceso.

5. En el ordenador que controla la maqueta, se ejecutan varios programas simultáneamente. Por un lado está el que denomino ControlZ que es el que mantiene la interfase de usuario. Simultáneamente se ejecuta el programa de comunicaciones, que el usuario normalmente no ve, pero que es el que se encarga de transmitir y recibir la información de las placas Velleman. Se ejecutan simultáneamente varias instancias de este segundo programa, tantas como placas Velleman estén activas. De acuerdo con mis mediciones, entre el retardo introducido por la placa, la comunicación serie por USB, y las funciones suministradas por Velleman, el dato situado por CODIF32 en la entrada de datos de la placa está disponible para el software con un retardo de 12 milésimas de segundo.

El programa de comunicaciones hace un polling del dato recibido con un periodo de 15 milésimas de segundo, y si detecta un dato distinto de cero, lo almacena en una variable hasta que sea procesado por la rutina de verificación. Esta rutina de verificación que se ejecuta cada 100 milésimas de segundo determina si se ha recibido algún dato y si es así lo valida y realiza las operaciones siguientes:

Genera un mensaje para el programa principal indicando el dato recibido y queda a la espera de recibir confirmación de lectura. Este mensaje se sitúa en un área COMMON a la que tienen acceso el programa principal y las diferentes instancias del programa de comunicaciones.

Escribe un archivo de log donde se van recogiendo todas las comunicaciones para que se puedan consultar por el usuario, si desea analizar el tráfico de mensajes.

Si en tres segundos no ha recibido confirmación de lectura por parte del programa principal emite una alarma por fallo de comunicaciones.

6. Cuando el programa principal detecta un mensaje en el área COMMON, en primer lugar emite el mensaje de recepción que espera el programa de comunicaciones, y a continuación procesa el mensaje recibido que este caso será algo así como "Activado el sensor 04" Entonces entra la rutina que interpreta estos mensajes de activación de sensor que hace lo siguiente:

En primer lugar busca en sus tablas internas qué sensor tiene la dirección hexadecimal "04" y en este caso encontraría que es el "B03". Además lee la posición en pantalla de este elemento, el cantón a que pertenece, etc. Lo primero que hace el programa es situar en la pantalla, junto a la baliza que se ha activado, una etiqueta que indica que una locomotora está pasando por ese punto. (Cuando el sistema de control de tracción esté completo, esta etiqueta contendrá el nombre de la locomotora, pero esto no está operativo todavía)

A continuación busca en la RUTA activa todas las líneas que correspondan a la baliza "B03" Para cada línea de la Ruta que corresponda a esa baliza realiza la(s) instrucciones asociadas, después de comprobar que se cumpla la posible condición que se pueda haber incluido. En nuestro caso, para que la señal se ponga en rojo, deberá haber una línea que contenga la instrucción: "F03 Rojo" ya que F03 es el nombre de la señal que se debe poner roja.

Cuando el programa detecta una instrucción como esa, lo primero que hace es localizar en sus tablas el elemento "F03" y al hacerlo encuentra sus datos. En este caso esas tablas indican que este semáforo tiene la dirección hexadecimal "54"para la señal roja y "55"para la señal verde, y que el tiempo de activación es de 200 milisegundos.

Entonces cambia la imagen en pantalla de este semáforo de manera que se vea rojo. A continuación coloca un mensaje en el área COMMON que tendría un significado como "El programa de comunicaciones 1 debe emitir durante 200 milisegundos el dato 54" y queda a la espera de confirmación de la recepción.

Este proceso se repite para todas las líneas de la Ruta activa que estén activadas por la baliza "B03".

7. Cuando el programa de comunicaciones detecta este mensaje en el COMMON, emite el mensaje de recepción, y procede a llamar a la rutina de Velleman que comanda las salidas para hacer que estas presenten durante 200 milisegundos la expresión binaria que corresponde al hexadecimal 54 y que es "01010100", Esto hace que esta expresión se transmita por USB hacia la placa Velleman correspondiente, que inmediatamente presenta en sus 8 salidas digitales la expresión binaria 01010100.

8. A esta salida binaria está conectada la placa DEMU01 cuyo funcionamiento ya se vio en su momento. En la anterior imagen del armario se puede ver una placa DEMU01 y 12 placas DEMU02

Esta placa utiliza un integrado 74HC154 para decodificar los cuatro bits altos de la señal recibida y deja pasar los cuatro bits bajos. Así que en nuestro caso como los cuatro bits altos son "0101" esto significa "05" (hexadecimal) por lo que se activa la salida 5 de entre las 16 posibles. Los cuatro bits bajos "0100" no se procesan en esta placa.

A estas 16 salidas pueden estar conectadas hasta 16 placas DEMU02, de ellas una, la que tenga asignada la dirección "05" en su pianillo  se activará al detectar la salida "05"

Los cuatro bites bajos"0100" llegan a todas las placas. pero solamente una, la de dirección 05 estará activada,`por lo que solo ésta responde a los bites bajos y a su vez los decodifica de manera que como 0100 representa "04" se activará la salida 4. En resumen se habrá activado la salida 4 de la placa 5. Sobre esta salida 4 hay montada una matriz de transistores Darlingnton alimentada a 12 voltios, por lo que se produce una salida de 12 voltios de tensión por la mencionada salida, durante el tiempo preestablecido de 200 milisegundos.

A esta salida va conectado un cable que por corresponder a la dirección 54 (placa 5 salida 4) va conectado a la bobina del semáforo que queríamos accionar y que lo mueve a la posición roja.

Con lo cual....... el semáforo se mueve a rojo, como vemos en el vídeo. (¡¡¡ UFF !!!)

La verdad es que expuesto así, con todo detalle, asusta bastante, pero no es más que una serie de elementos y procedimientos que he ido desarrollando durante los tres últimos años. ¡Supongo que si hubiese sabido desde el principio lo que me esperaba, no me hubiese lanzado!

Supongo que algún lector puede estar pensando si merece la pena tanta complicación, cuando en definitiva con un interruptor reed se pueden mover los semáforos al paso de los trenes y establecer un sistema de bloqueo automático.

Evidentemente aquí hay dos cosas que nunca puede tener un sistema de bloqueo realizado a base de interruptores reed y relés:

La primera es que el sistema descrito incluye el control por ordenador. En la pantalla del ordenador no solo se representa el trazado y todos los elementos auxiliares, que van mostrando su situación según van cambiando, sino que además permite manejar cada elemento de forma individual. Es más el sistema permite simular la activación de cualquier baliza sin más que hacer click sobre ella en la pantalla, desencadenando todas las ordenes asociadas, o bien actuar individualmente sobre un solo elemento (semáforo, desvío, desenganchador). En definitiva manejar el sistema desde una forma completamente automática hasta completamente manual.

A casi todos los que hemos montado un sistema de bloqueo basado en relés, nos ha ocurrido lo siguiente: Cada sensor situado junto a una señal, pone en rojo la señal contigua y en verde la señal anterior porque se conectan al mismo sensor. Pero si queremos manejar manualmente las señales, por ejemplo para ponerlas todas en verde no hay forma (fácil) de conseguirlo, porque si ponemos un semáforo en verde se nos pone automáticamente en rojo el siguiente al estar unidos eléctricamente el rojo de un semáforo y el verde del otro. Con este sistema, no existe tal problema, porque cada semáforo se maneja individualmente. Si cuando un semáforo se pone en rojo otro se pone verde cuando se activa una baliza, será porque hay dos líneas para esa baliza en la tabla de rutas.

La otra ventaja importante es la posibilidad de realizar operaciones complejas mediante la tabla de instrucciones de las rutas, que no solo incluyen mover semáforos sino también mover desvíos, ordenar acciones condicionadas, ordenar acciones diferidas, etc etc. Y todo ello con la posibilidad de tener varias rutas distintas planificadas y la posibilidad de definir con facilidad cualquiera otra que se necesite.

Sólo con estas dos consideraciones ya sería suficiente para justificar el control por ordenador, pero evidentemente hay una tercera característica, que todavía tengo que desarrollar, y que consiste en incorporar el control de tracción al sistema. Algo que no he mencionado en este artículo, es que aunque los semáforos ya se mueven de acuerdo con la circulación de los trenes, éstos no se paran automáticamente ante un semáforo rojo. Por supuesto puedo pararlos manualmente, porque todavía conservo el control de tracción en modo manual, y hasta podría cortar un sector de vía delante de cada señal y hacer que se parasen los trenes utilizando el conmutador de corriente de tracción que lleva cada semáforo, y que no he usado. Pero no es esa mi idea: Espero poder tener terminado pronto el prototipo del sistema de tracción, que combinado con lo que ya está funcionando, va a suponer un control total de los trenes, con paradas y arrancadas suaves ante los semáforos, velocidades individualizadas para cada locomotora, etc etc.

También es posible que algún lector haya pensado: ¿pero no es mucho más facil hacerlo con el sistema digital? Evidentemente el sistema deigital es mucho más fácil para el usuario porque nos lo dan hecho. Sin embargo si explicásemos el funcionamiento de un sistema digital con este nivel de detalle el resultado sería mucho más complicado. Adviértase que en toda esta esta explicación no han aparecido para nada cosas como "protocolo DCC"  "Cv's" por poner sólo dos palabras que están continuamente sobre la mesa al hablar de digital