Laboratorio de electrónica

En mi último artículo se me notaba un tanto "rebotado" ante las dificultades con las que me estaba encontrando con la placa de comunicaciones. Desde entonces han pasado un par de cosas que me han reconciliado un poco con el Mundo.

La primera es que he conseguido montar un programa fuente que funciona, a partir de los pedazos que me ha suministrado MicroPick. En efecto me han mandado los fuentes del programa para otra de sus placas y un formulario suelto del programa de la placa de PCB. Con esas partes, y algunos arreglos de mi cosecha, he conseguido un programa fuente que funciona, con lo que doy terminado el incidente, aunque la solución que me ha dado MicroPik dista mucho de lo que debería haber proporcionado.

Poco a poco voy montando más módulos del circuito demodulador, y todo va funcionando correctamente. La imagen de la cabecera, aparte de dar una idea del pequeño laboratorio de electrónica que me he montado, tiene muchos elementos interesantes.

En la pantalla del ordenador se ve (ampliando la imagen) que el dato de salida que el ordenador ha escrito en la salida es 11000001. En el ángulo inferior izquierdo vemos el demultiplexor, del cual he construido ya cuatro placas. Las direcciones de estas placas están ajustadas a 1100, 1101, 1110 y 1111 o sea precisamente las direcciones más altas. (Para los que conozcan  la notación hexadecimal, estas direcciones son C, D, E, y F). Se pueden ver en el detalle reproducido a continuación una etiquetas pegadas en cada placa con esta dirección)

El dato de salida como decía es 1100 0001. Los cuatro bits de la izquierda seleccionan la placa, luego habrán seleccionado la que tiene la dirección 1100. En efecto se puede ver el piloto de esa placa (la más a la izquierda de las cuatro, con la etiqueta "C") encendido mientras las otras están apagadas

También se pueden ver, a la izquierda de la placa de base,  unos leds verdes que reproducen el dato 1100 0001 que está emitiendo el ordenador

A la derecha, delante del teclado, hay otra placa, conectada a la salida de la placa decodificadora. Esta es una placa DEMU 04 que será la encargada de llevar relés para controlar la corriente de tracción en los apartaderos. No están puestos los relés, pero como tiene unos leds para ver que dato llega,  la utilizo para visualizar el funcionamiento. Se puede ver encendido un led verde, corrrespondiente a la decodificación de los cuatro bits bajos de la salida del  ordenador. En este caso 0001

En resumen, que todo funciona bien.

La otra cosa que me ha dado una buena noticia es la posibilidad de leer entradas de tipo analógico con esta placa. Yo había entendido que era una entrada analógica, pero en realidad son ocho, de modo que hay de sobra para construir algún tipo de mando que permita el manejo de los trenes con algún dispositivo mecánico (simplemente potenciómetros) y no exclusivamente con el ratón del ordenador.

Así que vuelvo a pensar en mantener la comunicación por USB, a pesar del tema de las lecturas de las entradas en modo polling. Mi amigo Marco Retama ha incluido un comentario en el artículo anterior, aconsejándome el uso de un control timer para leer periódicamente las entradas. Desde luego esa es la forma de hacerlo, pero sigo pensando que para detectar el paso de una locomotora sobre un reed, habría que hacer lecturas con una frecuencia muy alta para que no se escape el momento en que el contacto está cerrado.

Sin embargo, me he dado cuenta de una cosa: En los sistemas analógicos como el que acaba de publicar mi amigo Ángel en su blog el paso de las locomotoras sobre los reeds provoca el movimiento de unos relés biestables.....¡biestables! O sea que si una locomotora pasa sobre el reed,  la posición de un relé cambia y queda cambiada hasta que "algo" no lo restablece a la posición inicial. Por lo tanto poniendo unos relés de este tipo, puedo hacer lecturas de su estado con un intervalo de tiempo muchísimo mayor y con la seguridad de que no se me escapa ninguna detección. El "algo" que restaura los relés puede ser una orden dada por el programa, un vez que ha reconocido la posición de los mismos.

