lunes, 28 de mayo de 2012

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

viernes, 11 de mayo de 2012

Software de control (y III)


En el artículo anterior, mostraba una imagen de la pantalla del programa ControlZ mostrando un zona correspondiente a la estación de montaña de mi maqueta. Decía que para permitir una explicación, había introducido manualmente una rotulación sobre la imagen original, rotulación que el programa no presenta realmente en esa forma, sino que aparece para cada elemento su nombre según pasa el cursor del ratón por encima.

Vuelo a traer aquí una imagen de esa estación de montaña, pero ahora sin ningún retoque, precisamente porque voy a referirme a las indicaciones que el programa si presenta en la pantalla. Vuelvo a recordar que los colores con que se representa cada vía corresponde al cantón al que pertenece de manera que aquí vemos parte del cantón 1 en marrón, del cantón 2 en rojo, del cantón 3 en naranja del cantón 4 en amarillo y del cantón 5 en verde.

Por supuesto, tenemos indicación visual en la pantalla de la posición de cada desvío, de forma que vemos claramente como tenemos hecho un itinerario para que el tren circule de izquierda a derecha por la vía naranja, con sus correspondientes señales abiertas. El que en este cantón 3 de color naranja se vea la linea continua de ese color indica que ese cantón está libre, es decir no hay ningún tren en ese cantón.

Por el contrario en la vía de arriba, la roja del cantón 2 vemos que la linea es de trazos negros y rojos. Eso indica que el cantón está ocupado, esto es, que hay una locomotora moviéndose en ese cantón. En definitiva la linea continua indica cantón o sector libre y la linea de trazos indica cantón o sector ocupado.

En la vía central tenemos un sector que está ocupado y desconectado, es decir tiene cortada la alimentación por el correspondiente relé. Por eso se ve de color gris. Además la linea es de trazos. o sea que está ocupado.

Efectivamente hay una locomotora parada en ese sector y por eso vemos el rótulo BR 003 sobre fondo rojo. BR 003 es por supuesto la identificación de la locomotora que está en ese sector y el fondo rojo indica que está parada.

En la primera vía vemos también el rótulo BR 85 sobre fondo verde. Esto indica que sobre la baliza que hay junto al rótulo acaba de pasar la locomotora BR 85, que está circulando por ese cantón. Por eso todo el cantón rojo aparece como ocupado. El rótulo verde aparece cada vez que una locomotora pasa sobre una baliza, y permanece visible junto a la baliza hasta que la misma locomotora pasa sobre otra baliza.

En definitiva,  la pantalla del ordenador va presentando dinámicamente toda la información sobre qué cantones o sectores se ocupan y liberan y también la información de la posición de todas las locomotoras presentes en la maqueta. En la siguiente imagen vemos otro ejemplo, esta vez correspondiente a la estación principal:


Aquí vemos como hay cuatro locomotoras estacionadas en cuatro vías de la estación principal, que vemos indicadas con su rótulo rojo. Esas cuatro locomotoras están sobre sectores inactivos (color gris) y por eso están paradas. La segunda vía desde abajo está vacía así que no se visualiza con trazos ni tiene etiqueta de locomotora, pero está aislada y por eso la vemos gris. En la vía cuarta desde abajo, está entrando la locomotora BR 003, que acaba de pasar sobre la baliza de esa vía. Por eso vemos ya su rótulo en esa vía, pero como todavía ese tramo está bajo tensión el rótulo está en verde y el color de la vía es violeta, lo que corresponde al cantón 7. La locomotora puede estar todavía moviéndose (posiblemente al pasar sobre la baliza de la vía se habrá ordenado una parada suave) o estar ya parada, pero el relé de ese sector sigue conectado y por lo tanto da ocupación a todo el cantón 7. Por eso vemos todo el cantón siete, violeta, de trazos.

Se puede ver también el itinerario de desvíos que la han llevado desde la señal de entrada abajo a la izquierda, hasta la vía de andén donde está entrando.

Las posiciones de ocupación y las etiquetas de locomotora, se conservan de sesión a sesión aunque el ordenador se apague, así que si no movemos los trenes, al volver a encender el programa, se mostrarán las posiciones y ocupación de todos los elementos tal como quedaron al cerrar el ordenador en la sesión previa.

