viernes, 28 de junio de 2013

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.

lunes, 17 de junio de 2013

Adagio




Cuando ponemos en marcha algún sistema nuevo, es habitual que las primeras veces ocurran fallos y desajustes que obliguen a continuas correcciones y que realmente hace que las pruebas resulten una sucesión de sobresaltos.  Esto es normal, sobre todo con un sistema complejo como puede ser la puesta en marcha de un sistema de control de trenes por ordenador en una maqueta de trenes. Cuando además el sistema es tan distinto de lo habitual como ocurre en mi caso,  no tiene nada de particular que haya costado un cierto esfuerzo llegar a ajustar todo el sistema.

Para mayor complicación, en este caso había que conseguir el funcionamiento coordinado de dos sistemas que aunque mucha gente confunde, son dos mundos distintos. Me refiero por un lado a todo el sistema de hardware (circuitos, sensores, etc.) y por otro al sistema de software (programas de control y  software de comunicaciones). Curiosamente me considero mucho más experto en software que en hardware, dado que el primero ha sido mi profesión, mientras que mis conocimientos de hardware son mínimos, y los pocos que tengo los he ido adquiriendo gracias a este hobby. Y digo curiosamente, porque me ha dado muchos más problemas el software que el hardware, pero también hay que tener en cuenta que de todos los trabajos que he abordado con el proyecto de mi maqueta actual, el más complicado, con mucho, es el programa de ordenador que controla todo el sistema.

Aunque seguramente tendré que hacer muchos retoques todavía, hoy puedo decir que ambos sistemas están funcionando perfectamente y perfectamente conjuntados. El video que encabeza este artículo, es una demostración evidente. Mientras grababa el video, los dos trenes que aparecen han estado funcionando controlados por el sistema sin un sólo fallo, Así que se puede decir que el sistema ha alcanzado el grado de estabilidad, que permite contemplar su funcionamiento relajadamente, y naturalmente, he querido añadir una música relajante al video para subrayar ese aspecto. Como ya he comentado en ocasiones anteriores, me gusta ver circular mis trenes a una velocidad que para muchas personas es muy lenta, pero que si hacemos el cálculo resulta totalmente real. De modo que para encontrar un acompañamiento musical adecuado he tenido que recurrir a una partitura con tempo de adagio

A los que tengan la paciencia de verlo, me gustaría llamar su atención sobre algunos aspectos:

La velocidad de los trenes está ajustada a la realidad, de manera que el tren de mercancías se mueve a una velocidad a escala de 90 km/h y el de pasajeros a 110 km/hora. En el video se les ve a una velocidad bastante real.

Como se puede ver, las frenadas ante los semáforos son suaves y progresivas. Las arrancadas son también bastante suaves, aunque algunas veces alguna locomotora tarda un poco en arrancar, de modo que cuando lo hace, ya toma una cierta velocidad.

En varios momentos se ve la pantalla del ordenador con el programa de control funcionando. Se pueden ver las etiquetas que van indicando el paso de los trenes sobre el trazado de las vías, y las dos cabinas de control. En estas últimas vemos moverse las agujas de los velocímetros automáticamente, y también las marcas de color de los cantones que van cambiando según se mueven las locomotoras.

También se puede apreciar algo poco habitual: El circuito que los trenes recorren tiene tres cantones, de modo que solo pueden circular dos trenes, que son los que vemos en el video. Lo habitual en un caso como éste es que viéramos un tren, el mas lento, que circula continuamente, encontrando todos los semáforos abiertos, mientras que el tren más rápido va circulando detrás, parando en todos los semáforos y esperando en cada señal, a que el tren lento que le precede, vaya liberando cada cantón.

Sin embargo lo que vemos no es eso: Por el contrario vemos que tanto un tren como el otro se paran en algún momento, haciendo una circulación más variada y menos previsible que lo descrito anteriormente. La razón de esto es que uno de los cantones es mucho más corto que los otros dos, de manera que incluso el tren más lento puede liberar ese cantón corto mucho antes de que el tren más rápido haya recorrido un cantón mucho más largo. Esto es totalmente intencionado y está hecho para conseguir una circulación de trenes más interesante.

De modo que ha llegado el momento de extender el sistema de control a toda la maqueta. Espero que en el próximo video podamos ver ya cuatro o cinco trenes circulando simultáneamente.


sábado, 1 de junio de 2013

¿Como funciona?





Mi último comentario acerca de los "encoders" ha hecho que me llegaran algunos comentarios que agradezco, entre otras cosas porque me ha llegado la existencia de algún circuito integrado que realiza la función de convertir la señal de un encoder incremental, a algo más tratable Concretamente las referencias son LS7083 y LS7084.  Ya me extrañaba a mi que no existiera algo tan evidente, así que agradezco mucho esa información.

Por otra parte, he seguido investigando por mi cuenta, porque me parecía que la solución por software a la que yo llegué era demasiado rebuscada. Bueno pues lo que si he localizado es más gente que ha hecho prácticamente lo mismo (en más de un lenguaje de programación) así que me quedo más tranquilo porque la idea que se me ocurrió no era tan exótica.

Si cuando empecé con los problemas, hubiera conocido la existencia de ese chip, me hubiese lanzado sobre él, pero la verdad, ahora que ya tengo el problema resuelto por otro lado y a la vista de la bien que funciona, lo voy a dejar como está, aunque me apunto la solución "hard" por si en el futuro me surge otra vez este problema.