De hecho ni siquiera harían falta relés. Existen unos chips llamados precisamente "enclavamientos " (latch en inglés) cuya misión es justamente esa: Mantener indefinidamente un dato hasta que son restaurados. Creo que utilizando circuitos de estos se puede hacer un sistema de detección seguro y sin demasiadas complicaciones en la programación.

Mmmm.... ¡que cosa tan curiosa...! La palabra "enclavamiento" tiene un significado muy ferroviario, ya que se llamaban así los sistemas de mando mecánico para las agujas de las estaciones. Seguro que cuando los electrónicos hispanohablantes empezaron a utilizar la palabra "enclavamiento" como traducción de la palabra "latch" para denominar este tipo de circuitos electrónicos, no podían sospechar que un día, alguien como yo, podía llegar a utilizar un "enclavamiento" electrónico para simular la función de un "enclavamiento" ferroviario.

AHJJJJ! ¡qué fallo!

He comenzado con las pruebas del nuevo sistema, y debo decir antes de nada que todo va funcionando perfectamente (por ahora) así que estoy bastante contento con lo que he diseñado y construido.

Sin embargo me he encontrado con algunas pegas respecto de la famosa placa de comunicaciones por USB.  Así como las pruebas que hice el año pasado con las placas de comunicación por puerto serie no me dieron pega alguna, con esta si que estoy teniendo dificultades.

En primer lugar hay una cuestión estética:  Ya que la comunicación es USB, hay que meter un driver en el ordenador para manejar las comunicaciones con la placa. MicroPik suministra el driver, pero no se de dónde lo ha sacado, porque al cargarlo en Windows aparece un mensaje diciendo poco menos que que es pirata y que allá usted si carga eso. Mal empezamos. De todas formas yo cargué el programa, y aparentemente todo funciona bien.

El segundo tropiezo viene de lo siguiente: En la página Web de MicroPick dicen que con la placa se acompaña un programa para probarla y el código abierto (lo que los del negocio llamamos "los fuentes")  de ese mismo programa. Eso mismo ocurría con la anterior placa de comunicaciones.

Efectivamente el programa de prueba funciona bien y maneja la placa (al menos en cuanto a salidas, que es lo que me interesa) perfectamente, pero claro, no es más que un pequeño programa de demostración para ver que todo funciona.

Lo interesante para mi es disponer del código fuente del programa para a partir de él desarrollar los programas que yo quiero, tal como hice el año pasado. Sin embargo me encuentro con que el código que mandan está incompleto, y falta precisamente la parte más interesante que es la comunicación por USB.

Les he mandado varios correos y me están dando largas, pero no veo que vayan a darme una solución. Mala cosa. Y además inexplicable, porque si tienen el programa ejecutable que funciona bien, ¿porque no envían los fuentes de ese ejecutable.?

Quizá pudiera llegar a tener lo que necesito a base de hacer pruebas, pero me disgustaría tener que llegar a eso, cuando lo suyo es que me lo dieran hecho, tal como lo ofrecen.

De todas formas, ambos problemas pueden tener solución, pero esta tarde me he encontrado con un problema que no la tiene porque es un tema de concepto. Me refiero a la forma de captar las entradas digitales.

En la placa anterior que compré el año pasado, la captura de entradas digitales es por un evento. (el evento OnCom del control de comunicaciones). Esto quiere decir que sin hacer nada desde el programa, cuando el estado de las entradas varía, se activa el evento, y se puede programar hacer lo que se quiera. Sin  embargo con esta nueva placa, es el programa quién tiene que preguntar por el estado de las entradas y como respuesta, el microcontrolador de la placa le informa de su estado.

Seguramente mis lectores no se habrán dado cuenta de la importancia de esto. pero quedará claro de forma inmediata: Las entradas digitales están conectadas a los contactos reed que detectan el paso de los trenes, de forma que cuando una locomotora con imán pasa sobre uno de los reeds, se cierra el circuito y varía el estado de esa entrada. Pero ese estado cambiado dura unas fracciones de segundo, porque inmediatamente la locomotora ha pasado y el reed vuelve a su estado anterior.

