Rotondas digitales

 

Como ya he comentado, está comenzando a funcionar mi sistema de control por ordenador para los aparatos de vía y accesorios, lo que incluye desvíos, y desenganchadores, las señales mecánicas y los propios sectores aislados.

En la primera parte del vídeo aquí presentado se puede ver el sistema funcionando. En general he tratado de que se vea al mismo tiempo la pantalla del ordenador, y detrás el aparato de vía que está respondiendo a las instrucciones dadas desde el programa

 

Tenía pendiente un tema, y me refiero al control de los puentes giratorios. Ya he dedicado aquí algunos artículos a este tema,  y por cierto dejando las cosas un poco en el aire, ya que no acababa de convencerme ni la forma de conseguir el movimiento del puente, ni la forma de conseguir llevar la corriente de tracción a las vías del puente.

 

Aprovechando que tenía que esperar la llegada de suministros me he puesto a perfeccionar el programa de control para que pueda manejar los puentes giratorios de las rotondas, de una manera eficiente. El resultado obtenido ha sido muy positivo. Como se ve en la última parte del vídeo la cosa funciona así:

 

La imagen de la rotonda en la pantalla del programa, presenta una representación del puente, siempre situado en la misma posición que el puente en la maqueta. Esta imagen tiene un ensanchamiento, por la parte correspondiente a la cabina del puente para distinguir ambos extremos.

 

Cuando el usuario quiere mover el puente, pulsa sobre una de las dos flechas que tiene la imagen. Esto hace girar la imagen del puente en el sentido deseado. Repitiendo las pulsaciones el usuario mueve la imagen hasta que marque la posición a la que desea llevar el puente. Éste, mientras tanto,  todavía no se ha movido. Una vez que la imagen de pantalla muestra la posición deseada. se pulsa de nuevo, esta vez en el centro de la imagen. En ese momento, la imagen del puente retorna a mostrar la situación inicial del puente, el puente comienza a girar, y el fondo de la imagen cambia  a verde. Mientras el puente gira, la imagen permanece verde, y la imagen del puente va girando sincronizadamente en la pantalla. Cuando el puente llega a la posición deseada, el color verde desaparece, quedando la imagen del puente en la misma posición que el puente de la rotonda.

En algunos foros he visto en algún caso discusiones acerca de la mejor forma de digitalizar un puente giratorio. Parece que existen decoders especiales para esta función pero por lo que parece hay muchos problemas y en algunos caros es necesario incluso cambiar el cableado del puente. Mi sistema es bastante simple y desde luego no se necesita ninguna modificación en el puente. Simplemente se conectan los cables del puente a tres de los relés utilizados por el sistema. El primer relé controla el sentido de giro, el segundo controla la marcha y parada del puente y el tercero controla la polaridad de las vías del puente. Todo ello, sincronizado con los movimientos de la imagen de pantalla, se hace por software.

Hace unos meses, escribí aquí un artículo llamado precisamente "Rotonda" donde contaba los problemas que estaba encontrando para organizar la alimentación. En ese artículo, decía:

• La otra solución es más drástica: Consiste en eliminar las celebérrimas chapitas de contacto. De esta forma las vías de parada llegan justo hasta el borde del puente, pero no se comunican con los carriles del puente. Los dos carriles del puente deben entonces recibir alimentación independientemente por medio de los cables de conexión del puente. Evidentemente hay que hacer algo para que el puente reciba esta corriente con la polaridad adecuada, lo cual no es fácil. Como sistema automático no se me ocurre ninguno, salvo que acabe de controlar todo esto con ordenador y el programa sea tan listo que conozca en cada momento la posición del puente

Es evidente que la condición expuesta en ese artículo se ha cumplido. Ahora el puente está controlado por ordenador y el sistema es efectivamente "tan listo" que conoce en cada momento la posición del puente. Tan es así que refleja esta posición en la pantalla del ordenador. Así que estoy en las condiciones ideales para utilizar esta opción que pasa por suprimir las famosas chapitas. Dicho y hecho: ayer fueron cuidadosamente extirpadas, con lo cual se han evitado problemas, ya que en algunos casos alguna de estas chapitas de enganchaba en la cabeza de un carril, entorpeciendo el movimiento del puente. Desde que hice esta operación , el puente gira estupendamente en ambos sentidos. Me falta todavía incluir en el software la función que manejará el sentido de la corriente en el puente, pero eso es muy sencillo.