Pero claro, en una maqueta de trenes tenemos que prever las intervenciones manuales, para quitar manualmente un tren de las vías o para ponerlo. Estos casos están previstos de una manera bastante simple: Si manualmente hacemos click sobre una baliza de un sector se pondrá la locomotora que digamos en ese sector, y el programa mostrará la etiqueta en esa posición. Análogamente, al hacer click en una de las etiquetas la locomotora se elimina de ese sector dejándolo libre.

Creo que con esto, están cubiertas todas las necesidades en cuanto al programa de control. Ahora por supuesto falta por probar todo esto, empezando por situar las balizas en la maqueta, con el correspondiente cableado, cosa que todavía no he hecho, y que me va a llevar unos cuantos días de un trabajo bastante delicado. El consuelo es que será la última actuación que afecte a la vía

Es curioso que prácticamente todo esto puede funcionar aún manteniendo el control manual de los trenes. Las señales se moverán y los sectores y cantones cambiarán sus indicaciones de libre a ocupado, y todo ello simplemente por la actuación de los sensores de la vía, con independencia de que la corriente de tracción sea todavía manual. Incluso los relés que activan o desactivan los sectores funcionarán sobre la corriente de tracción aunque el control de tracción siga siendo manual.

Las únicas cosas que no van a funcionar bajo control del programa, hasta que la tracción tenga control por programa, son las paradas y arranques suaves. Así que aunque parezca sorprendente, todo lo que se ha visto aquí en los tres últimos artículos puede aplicarse prácticamente al cien por cien a una maqueta estrictamente analógica con mando manual de los trenes









martes, 8 de mayo de 2012

Software de control (II)


Para aquellos lectores que se hayan quedado con la curiosidad de saber para qué sirven el resto de las columnas de la ventana de definición de rutas presentada en el artículo anterior, voy a explicar aquí su funcionamiento.

En la figura del encabezado podemos ver la "estación de montaña" de mi maqueta, tal como la vemos en la pantalla del ordenador. He incluido una rotulación en rojo que muestra los nombres de unos cuantos elementos, tal como están definidos en el sistema. Los nombres que empiezan por F se refieren a semáforos, los que empiezan por D a desvíos, los que empiezan por B a balizas y los que empiezan por T a tramos aislados.  Respecto de estos últimos, aclaro que los cantones se denominan T1, T2... T8 y se dibujan en colores diferentes. El color rojo corresponde al cantón 2, el naranja al cantón 3, el amarillo al 4 etc (a los conocedores de las claves de colores para el marcado de resistencias les sonará esa nomenclatura) Dentro de un cantón puede haber un número indefinido de sectores o tramos aislados, que son los segmentos de vía que pueden ser conectados o desconectados mediante un relé. En la imagen vemos T3P1 y T3P2  Ambos empiezan por T3 porque pertenecen al cantón T3 y el resto P1 y P2 indica que son respectivamente el sector 1 y el sector 2 del cantón 3. Estos sectores los vemos en color gris, como indicación de que están inactivos, es decir, que su relé lo mantiene desconectado de la alimentación de su cantón.

La nomenclatura como se ve es bastante sistemática, precisamente para facilitar la definición de las rutas, pero eso no es una exigencia del programa. Podemos denominar cada elemento como queramos. El que yo haya rotulado la figura con esos nombre es para facilitar la explicación pero la imagen de pantalla no tiene esas indicaciones porque si apareciesen los nombres de todos los elementos en la pantalla tendríamos una imagen muy abigarrada, salvo que los rótulos fuesen muy pequeños, pero entonces resultarían invisibles. En lugar de eso, lo que se tiene es que simplemente pasando el cursor de ratón sobre un elemento, aparece  una ventanita con su nombre

Pues con esta explicación previa puedo pasar a demostrar como funciona la columna "Condición" de la ventana de rutas. (Posiblemente se necesitará ampliar esa imagen, haciendo click en ella)

Lo que he tratado de hacer es demostrar como se puede hacer una gestión automática de la estación, concretamente en este caso de las dos vías T3P1 y T3P2. Los trenes circulan por la derecha, de modo que en las vías de color naranja, van de izquierda a derecha, así que la señal F13 es la señal de entrada en la estación, y F04 y F06 son las señales de salida de las vías  T3P1 y T3P2 respectivamente.

