ESTE BLOG COMENZÓ A PUBLICARSE EN 2008, POR LO TANTO MUCHOS DE LOS TEMAS HAN QUEDADO DESACTUALIZADOS U OBSOLETOS. LOS LECTORES QUE DESEEN UTILIZAR ALGUNO DE LOS ELEMENTOS AQUI DESCRITOS DEBERÏAN ASEGURARSE DE BUSCAR LAS REFERENCIAS MAS MODERNAS DE LOS TEMAS DE SU INTERÉS. EL BUSCADOR INCLUIDO SERÄ UNA AYUDA PARA ESA BÚSQUEDA

domingo, 20 de junio de 2010

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.

2 comentarios:

  1. Hola Ignacio,
    Acotando a lo que has explicado en esta publicación, te cuento que he estado colaborando con un amigo ferromodelista que utiliza un sistema para control de maquetas llamado CMRI (quizás has oído hablar de él). Mi amigo usa trenes para 2R con control por DCC.
    Pues en ese sistema se tiene que crear un loop cerrado para estar leyendo los detectores de ocupación (inputs). Luego, según el estado de los detectores, se calcula cuál es el aspecto que deben tener los semáforos de la maqueta y la posición de algunos desvíos, se empaquetan los comandos para encender los semáforos en la forma calculada y operar los desvíos y luego se envía esta información al sistema (outputs), a la vez que se actualiza un panel de control virtual que está en pantalla. Luego hay que comenzar de nuevo leyendo los detectores.
    La programación la estoy haciendo con Visual Basic 6.0, y lo que he hecho, para que el lazo principal del programa no bloqueé los demás comandos que puden darse en el programa, es usar un timer. El timer ejecuta la subrutina de lectura, cálculo y envío de comandos. El asunto es que el timer nos ha permitido calibrar bien, la frecuencia de ejecución del lazo principal (cada décima de segundo) sin que ello impida ejecutar otros comandos.
    Un abrazo desde Costa Rica

    ResponderEliminar
  2. Hola Marco.

    Gracias por tu aportación, Veo que estás un tema parecido al mío.

    Si, efectivamente, con un timer, se pueden leer las entradas con un periodo de tiempo ajustable. El problema es que en mi caso, las entradas varían muy rapidamente, (lo que dura el cierre y la apertura de un reed cuando una locomotora pasa por encima. Eso puede ser del orden de una décima de segundo) Para tener la seguridad de pillar el momento en que está cerrado, tengo que hacer el bucle de lectura con una frecuencia muy alta, del orden de una centésima de segundo, y eso me va a ocupar demasiado tiempo de proceso.

    Estoy pensando alguna solución alernativa, y creo que ya tengo alguna en mente. En los próximos días hablaré de esto.

    ResponderEliminar

Gracias por expresar tus opiniones.

Los comentarios aparecerán en el blog normalmente en unos pocos segundos