Un poco de software (I)

Pantalla del programa ControlZ en un ordenador de 1280 x 1024 pixels de resolución de pantalla.

Como saben mis lectores, en este blog voy publicando todos los avances que realizo en la construcción de mi maqueta. También voy explicando en los distintos artículos cómo y porqué voy haciendo cada cosa, y publico fotografías planos y esquemas de trazados de vía, esquemas eléctricos, etc. No sólo eso, sino que en las páginas de Descargas, a las que se accede desde el menú de la cabecera, publico esquemas eléctricos, plantillas de PCB, listas de material, y en definitiva todo cuanto se necesita para que si alguien quiere seguir mis pasos, pueda hacerlo.

Debo dejar claro, sin embargo que éste es un sistema absolutamente original, y distinto del sistema que se ha impuesto de forma absolutamente global. Me refiero, claro está al sistema digital, asi que el que quiera meterse por mi camino sabe que no va a encontrar prácticamente ningún producto comercial que venga en su ayuda, de forma que, como yo, tendrá que hacerse todo el hardware de forma artesanal.

Pero seguramente, con ser eso un problema, no es el mayor, porque realmente los elementos de hardware son bastante sencillos, y para el sistema de comunicaciones he podido utilizar una placa de comunicaciones comercial.

Sin embargo, apenas he comentado nada acerca del software que he desarrollado para mi proyecto, y que se materializa en el programa que he denominado "ControlZ".  En mi último artículo me referí de nuevo a él, comentando que había podido ponerlo en marcha en un nuevo ordenador (más bien un mini ordenador) y en un nuevo sistema operativo (Windows 7). Así que ahora que estoy de nuevo metido en harina con el software, es una buena oportunidad para hablar de este tema.

Lo primero que hay que decir, es que el programa está incompleto, tan incompleto como el resto del proyecto, porque todo va avanzando en paralelo.

Sin embargo, en algunas ocasiones, se han dirigido a mi algunos lectores pidiéndome que les explique cómo, o les ayude a realizar un programa similar para sus maquetas. En todos los casos he contestado a esas demandas con explicaciones o incluso aportando piezas de software, pero tengo la sensación de que a ninguno de esos demandantes les han servido de mucho mis respuestas.

Y es que parece que estos comunicantes esperaban algún procedimiento maravilloso para dibujar un desvío en la pantalla, desvío que cambia de posición al pulsar con el ratón sobre él, o para dibujar un semáforo cuyas luces cambian de verde a rojo, o un desenganchador que parece que se levanta al pulsar sobre el mismo y no digamos ya, si de lo que se trata es de dibujar un velócímetro, cuya aguja se mueve por la escala indicando la velocidad en cada momento de la locomotora, o de dibujar una rotonda cuyo puente hacemos girar con el ratón  y que como consecuencia hace que la rotoda de la maqueta se mueva.(ver: Rotondas digitales). Todo ello, como decía aquél, es "more transpìration than inspiration". Quiero decir que conseguir eso, es complicado, y requiere bastante experiencia en programación, y concretamente en programación de gráficos.  Se da la circunstancia de que la programación ha sido mi actividad profesional durante muchos años, así que estaba dentro de mi alcance el abordar este tipo de software, pero precisamente en esa actividad profesional he podido comprobar como muchos programadores expertos patinan clamorosamente, cuando se enfrentan a ese tipo de programación.

Tomemos como ejemplo  el conseguir que la aguja del velocímetro se mueva por la escala. Para ello hay que aplicar unos cuantos conceptos de trigonometría. Si se tienen, es fácil dibujar esa aguja móvil, pero si no se tienen, por mucha experiencia de programación que se tenga, no se será capaz de hacerlo.

Concretamente: las siguientes siete instrucciones de Visual Basic dibujan la aguja del velocímetro que vemos dentro de cada una de las ventanas de control de locomotora.

     Picture1.DrawWidth = 4
     Picture1.ForeColor = &HFFFFFF
     Picture1.FillColor = &HFFFFFF

     Picture1.Circle (0, 0), 6


     Grados = (VeloActual / VeloFondo) * 270
     Angulo = (225 - Grados) * 1.74532925199433E-02 'radianes
     Picture1.Line (-20 * Cos(Angulo), -20 * Sin(Angulo))-(51 * Cos(Angulo), 51 * Sin(Angulo))