Con el sistema de la placa por puerto serie, en el momento de que la locomotora pasa sobre el reed se produce un evento y el programa se entera siempre de que esto ha sucedido. En cambio si es el programa el que tiene que preguntar cada x tiempo por el estado de las entradas (de cada una de las entradas....) ¿cada cuánto tiempo tiene que preguntar por ese estado? ¿cada milisegundo? Está claro que es inviable, porque el programa no podría hacer otra cosa que averiguar el estado de las entradas. De hecho, en los aparatos que funcionan por impulsos  de corriente (los desvíos por ejemplo) el programa está parado mientras dura el impulso (típicamente 100 a 500 milisegundos). Como coincida una locomotora pasando por un reed en ese momento no se podría detectar su paso.

Resulta que en las centrales digitales comerciales, parece que también se da este caso, según algún comentario que he leído recientemente. Los usuarios se quejan de que falla la detección de trenes cuando hay mucho movimiento, y parece que las últimas versiones de centrales han corregido este defecto utilizando el sistema de eventos o interrupciones en lugar del "polling" que es como se llama la forma que exige que el programa muestree continuamente las entradas. No voy yo ahora a caer en ese fallo.

Total, que a pesar de que había pensado que esta placa era una buena solución. me estoy convenciendo de que más vale lo malo conocido, sobre todo cuando lo conocido no es malo. Lo bueno del caso es que todo mi diseño es perfectamente válido, tanto para la placa de puerto serie como para la USB, de manera que puedo continuar las pruebas con la placa de puerto serie, y si se resuelven los problemas del USB no habrá ningún problema en cambiar.

Lo que si es cierto es que los de MicroPik han caído varios enteros en mi apreciación. Ya veremos como termina este asunto, pero no me gustaría seguir dependiendo de ellos. De momento ya he pedido un libro de programación de microcontroladores.

Y... no he dicho nada de la fotografía de cabecera. Bueno no es más que una foto de las pruebas que voy haciendo, pero ha quedado bonita. A mi estas fotografías cercanas de aparatos electrónicos me parecen muy atractivas.

Esquemas eléctricos