La baliza B35 no aparece en la imagen porque está a la salida de la estación anterior. La idea es que cuando el tren sale de la estación anterior, prepare las señales y los desvíos para cuando llegue a esta estación. Por eso todas las acciones que aquí vemos se ordenan al activarse la baliza B35

Lo primero que se hace es poner la señal de entrada en rojo. Si al final del proceso el sistema puede dar paso al tren, esta señal se pondrá en verde, si no es así, porque ambas vías T3P1 y T3P2 están ocupadas, la señal quedará en rojo. impidiendo el acceso del tren a la estación. En las siguientes lineas aparece la expresión "T3P2  Libre" en la columna "Condición" . Esto quiere decir que el  programa comprueba si esa expresión se cumple, y solo si es así se ejecuta la orden expresada en la columna "Acción"

Así, en este caso, si esta vía está libre se ejecutan las cinco instrucciones indicadas, es decir en este caso, poner el desvío D41 en curva, el D15 recto y el D14 en curva. Es decir hemos hecho un itinerario para que el tren atraviese la estación por la vía T3P2 Además ponemos la señal de entrada F13 en verde y activamos el tramo T3P2 para que la vía tenga corriente cuando llegue el tren.

Pero eso no es todo: a continuación se hace un intento de hacer un itinerario por la vía T3P1 que sería más favorable. Para ello se incluyen cuatro instrucciones más condicionadas a que el tramo T3P1 esté libre, así que ponemos en la condición "T3P1  libre"

Si esta condición se cumple, de ponen rectos los desvíos D41 y D14, y lo mismo que antes, se pone verde la señal de entrada y se activa el tramo T3P1. Como esta secuencia se ejecuta después, el itinerario queda efectuado por la vía T3P1 aunque ambas estuviesen libres.

O sea, que eso tan discutido en los foros acerca de los complicados circuitos a base de relés para automatizar una estación, se puede hacer también perfectamente por software. Evidentemente con más lineas, se pueden automatizar estaciones de más vías.

Pero todavía podemos hacer mucho más. La pantalla de rutas tiene dos columnas más que son muy interesantes: Se denominan "%Velocidad" y "Retardo" veamos como funcionan:

La siguiente imagen recoge la continuación de la anterior dentro de la misma ruta, ya que ahora vemos las líneas 11 a 18


Aquí definimos qué pasa cuando el tren llega a la estación. Si entra por la vía T3P1 activará la baliza B31, así que se ejecutarán las instrucciones 11 12 y 13. En la primera ponemos la señal de entrada F13 en rojo y también la señal de salida F04

La línea 13 es muy interesante porque hace dos cosas: Primero pone el sector T3P1 en situación de ocupado y a continuación ejecuta la instrucción "T3 0" Esto ordena que el cantón 3 haga una parada progresiva hasta parar el tren.

Obsérvese que la orden es al cantón "T3" completo. Como saben mis lectores mi sistema se basa en que en cada cantón sólo puede haber una locomotora activa  así que esta orden afecta a la locomotora que acaba de accionar la baliza B32.

O sea que la columna % Velocidad ordena simplemente que el cantón indicado cambie la "Velocidad Objetivo" a un porcentaje de la velocidad máxima indicado por la cifra que aparece en la columna. Un cero, como en este caso, hace que la velocidad objetivo sea 0 así que la locomotora decelerará hasta pararse. Si ponemos por ejemplo T3 50 ordenaremos que la velocidad objetivo pase a ser el 50% de la velocidad máxima de la locomotora.

Aunque todavía no he llegado a ello, está claro que el control de tracción funciona haciendo que la locomotora tienda siempre a la velocidad que se le marca como velocidad objetivo desde su velocidad actual en cada instante. El que alcance esa velocidad objetivo más o menos rápidamente dependerá de como se programe la simulación de inercia.

Adviértase que con este sistema, el control de que una locomotora pase más o menos rápida por una zona, no está asociada a un bloque o cantón, sino al hecho de activar una baliza. Podríamos cambiar la velocidad de la locomotora por cada baliza que pase. Recuérdese que esta orden está en la definición de la ruta de manera que otra locomotora que pase por la misma baliza pero siguiendo otra ruta no tiene porqué obedecer al mismo ajuste de velocidad.