Las tres primeras lineas establecen cómo se va a dibujar: Con trazo de grosor 4, con color blanco, y con color de relleno blanco.

La cuarta instrucción dibuja el circulito blanco que se sitúa en el punto de giro de la aguja.
En la quinta instrucción calculamos la proporción entre la velocidad actual, la que debe indicar la aguja, respecto de la velocidad de fondo de escala. Esta proporción aplicada al total de grados que abarca la escala, 270, nos da el número de grados que debe moverse la aguja.

En la siguiente instrucción cambiamos esa cifra de grados a radianes obteniendo el valor "Angulo"

Y en la última linea dibujamos la línea que representa la aguja trazando una línea entre dos puntos cuyas coordenaedas son: x=-20 * Cos(Angulo),    y= -20 * Sin(Angulo)    y    x=51 * Cos(Angulo),    y=51 * Sin(Angulo).

Observese que se está dibujando en el objeto "Picture1" que en una fase anterior se ha definido como un control de tipo picture con un sistema de coordenadas con el origen en el centro y 200 unidades de ancho y alto

El resultado se puede apreciar en el vídeo adjunto

Como se ve, intervienen las funciones trigonométricas seno y coseno, así que hay que tener claro su significado. Como antes decía, no hay nada mágico. Hay que calcularse el ángulo que debe tener la aguja, las coordenadas de los puntos extremos y dibujar una linea entre esos dos puntos extremos con un determinado color, y un determinado espesor. Realmente en programación, para dibujar, sólo hay dos instrucciones Line y Circle. Las dos las he usado aquí, y no hay ninguna más, asi que cada dibujo que queramos ver hay que componerlo a base de estas dos instrucciones.

Realmente estas dos instucciones corresponden a una regla y a un compás, y como sabemos, esos son los dos únicos instrumentos imprescindibles para dibujar.

Y para que la aguja realmente se mueva, el truco es el mismo que el del cine o la televisión: La aguja se está dibujando continuamente, cada vez en la situación que corresponde a la velocidad en cada momento. Esto también es poco habitual en programación: Realmente el programa está permanentemente metido en un bucle que redibuja continuamente los elementos gráficos que cambian. Por ejemplo en la esquina superior derecha de la pantalla de la cabecera vemos un cronómetro que va calculando los minutos y segundos que lleva funcionando el programa. Los números van cambiando porque el programa redibuja continuamente las cifras.

Si nos fijamos, en el caso de la aguja del velocímetro, hay una variable, de nombre VeloActual que determina la posición en que debe aparecer la aguja. Cada vez que se ejecutan esas instrucciones se dibuja la aguja de acuerdo a este valor. Se trata de una variable analogica, porque realmente su valor corresponde a la velocidad teórica de la locomotora en Kilómetros/hora, que varía de forma continua entre cero y el valor máximo.

En otros casos la variable es de tipo digital, por ejemplo un semáforo de dos luces, puede lucir en rojo o en verde.por lo que la variable que dice como se debe dibujar, solo puede tener dos valores. Bueno en realidad tiene cuatro posibilidades: encendido el rojo, encendido el verde, encendidos ambos y apagados ambos. Pero en todo caso, se trata de una variable entera que solo admite unos pocos valores. En este caso 0, 1 o 2 (el caso de los dos apagados no se contempla) Tratándose de semáforos, el nombre de esta variable es "Aspecto".  Si algún lector se pregunta cuando se muestran encendidos simultáneamente el rojo y el verde la respuesta es que se muestran así en el modo de diseño, es decir cuando el usuario está definiendo que en una determinada posición, va un semáforo.

Bueno pues la rutina que dibuja un semáforo es la siguiente:

Case 1 'semaforos dos aspectos


    Destino.DrawWidth = Grueso
    Destino.Line (x - 3 * a, y)-(x + m, y), Negro 'palo
    Destino.Line (x - 3 * a, y + n)-(x - 3 * a, y - n), Negro 'base


    Destino.DrawWidth = Grueso * 4
    Destino.Line (x - m, y)-(x + m, y), Negro ' cabeza

    Destino.DrawWidth = Grueso


    Select Case Aspecto
        Case 1
            Destino.Circle (x + m, y), Grueso / 1.6, Rojo
        Case 2
            Destino.Circle (x - m, y), Grueso / 1.6, Verde
        Case Else
            Destino.Circle (x + m, y), Grueso / 1.6, Rojo
            Destino.Circle (x - m, y), Grueso / 1.6, Verde
    End Select