A lo mejor alguno de los lectores de este blog, ha pensado que estoy ocultando una información, que se considera fundamental en todo proyecto eléctrico o electrónico. Me refiero, a los esquemas de los circuitos, que aparecen siempre en los proyectos de este tipo como paso previo`para definir el funcionamiento.

No es mi intención ocultar nada con respecto a estos temas, en primer lugar porque este blog tiene un carácter divulgativo, y en segundo lugar porque no me considero "inventor" de este dispositivo de control. *

Lo que ocurre es que mi método de trabajo, implica que en la mayoría de los casos realizo primero el esquema de la placa PCB, y posteriormente hago el esquema del circuito. Esto parece una extraña forma de trabajo, pero a mi me da buen resultado. Digamos que al tener que pensar sobre la forma de funcionamiento del circuito mientras diseño la placa, me facilita no cometer errores en ese diseño. Luego, hago un esquema del circuito, a partir de la placa construida, y muchas veces ya probada, de modo que el esquema tiene un carácter de documentación "as built" y su principal objeto es documentar el proyecto, sobre todo de cara a futuras revisiones. Además, al hacer el esquema a partir de la placa sirve también de verificación, ya que si hay algún error de diseño, suele detectarse fácilmente al tratar de hacer el esquema.

Por ejemplo, el esquema que encabeza este artículo, lo acabo de dibujar. Hasta ahora este esquema estaba sólo en mi cabeza, de modo que no me extraña que algún lector lo hay echado de menos al leer la serie de artículos que trata de este sistema de mando, particularmente del artículo "De nuevo con los voltios" . Ahora, contando con este dibujo, parece mucho más fácil explicar la teoría del sistema de mando, y la explicación podría ser esta:

En la parte superior, tenemos un ordenador que está ejecutando el programa "Control Z" Este programa envía señales al exterior por medio del USB hasta la placa de comunicaciones USB188. Esta placa que es la que suministra MicroPik, convierte el flujo de datos recibidos serialmente por el puerto USB en palabras de 8 bits que salen por el bus de datos (lineas rojas)

La placa DEMU 01 se conecta a los cuatro bits altos del bus de datos y, mediante el circuito integrado 74HC154 "demultiplexa" esos 4 bits altos en sus dieciséis códigos individuales, que constituyen los 16 bits del bus de control (líneas verdes)

La placa DEMU 02 se conecta también al bus de datos, pero lee los cuatro bits bajos y uno de los 16 bits de control (el bit de control se determina cerrando uno de los 16 microinterruptores que lleva esta placa) Solo se activa cuando el dato de control, que lee cada placa, está activado, es decir cuando coincide con la decodificación de los bits altos realizada por DEMU 01

Puede haber hasta 16 placas DEMU 02, siempre que cada una se conecte a uno de los 16 bits de control

Cada una de estas placas, lleva un circuito 74HC4514 que decodifica los cuatro bits bajos del bus de datos en sus 16 componentes individuales (líneas azules). La placa produce una salida de 12 voltios por la salida activada, de manera que puede llevarse directamente a actuar sobre elementos que funcionen con un impulso de corriente continua de 12 voltios. Típicamente utilizaremos estas salidas para mover los desvíos, utilizado dos salidas para cada desvío. Basta conectar los cables azules de los desvíos a dos salidas contiguas de una de estas placas. Quiere decir que cada placa DEMU 02 puede mover directamente ocho desvíos

Otra posibilidad es conectar las salidas de la la placa DEMU 02 a una placa DEMU 04. Esta placa lleva 4 relés biestables de 12 voltios con doble conmutador (DPDT) (Tyco Electronics V23079-B1203-B301)

Las seis conexiones a los contactos de trabajo quedan accesibles, de modo que pueden utilizarse de varias formas, ya sea como conmutador sencillo o doble, como inversor, etc. Hay un sistema formado por un zócalo de circuito integrado que permite configurar las salidas de la forma deseada mediante pequeños puentes.

Un uso típico de estos relés es manejar la alimentación de una vía de apartadero: La corriente de tracción (lineas de color naranja) se conecta o desconecta del tramo aislado de vía que queremos controlar, según la posición del relé. Como los relés tienen doble conmutador, se puede conectar en paralelo una señal luminosa o un semáforo que se abra o cierre según la vía tenga corriente de tracción o no.

Hay muchos más usos para estos relés. Se pueden conectar para manejar señales luminosas, para encender y apagar iluminaciones, para manejar rotondas y pasos a nivel, etc. Cualquier cosa que podamos encender o apagar en un panel de control mediante un interruptor o un conmutador, lo podemos manejar con uno de estos relés mediante una orden procedente del ordenador. Incluso con tensiones de 220 Voltios y hasta 5 amperios, así que por ejemplo podríamos llegar a manejar la iluminación de la habitación.

Cada relé utiliza dos salidas del DEMU 02, de modo que una placa completa DEMU 04 utiliza ocho de las dieciséis salidas de una DEMU 04.

Por último, la placa DEMU 03 sirve de cierre al bus, y lleva unos Leds para monitorizar la situación de cada señal..

También tengo dibujados los esquemas de cada una de las placas.

Aquí está el esquema de la placa de la placa DEMU 01 que también lleva el esquema de la placa DEMU03 (recuerdo que haciendo click, en la imagen se amplía hasta su tamaño original)

El siguiente, es el esquema de la placa DEMU 02

Y este es el esquema de la placa DEMU 04, la que lleva los cuatro relés:

Como se puede comprobar por las fechas, estos esquemas están recién realizados o modificados. Espero que se puedan considerar ya definitivos.

* Todo esto tiene su origen en una serie de mensajes intercambiados en el foro de LCTM en Marzo de 2008 ( Mensaje  49042 y siguientes ). Como se puede ver en esos mensajes yo no tenía ni idea de estos temas en esa época, y pude ponerme un poco en la página gracias a los mensajes de otros participantes en el foro. No es que ahora tenga mucha más idea, pero he podido dedicarle algo de tiempo (y dinero, claro) a los ensayos que me han llevado a este punto.