En mi último artículo, anticipé que estaba pensando en construir un mando portátil al estilo Multimaus, para manejar manualmente los trenes, con la posibilidad de alejarme del puesto de control.
Así que, dicho y hecho: la imagen de la cabecera muestra el aspecto de este elemento que he construido y al que le he dado el nombre de "Mousecab" . Evidentemente el nombre proviene de que tiene el aspecto de un "mouse" y emula la función de una Cabina de control de mi programa.
Como se puede ver, en la parte inferior hay tres pulsadores, en colores verde, negro y rojo que realizan las funciones de Adelante, Paro, y Atrás, duplicando así los botones "virtuales" que aparecen en la pantalla de la Cabina. Además, por supuesto, hay un mando giratorio que regula la velocidad del tren, y que como veremos en el vídeo, su movimiento se refleja en el control de velocidad de la ventana de la cabina.
En la esquina superior derecha hay un display que muestra el número de la cabina sobre la que está actuando el Mousecab. Evidentemente podemos cambiar la conexión a cualquier otra cabina, pulsando el botón de "Manual" en la Cabina. El cambio se señaliza en la pantalla porque el número de cabina pasa de verde a rojo, y en el Mousecab porque el display muestra, el número de cabina al que se ha conectado. (¡Para esto era el número de cabina grande que puse recientemente en la esquina superior derecha!)
Hay un botón azul, previsto ara actuar sobre un desenganchador, y facilitar así las maniobras, pero todavía no he modificado el software para que los desenganchadores obedezcan a este botón.
Técnicamente es relativamente sencillo, ya que me he limitado a seguir la misma técnica usada en el resto de controles y sensores de la maqueta. Por ejemplo, los cuatro botones funcionan exactamente igual que las balizas que detectan el paso de los trenes. Al pulsar uno de los botones se pone a masa una entrada de un circuito multiplexor, en este caso un 74HC148 que envía un código de tres dígitos a la entrada de una de las placas Velleman que se encarga de transmitir esta señal al ordenador. El programa está haciendo polling sobre esa entrada, de manera que cuando se reconoce un dato el programa lo detecta y sabe cómo actuar. Es el programa el que sabe sobre qué cabina hay que actuar en cada momento, ya que el dispositivo es "tonto"; se limita a decir, por ejemplo se ha pulsado el botón 3 y todo lo demás, es decir que función hay que hacer sobre qué cabina, es por software.
Análogamente, la visualización en el Mousecab del número de cabina sobre la que actuará en cada momento, es fundamentalmente por software, de manera que es el programa el que controla que cabina está conectada al mouse en cada momento, si es que hay alguna conectada. Así que el programa produce una señal permanente (tres bits) que se envía a la misma placa Velleman y que genera en la salida la señal correspondiente, que se lleva hasta el Mousecab. Como sólo envío tres bits el display sólo puede visualizar los dígitos 0 a 7, de modo que el 8 y el 9 no pueden aparecer. Realmente no los necesito, porque el máximo número de cabinas en mi programa es de 6, correspondientes a los seis controladores PWM que tengo instalados. Podía haber previsto los cuatro bits que se necesitan para mostrar el 8 y el 9, pero al ahorrarme un bit he podido utilizar cables y conectores de 9 vías, es decir, he utilizado los cables y los conectores que se emplean (más bien se empleaban) para las conexiones por puerto serie de los ordenadores.
La imagen siguiente muestra el aspecto del circuito que he montado, en vista frontal y trasera. En la cara delantera vemos los tres circuitos integrados que lleva, y que son el multiplexor 74HC148, que ya he comentado, el decodificador 75HC4511 que genera las señales para los siete segmentos del display, y un inversor 74HC14, porque como siempre la señal que generan las placas Velleman está invertida.
En la cara posterior se aprecia que se trata de un circuito impreso bastante compacto, pero ha quedado de un tamaño muy apropiado, como para meterlo en un caja que cabe en la mano cómodamente.
En el vídeo que aparece a continuación vemos las primeras pruebas de este elemento. Inicialmente vemos como los controles que se visualizan en la pantalla del ordenador responden a los movimientos de los mandos del mouse. Realmente, es curioso este efecto, porque salvo el ratón, no estamos acostumbrados a ningún dispositivo que interaccione de esta forma con la pantalla del ordenador. Luego vemos ya como manejamos un tren con el Mouse y realmente se hace una buena demostración de movimientos lentos del tren que aparece en la imagen.
Y ahora voy a contar una historieta, que ha sido la que mayores quebraderos de cabeza me ha dado en todo este tema. El mando giratorio que tenemos en el centro y con el que manejamos la velocidad, no es un potenciómetro, sino un encoder. Concretamente lo que se llama un encoder incremental mecánico. Ya en mi artículo Encoder mencionaba yo, que esta palabra se empleaba también para designar unos dispositivos que detectan la posición o al menos el giro de un eje.
Efectivamente este es un dispositivo que tiene tres terminales, de los cuales el central es de masa, y los otros dos se conectan a masa momentáneamente según el eje gira, de manera que si movemos el eje constantemente se producen una serie sucesiva de puestas a masa, en definitiva de impulsos, que se pueden llevar a un dispositivo que los interpreta y actúa en consecuencia.
Mi problema fue que pensé que girando el mando en un sentido se producían estos contactos a masa en uno de los terminales, y girando en sentido contrario, se producían en el otro terminal. Hice una prueba rápida con un polímetro y me convencí de que así era, pero debió ser una prueba demasiado rápida, porque me llevó a engaño. Lo malo fue que diseñe y construí todo el aparato con esta idea.
Así que cuando lo probé, me encontré con que no funcionaba como yo esperaba. Después de unas cuantas pruebas y de investigar por Internet, me enteré que estos elementos funcionan de la siguiente forma: Cuando el eje gira, se producen en efecto, puestas a masa de los terminales, pero tanto si giramos en un sentido como en otro, se producen en ambos terminales. La diferencia está en que una de las series de "puestas a masa" está desfasada respecto de la otra, de modo que girando en un sentido la serie del terminal 1 va por delante de la del terminal 2 y girando en sentido contrario, la serie del terminal 2 va por delante.
La verdad es que me parece una cosa supercomplicada, y parece ser que la razón está en que el origen de estos aparatos está en elementos industriales destinados a controlar el movimiento de un eje que gira. Si leemos solamente uno de los terminales tendremos una serie de pulsos, ya sea el giro en un sentido o en otro, y sólo con ese dato ya podemos calcular la velocidad. Si además queremos conocer el sentido, entonces leemos el segundo terminal y por el desfase conocemos el sentido. Vale, pero eso es correcto para decoders industriales que se conectan al eje de una maquinaria, y que por cierto no son mecánicos sino ópticos o magnéticos. Pero cada vez se emplean mas estos decoders mecánicos en sustitución de los potenciómetros, fundamentalmente porque su salida es de tipo digital, con lo cual se adaptan mucho mejor a la tecnología digital. No se si existen decoders mecánicos que funcionen como yo pensaba, pero me parece que no, así que he tenido que pensarme cómo utilizaba esa complicada señal para saber algo tan sencillo como el determinar el sentido de giro del mando.
En la figura previa, vemos el tipo de señal generada por uno de estos encoders según se hace girar el eje. La señal A es la que aparece en uno de los terminales, y la B la que aparece en el otro terminal. Si el eje gira en un sentido las señales aparecen tal como las vemos leyendo de izquierda a derecha, así que la señal B está retrasada respecto de la A. Si giramos al revés es como ver la imagen de derecha a izquierda, así que la señal A es la retrasada respecto de B.
Lo que he hecho es considerar estas dos señales como dos dígitos de un código binario, siendo la A el bit más bajo y el B el más alto. Así que si empiezo a girar el mando en un sentido, se genera la secuencia de códigos binarios 00 01 11 10 00 01 11 10 00 ........... o bien si lo expresamos en decimal, la secuencia es 0 1 3 2 0 1 3 2 0 ..............
Por el contrario si lo hacemos girar en sentido inverso, la secuencia que se genera es 0 2 3 1 0 2 3 1 0...
Como estoy haciendo la lectura por polling, voy haciendo lecturas con una frecuencia dada y comparo cada lectura con la anterior. Si ha habido un cambio de valor, determino cuales son losvalores consecutivos leídos. De modo que si las parejas de valores consecutivos leidos es una de estas: 0-1 o 1-3 o 3-2 o 2-0 está claro que se está generando la primera de las secuencias, así que el mando está girando hacia la derecha. Por el contrario si leo cualquiera de las siguientes parejas de valores consecutivos: 0-2 o 2-3 o 3-1 o 1-0 será porque se está generando la segunda secuencia, así que el mando está girando hacia la izquierda.
Naturalmente si la lectura del polling es mucho más lenta que la frecuencia con la que cambian los valores, se perderán muchos valores intermedios, con lo cual el método deja de funcionar. Lo malo de esto, es que la frecuencia de los valores depende de lo deprisa que se gire el mando, así que si giramos el mando muy rápidamente la frecuencia supera la del polling y se pierden lecturas.
Afortunadamente he podido comprobar que con una frecuencia de polling de 15 milisegundos y moviendo el botón con calma el sistema funciona muy bien, tal como se comprueba en el vídeo. No tiene sentido mover rápidamente el mando porque eso supondría querer cambiar la velocidad de la locomotora de una forma excesivamente rápida.
De modo que al final he salido airoso de mi primera incursión en el mundo de los decoders. Pienso que posiblemente haya algún tipo de circuito integrado que interprete las señales del decoder y presente una salida más tratable, pero desde luego yo no lo he encontrado.