Ya sé que para la mayoría de los lectores, el presentar aquí estos segmentos de código puede resultar aburrido, pero, insisto, lo hago para aquellas personas que tengan conocimientos de programación, y que tengan curiosidad por saber cómo se pueden hacer este tipo de programas con gráficos móviles. Vemos como aquí la variable "Aspecto" hace que ejecuten unas u otras instrucciones del último bloque, y que en definitiva están dibujando un circulo de color rojo o verde.

Esta rutina es polivalente, ya que se usa para dibujar semáforos en más de una situación de programa. Por eso se usa la variable Destino que indica dónde hay que dibujar en cada caso. Las variables x e y especifican las coordenadas donde debe hacerse el dibujo, a es la altura del poste y m es la altura de la cabeza del semáforo. La variable "Grueso" indica el espesor de las líneas de dibujo, y las variables "Rojo", "Verde" y "Negro" contienen la definición binaria de esos colores.

Y naturalmente, el caso de los desvíos es análogo. Una variable, que por cierto también se llama "Aspecto" dibuja las lineas correspondientes a la posición del desvío. Hay desvíos con dos aspectos, y otros con tres, caso de los desvíos triples.

De hecho cualquier segmento de vía se dibuja igual que un desvío ya que puede corresponder a un trazo vertical, horizontal, inclinado a derecha, inclinado a izquierdas, y todas las combinaciones de esquinas que permiten cerrar los dibujos. Sin embargo, los tramos simples no tienen aspectos, por lo que se dibujan siempre igual, a diferencia de los desvíos.

Seguramente algún lector que tenga experiencia en programación se habrá visto sorprendido por el hecho de que el programa dibuja CADA VEZ cada elemento utilizando las instrucciones Line y Circle para dibujar las imagenes. Cuando se hacen cosas parecidas a esta, muchos programadores realizan previamente una gran cantidad de imágenes, utilizando un programa de dibujo (Paint o PhotoShop, por ejemplo), almacenan todas estas imágenes, y luego durante la ejecución presentan unas u otras imágenes en el lugar oportuno. Mi experiencia es que ese tipo de sistemas resultan más lentos, y mucho más difíciles de mantener, pero sobre todo, el dibujar los elementos cada vez durante la ejecución tiene la enorme ventaja de que puede dibujarse a cualquier escala sin más que dar un nuevo valor a las coordenadas. De esta forma se consigue muy sencillamente que se pueda hacer zoom sobre cualquier zona del dibujo y a cualquier grado de ampliación. También es posible utilizar colores variables con significados apropiados porque en definitiva para la rutina de dibujo los colores son variables cuyo valor le viene dado.

También es facilisimo adaptarse a las distintas resoluciones de pantalla. En la imagen de cabecera de este artículo vemos la imagen del programa en un ordenador de sobremesa con pantalla de 1280 x 1024 pixels, pero como contaba en mi anterior artículo, no he tenido la menor dificultad eh hacerlo funcionar en un pequeño ordenador con bastante menos resolución, incluso con proporciones distintas, ya que tiene una pantalla apaisada, tal como vemos en la fotografía de cabecera de mi anterior artículo (Un hito).

Si algun lector, que estaba considerando la posibilidad de hacer un programa para controlar su maqueta, se ha asustado al leer todo lo anterior, le hago la advertencia de que hacer un programa de la forma en que yo lo he hecho, es realmente un lujo, ya que el programa está hecho como si fuera a venderse, es decir que permite definir cualquier trazado de vías y colocar los desvios, señales, y demás elementos que sean necesarios. Esto está muy bien, porque permite hacer modificaciones con toda facilidad, y tiene las ventajas que he comentado en cuanto a la posibilidad de zoom y la adapatación a distintas resoluciones de pantalla, pero realmente se puede hacer un programa mucho más sencillo, si nos conformamos con que sea hecho específicamente para una determinada maqueta, y para una determinada resolución de pantalla. En un próximo artículo trataré más extensamente este tema.

Claro que aquí viene la segunda parte: ¿Como hacemos para que esas "ordenes" que el programa envía salgan del ordenador y lleguen a mover un desvío en la maqueta? Aunque parezca raro, esto es muchísimo más sencillo que lo que hemos explicado hasta ahora, pero de eso trataremos en el artículo siguiente.