También me han comentado la forma en que las centrales digitales comerciales resuelven el problema siguiente: Si yo estoy manejando una locomotora con un mando giratorio estilo potenciómetro (es decir que el giro tiene un tope inicial y otro final)  y la he llevado a una velocidad alta, el mando estará cerca de su tope superior. Si en ese momento paso a manejar otra locomotora que está parada, ¿cómo la hago subir de velocidad? Apenas puedo girar el mando porque estará cerca de su tope. Me han comentado alguna solución a este problema como la que utiliza el Multimaus, pero me parece complicada y artificiosa. Para mi la solución perfecta es la del encoder, porque un encoder no tiene topes y gira indefinidamente en ambos sentidos, de manera que cuando el mando se enlaza a una locomotora, el botón de velocidad, esté como esté, toma ese punto como correspondiente a la velocidad que tenga la locomotora, y a partir de ahí se puede hacer subir o bajar sin problemas. Por esto, desde el principio me empeñé en utilizar un encoder como control de velocidad. De hecho los encoders que utilicé los tenía comprados hace meses, pensando en uso como este.

Antes he dicho a la vista de lo bien que funciona, porque realmente estoy muy contento de como está funcionando mi sistema. Hoy he querido grabar un nuevo vídeo intentando demostrar el funcionamiento, pero me temo que lo haya conseguido solo a medias, porque realmente es muy difícil hacerse una idea si no es en vivo y en directo, a pesar de los videos.

Una de las dificultades que encuentro es el hecho de cuando tenemos dos trenes funcionando, si hago una toma general en la que se vea toda la maqueta y los trenes circulando en ella, los trenes resultan demasiado pequeños y casi invisibles. Por otra parte lo interesante no es seguir un único tren, porque lo importante es comprobar la interacción entre los trenes, es decir, como unos se paran mientras otro ocupan los cantones etc.

Se me ha ocurrido hacer un video en el que se vean simultáneamente dos trenes, dividiendo la pantalla por la mitad, y poniendo un tren en cada parte. La idea es que las dos imágenes deberían ser simultáneas, pero claro, eso supondría tener dos cámaras grabando simultáneamente, una cada tren. Como no tengo más que una cámara he hecho una pequeña trampa ya que las dos imágenes que se ven, corresponden en realidad a momentos distintos, aunque en ambos casos se estaba haciendo el mismo circuito. Al final resulta un poco mareante, pero es lo mejor que he podido conseguir para ilustrar lo que he llamado "modo automático"

En la imagen vemos dos trenes: Una BR53 con diez vagones de mercancías cerrados, y una BR18.4 con los coches de Rheingold. Al hacer el perfil de las locomotoras hay que dar el dato de la velocidad máxima de cada locomotora, de manera que para la BR18 la máxima velocidad es de 120 km/hora y para la BR53 es de 90 km/hora. (en realidad la BR53 no llegó a fabricarse así que el dato de velocidad máxima es estimado)

En el video vemos que efectivamente el tren de mercancías va bastante más lento que el Rheingold. Además sus aceleraciones son mucho más lentas, como corresponde a un tren pesado. Por otra parte, el Rheingold tiene programadas paradas en la estación, pero el mercancías no, aunque cuando pasa por la estación en sentido ascendente tiene programada una reducción de velocidad al 70%.

Todo esto lo vemos funcionar de modo completamente automático en la primera parte del video. Aparte de las paradas del Rheingold en la estación, vemos como se paran ambos trenes en los semáforos, haciendo paradas y arrancadas suaves y recuperando cada uno su velocidad con mayor o menor rapidez. La velocidad de cada tren corresponde exactamente a la velocidad máxima de cada locomotora, en este caso 90 y 120 km/hora excepto cuando pasa por tramos de "velocidad limitada".

En la segunda parte del vídeo vemos el modo "semiautomático" en el cual el usuario puede fijar una velocidad para cada tren a su gusto. Esta velocidad puede estar por encima o por debajo de la velocidad máxima de cada locomotora (con el límite del 130% de la velocidad máxima). En el video vemos que se ha puesto una velocidad muy alta para la BR53, que en esta ocasión va más deprisa que la BR18. El usuario puede cambiar la velocidad (incluso a velocidad cero) para cada locomotora en cualquier momento sin más que hacer click sobre el velocímetro de la pantalla de la Cabina. Esta velocidad que el usuario puede ir ajustando sobre la marcha a su gusto, se toma como "velocidad objetivo", es decir, que la locomotora acelera o frena tendiendo a alcanzar esa velocidad suavemente, de acuerdo con sus parámetros de aceleración e inercia.

Por fin, en la tercera parte, vemos el sistema funcionando en modo manual. Sólo un tren estará en manual y será manejado por el Mousecab, mientras que el resto de trenes seguirán en automático o semiautomático. Por supuesto se puede tomar el mando manual de cualquiera de los trenes.  En la imagen vemos como se maneja el Rheingold con el mouse mientras que el tren de mercancías funciona en automático. Vemos como el usuario maneja el Rheingold y lo detiene en la estación y también, como cuando el mercancías llega a la señal de entrada del cantón, se detiene, y no vuelve a arrancar hasta que el tren manejado manualmente libera el cantón. Obsérvese que las paradas y arrancadas son muy suaves, tanto en el tren manejado a mano como en el manejado automáticamente.

Y seguramente surgirá una pregunta: ¿Y si manejando manualmente el tren, llego a una señal en rojo y no paro? Pues en este caso, el tren se para solo. Lo que no hace es volver a arrancar solo cuando la señal se pone verde de nuevo. Cuando se produce esta situación, es decir cuando el tren, manejado manualmente, se para solo ante una señal en rojo, se enciende en la ventana de la cabina un piloto rojo que queda encendido mientras el semáforo está cerrado, y un piloto azul que se enciende mientras el tren está frenando. ¿A alguien le recuerda esto algo? ¿Por ejemplo al ASFA?