Naturalmente con velocidad objetivo 0 la locomotora acaba por detenerse, pero esta parada es siempre una parada suave de acuerdo con la programación del control de tracción. Realmente existen dos formas más de parar una locomotora: Una es la instrucción de tramo inactivo Por ejemplo "T3P1 Inactivo" lo que hace es ordenar que el relé del tramo T3P1 desconecte la corriente de ese tramo. Por supuesto, si hay una locomotora en ese tramo se parará inmediatamente. Como esta parada es brusca normalmente solo la emplearemos en estaciones ocultas o para dejar "aparcada" la locomotora en ese tramo.

La otra forma de detener el tren es la instrucción Stop. Por ejemplo la instrucción "T3 Stop" lleva el regulador del cantón T3 inmediatamente a cero.

Veamos ahora algo particularmente interesante, recogido en las líneas 14 a 17 de la última pantalla de ruta, y que corresponden a la baliza B32, es decir, al caso de que el tren haya entrado por la vía T3P2.

Las tres primeras son análogas a las tres primeras de la baliza 31, es decir, se pone a rojo la señal de entrada F13, se pone a rojo la señal de salida F06, el sector se marca como ocupado, y se fija la velocidad objetivo en cero, con lo que el tren se parará suavemente en la estación.

Pero en la línea 17, vemos como asociada a la misma baliza B32 se ordena poner la señal de salida en verde y arrancar suavemente hasta el 80% de velocidad, lo cual sería contradictorio con lo indicado en la linea anterior. La clave está en la cifra 30 incluida en la columna "Retard". Lo que esto hace es que esa instrucción se ejecute 30 segundos después de la activación de la baliza. Es decir, en definitiva, al pasar por la baliza B32 el tren hace una parada suave en la vía T3P2, espera 30 segundos, y realiza un arranque suave hasta alcanzar la velocidad 80% de su máxima.

Para dejar el tema terminado:

La columna "R" indica que cuando se cambie la velocidad a la velocidad objetivo ordenada, se haga hacia delante o hacia atrás.

Las dos columnas "Transición" ordenan que cuando se active esa baliza se haga una transición de cantones desde el indicado en la primera de estas columnas al indicado en la segunda. Es lo que hará funcionar el "conmutador de cantones" descrito en "CabControl" Como complemento a esas dos columnas, la marcada como "X" indica si esa transición hay un cambio de polaridad en la vía.

Si algún lector ha conseguido llegar hasta aquí, aparte de manifestarle mi agradecimiento, seguramente tendrá conocimientos más que medianos de programación, así que comprenderá que programar todo esto es un esfuerzo bastante importante, ya que no solo estamos hablando de una ventana donde se pueda definir toda esta parametrización, sino que cada dato que introducimos es validado, y almacenado en la base de datos con los correspondientes enlaces a todos los datos relacionados, más toda la programación correspondiente para que todo esto actúe, produciendo las correspondientes señales de salida y el reflejo visual en la pantalla del ordenador.  Está claro que no me aburro.

A propósito del tema, parece interesante hacer una reflexión, Como se puede apreciar por todo lo visto, el programa está hecho como para venderlo. Quiero decir que todos los datos se introducen en pantallas y ventanas con los correspondientes rótulos y las oportunas validaciones, aparte del hecho de que se pueda partir de cero y definir cualquier trazado de vías. Aparentemente esto es un trabajo inútil puesto que probablemente parece que es mucho más fácil hacer un programa que sólo tenga la parte operativa, de modo que los datos están, o bien definidos en la propia programación, o en algunos archivos externos que se rellenan manualmente con datos fuera del control del programa.

Seguramente el actuar así procede de una deformación profesional. Me he pasado mi vida laboral diseñando programas para que los manejen otros, así que se me va la mano a esa forma de programación. Por otra parte las otras alternativas solo aparentemente son más rápidas de desarrollar, porque aunque al principio se obtienen resultados más rápidamente, la desorganización lógica que supone esa forma de actuar hace que cualquier modificación sea cada vez más compleja.  Evidentemente, aunque mi objetivo no sea la venta, este programa podrá ser utilizado en el futuro por otras personas que se atrevan a seguir esta línea.

domingo, 6 de mayo de 2012

Software de control (I)


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.