Encoder (otra vez)

Creo que este es el tercer artículo de este blog que lleva el título de Encoder, y es que como ya advertí en el primero, (Encoder) dedicado a un encoder digital que genera un código binario para identificar la baliza que se ha activado al paso de un tren, esta palabra se utiliza para varios elementos. También hace poco he hablado de los encoders mecánicos incrementales al referirme al Mousecab y de la extraña forma que tienen de comunicarse con el mundo.

Bueno, pues hay todavía otro elemento, parecido al anterior pero que se denomina "encoder mecánico absoluto" La diferencia es que mientras el encoder incremental, que tiene solamente tres patillas, va produciendo pulsos al mover el eje, en un sentido o en otro, el absoluto, que tiene mas patillas, lo que hace es presentar en esas salidas una codificación binaria de la posición del eje.

Por ejemplo el que vemos en el video es un encoder absoluto de 24 posiciones. Eso quiere decir que según cual sea la posición del eje, aparece en sus cinco salidas, la codificación binaria de un número de 0 a 23 que nos indica en qué posición está el eje. Como vemos en el video, al ir girando el eje, va cambiando la salida representada aquí con cinco leds.  Estos encoders son también de giro infinito en ambos sentidos, pero a diferencia de los incrementales podemos saber la posición del eje y no meramente que el eje se ha movido como en los incrementales.

Bien, pero el mundo de los encoders tiene sus caprichos, así que uno esperaría ver en el video, como, al ir girando el eje, se visualiza una secuencia de números binarios de cinco dígitos en orden creciente, o sea la secuencia 00000, 00001, 00010, 00011, 00100........ Y como se puede comprobar esa secuencia ordenada de números binarios no es lo que vemos.

En primer lugar hay un motivo evidente, y es que las patillas del encoder no están colocadas en orden, de manera que los dígitos que vemos, de arriba a abajo en el vídeo son: 4, 2, 1, 3 y 5, así  que esto ya despista totalmente.

Pero hay otra razón todavía más poderosa: La salida de este dispositivo no es un número entre 0 y 23 en código binario, sino en código gray.

Para mis lectores que no lo sepan aclaro lo que es el código gray. En primer lugar aclaro que hay que decir gray y no "gris" como dice mucha gente, porque esta palabra que viene, como no, del inglés, no hace referencia al color gris que se escribe grey en inglés, sino a su inventor Frank Gray, y por lo tanto no hay que traducirlo como gris.

El tema es el siguiente: antes he reproducido la serie de los cinco primero números expresados en código binario. En el dispositivo, tendría que ocurrir que al ir pasando de la posición 0 a la 1, luego a la 2, etc viésemos aparecer esos números binarios en forma de leds encendidos y apagados. Pero fijémonos lo que ocurre cuando pasamos de la posición 3  a la 4. Los leds tendrían que pasar de la posición 00011 a la posición 00100. Es decir varían tres dígitos para pasar de indicar 3 a 4. Si consideramos que este es un dispositivo mecánico es imposible que esos tres dígitos cambien exactamente al mismo tiempo, de manera que por ejemplo, al menos durante microsegundos, tendríamos valores como 00010  o 00101 hasta que se estabiliza en 00100. Un sistema que va a ser leído con un dispositivo electrónico podría entonces dar lugar a lecturas erróneas.

Entonces al señor Gray se le ocurrió hacer una codificación que representase los número por medio de una codificación binaria, pero de tal forma que nunca variase más un dígito para pasar de un valor al siguiente o al anterior.

Por  ejemplo los números del 0 al 5 en código gray son:

000  001  011  010  110  111

Obsérvese que en efecto nunca cambia más de un dígito de un número al siguiente. Y obsérvese también que es un destrozo aritmético porque al pasar de un número de dos dígitos como son los cuatro primeros al primero que ya necesita un tercer dígito (110) las dos cifras de la derecha no son iguales que las del primer numero (00) así que esta forma de codificar números no es aritmética y no pueden por tanto hacerse operaciones de sumas restas etc, con esta codificación, al contrario de la codificación binaria con la que si se puede operar.

Evidentemente ser puede programar un algoritmo para convertir el código gray a binario y viceversa, y tengo entendido que algunos lenguajes de programación lo implementan como funciones, pero no es algo elemental.

Y seguramente algún lector estará pensando: "pero ¿dónde quiere ir a parar Ignacio con este rollo?". Bueno, como ya dije antes hablé hace tiempo de los encoders y en aquél artículo  de Abril de 2012 decía:
Uno de los más conocidos son los "posicionadores" que devuelven un código digital en función de la posición de un eje que puede girar........como por ejemplo el eje de giro del puente de una rotonda....(en que estaré yo pensando?)

Efectivamente estaba, y estoy, pensando en modificar el sistema de mando del puente giratorio de la rotonda de mi maqueta. Ya expliqué en su día (Julio de 2010 : Rotondas digitales) que mi programa manejaba la rotonda de mi maqueta, y luego se han visto algunos videos en que se la ve funcionar. La verdad es que funciona bien, pero el sistema se basa en que el programa acciona el motor del giro durante un tiempo determinado que se calcula a partir de la posición inicial del puente, la posición a la que queremos llegar, y el tiempo que tarda el giro del puente en cubrir el arco entre dos salidas. Pero claro, esto se basa en que el puente está situado inicialmente en el punto donde se quedó la última vez que se movió, y en que el motor se mueve siempre a la misma velocidad. El problema es que si el programa se interrumpe por cualquier motivo, la posición del puente no se guarda para la siguiente vez, y por otro lado es posible que el motor si está frío y hace tiempo que no funciona, se mueva más lentamente que si se ha movido recientemente.

Naturalmente la forma buena de hacer esto es que el programa sepa en todo momento la posición real del puente, y para ello resulta ideal uno de estos dispositivos, Si soy capaz de acoplar ese encoder al eje de giro del puente, voy a tener una señal que me indica permanentemente la posición del puente. No es por casualidad que haya pedido precisamente ese encoder de 24 posiciones, porque precisamente la rotonda tiene 24 vías en el círculo.

Me da mucha pereza levantar la rotonda y empezar a trastear con ella, pero ahora que voy a meterme con la colocación de balizas en la parte baja de la maqueta y también con el accionamiento de los desenganchadores desde el Mousecab, es el momento de hacerlo.

Más Archistories

En el artículo precedente, comenté que había encargado unos cuantos modelos de Archistories, para probar el sistema de construcción, basado en cartón cortado con laser. Después de la prueba efectuada en ese artículo con un modelo de taller de locomotoras, he abordado la construcción de los demás modelos, con el objetivo de adquirir la suficiente práctica para abordar la construcción de la rotonda, y también de comprobar la calidad final de estos modelos.

Lo primero que quiero decir es que el resultado final es excelente. Basta ver la imagen anterior para comprobar el extraordinario detalle que se obtiene con este sistema. Pero lo que también he podido comprobar, es que la elección del taller de locomotoras para comenzar, fué muy acertada, porque efectivamente el resto me está resultando mucho más delicado, y por lo tanto requiriendo un tiempo bastante largo. 

El puesto de enclavamiento que sirve de cabecera a este artículo, me llevó un par de sesiones de tres o cuatro horas, y en algún momento me encontré cerca del límite de mi capacidad como modelista. La escalera exterior por ejemplo, en la cual cada peldaño es una pieza distinta, es todo un reto. Este modelo tiene además detalles interiores, de modo que por las ventanas del piso superior se pueden ver las palancas que moverían las agujas.

Otro tema, es que, precisamente para que se vea el interior este modelo lleva iluminación, que naturalmente hay que dejar instalada antes de terminar el montaje.

El siguiente modelo que abordé fué esta estupenda torre de agua. El detalle sigue siendo impresionante. Esta vez fundamentalmente la dificultad estaba en la celosía de la estructura metálica, pero el resultado final es también espectacular.

Me temo que en estas fotografías no se llega a apreciar bien la perfección de estos modelos. Hay que pensar que se trata de modelos de escala Z, de modo que la altura total de esa torre, que reproduce lo que sería en la realidad un gran depósito de agua es menos de 10 cm, con lo cual las piezas más finas de la estructura de soporte tienen un espesor bastante menor que un milímetro.

Es curioso que tanto en este modelo como en el anterior, las partes que simulan ser de madera, son realmente de una finísima lámina de madera auténtica. En este, además, esta madera simula tener unas letras descoloridas, que deberían haber sido un anuncio o algo parecido.

Y de nuevo compruebo que, una vez montados, estos modelos son bastante resistentes, más de lo que cualquiera supondría para un elemento construido con cartón.

El siguiente modelo con que me enfrenté es una grúa para carbón Es un modelo también muy detallado, aunque quizá un poco menos perfecto que los anteriores. Me dio la impresión que quizá sea uno de los primeros desarrollos de la empresa.

Aquí, curiosamente la mayor dificultad está en la cabina de la grúa, que a mi modo de ver se ha hecho con demasiadas piezas para el tamaño que tiene, pero bueno, a base de pinzas y paciencia ha quedado bastante bien. Hecho de menos algún cubo o cuchara para cargar el carbón que debería poder cogarse en el gancho.

Asi que con estas "prácticas" me decidí por fin a abordar el montaje de la rotonda. La verdad es que una vez que le coges el tranquillo al sistema vas bastante rápido mientras no surjan puntos especialmente delicados como escaleras o celosías, que la rotonda no tiene. 

Anteriormente comenté que mi maqueta en construcción tenía el esquema de vias, previsto para la rotonda de Märklin que es de tres cocheras, mientras que la de Archistories es de cuatro. Pensé si sería posible montar la rotonda de Archistories  con solo tres vías, y al analizar el tema me di cuenta de que era perfectamente posible hacerla sólo con tres De hecho Archistories vende el módulo inicial para cuatro cocheras, y un segundo módulo para añadir una o dos cocheras más, por lo que puede construirse una rotonda con cualquier numero de cocheras.

Pero también me di cuenta, al presentar las piezas sobre el terreno, de que aunque construyera la rotonda con las cuatro cocheras, al final ocupaba incluso menos que la de Marklin. Esto es posible porque esta rotonda se sitúa bastante más próxima a borde del puente giratorio que la de Marklin, de manera que las puertas están más juntas y como las vías interiores son algo más cortas, se separan menos al final, con lo cual caben las cuatro en el espacio que la rotonda de Marklin necesita para tres.

Como ya comenté, tenía prevista una cuarta vía que si hubiese sido con la rotonda de Märklin hubiese ido por fuera, pero que ahora puedo usar como la cuarta vía de la rotonda. 

Así que con todo mi entusiasmo, me lancé a construir esta rotonda completa, hasta que tuve que parar por un detalle: Resulta que a diferencia de la rotonda de Märklin, esta tiene el techo fijo, no desmontable, de manera que una vez que se termina el montaje no se tiene acceso al interior. Entonces me di cuenta que si ponía ese techo, me iba a ser muy difícil poner las vías interiores, por lo que lo lógico es poner las vías antes, y luego terminar el techo.

Lo malo es que no puedo poner las cuatro vías en su base , y dejar el puente giratorio para más adelante, realmente para mucho más adelante, puesto que el tema del puente giratorio lo tenía pensado como una de las últimas operaciones de montaje. No se puede colocar el puente con las vías ya pegadas en su posición final: Hay que fijar primero el puente y luego ir colocando las vías una por una.

Así que me he visto forzado a colocar ya el puente, y dejarlo operativo y conectado a todas sus vías antes de poner la rotonda en su lugar, (o incluso esperar a más adelante para la rotonda, pero dejando ya las vías interiores milimétricamente posicionadas, para que la rotonda se pueda colocar sin problema en cualquier momento)

Con lo cual me he tenido que enfrentar con el problema del puente mucho antes de lo previsto. Y digo el problema del puente, porque éste tiene su historia. Proviene de mi segunda maqueta de escala Z  (ésta es la cuarta) En aquella (año 2007) el manejo de la rotonda se hacía con el mando que trae la propia rotonda, y que situé junto a los cuadros de mando que monté, o sea sin problema alguno. Sin embargo esta maqueta la desmonté y construí una nueva (la tercera) , cuya construcción se describe en los primeros años de este blog, Como esta maqueta tenía un sistema informático de control, la rotonda pasó a ser manejada como parte de ese sistema. Véase el artículo Rotondas digitales de Julio de 2010.

Así que ahora, lo primero que he tenido que hacer es darle un buen repaso a este veterano puente y ver si lo podía hacer funcionar. Y lo segundo es ver como resuelvo el sistema para manejarlo. Pero esto ya nos lleva muy lejos y será objeto de otro artículo