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

sábado, 21 de abril de 2012

Software de detección




Efectivamente, faltaba el software capaz de entenderse con la placa Velleman y detectar que un tren ha pasado sobre uno de los detectores.

Como ya he comentado anteriormente, el montaje informático que utilizo incluye, además del programa principal que es el que el usuario maneja, otro programa que permanece oculto, salvo que expresamente se quiera hacerlo visible, y que es realmente el que maneja las comunicaciones. Tan es así que de este segundo programa se abren varias instancias,  tantas como placas Velleman existan en la instalación.

Cuando este programa se hace visible, la pantalla del ordenador presenta un "log" de todos los mensajes que se envían y se reciben de la correspondiente placa de comunicaciones, lo cual es muy útil para comprobar el funcionamiento del sistema. Las comunicaciones entre este programa, y el programa principal son ya una cuestión puramente de software, de modo que no tiene más complicación que el adecuado desarrollo de los programas.

Bueno pues ya tengo desarrollada la parte de comunicaciones de este software, con lo cual se imponía una prueba global. Para ello he preparado el montaje que se ve en el vídeo, en el cual he situado dos detectores Hall en un tramo de vía.

Los Sensores los he montado en un trocito de circuito impreso de tiras perforadas que lleva un conector Molex, el detector Hall, y un condensador, según se recomienda en las hojas de datos del sensor Hall A1120EUA-T y  tal como puede verse en la imagen. De esta forma el sensor se introduce desde debajo del tablero a través de un orificio de 4 mm de diámetro, y al final se dobla su cabeza hacia atrás para dejarla horizontal entre las vías. Cuando lo haga en la maqueta, utilizaré una gota de adhesivo para dejarlo fijo.
De los tres cables que llegan a cada sensor, el negro es la masa, el rojo la alimentación (5 V), y el verde la salida de señal. Los cables rojo y negro pueden llevarse en plan guirnalda de un conector a otro. El cable verde, es el que hay que llevar individualmente desde cada sensor a una de las entradas del CODIF32. Para esta prueba, he puesto dos sensores Hall, y he conectado uno de ellos a la entrada 12 y otro a la entrada 19. Se puede ver aquí la conexión:
Cada uno de los conectores de entrada de CODIF32 tiene 10 vías, pero solo 8 son entradas. El primero y el último de cada conector son, uno de masa y otro de alimentación. Así se facilita el conexionado de los sensores. Las cinco salidas más la masa de CODIF32 se conectan directamente a la correspondiente regleta de entradas digitales de la placa Velleman. No hay ninguna indicación visual en la placa. del funcionamiento de estas entradas.

Y desde luego, el conexionado termina conectando la placa Velleman al puerto USB del ordenador.

En el vídeo, podemos ver como todo este montaje funciona perfectamente. Se puede comprobar que cada vez que la locomotora pasa sobre uno de los detectores, aparece un mensaje en la pantalla, indicando qué detector se ha activado. En el vídeo se hacen varias pruebas a distintas velocidades, sin que se pierda ninguna señal.

La verdad es que aquí había un tema pendiente muy importante. Como ya comenté hace tiempo, (Ahjjjj qué fallo y Laboratorio de eléctrónica), hay dos formas de que un programa de ordenador detecte que un dato de entrada ha cambiado. El método más perfecto es que el sistema produzca una interrupción o evento cada vez que el dato cambie. Los programadores de Visual Basic están acostumbrados a funcionar así. Por ejemplo cuando el usuario pulsa un botón en la pantalla se dispara el evento "click" del objeto "botón"  La otra forma de que un programa se entere de que una entrada se ha activado, se denomina en técnica informática polling,  consiste en leer periódicamente los valores de las entradas y detectar si ha habido algún cambio respecto de la lectura anterior. En el ejemplo anterior el programa analizaría constantemente el estado del "botón" para ver si su estado cambia.

Cuando, como es este caso, los datos que pueden cambiar proceden de un sistema de hardware, el método de interrupciones es muy difícil de implementar por lo que se recurre al polling.  En aquella ocasión,  un fiel seguidor de este blog, Marco Retama, aportó que estaba haciendo un sistema semejante al mío y que utilizaba un control timer de Visual Basic para hacer una lectura del estado de las entradas cada cierto tiempo. Evidentemente ese es el sistema, pero en su caso se trata de sensores de ocupación, mientras que en mi caso se trata de sensores de paso. La diferencia es que por pequeño que sea el bloque cuya ocupación queremos detectar, un tren estará mucho más tiempo sobre un bloque, que el tiempo que tarda en pasar sobre un detector de paso. Así que para el caso de Marco le bastaba leer las entradas cada décima de segundo. Sin embargo una décima de segundo es muchísimo par un detector de paso, porque el tiempo que está activado el detector puede ser menor, y puede ocurrir, que entre lectura y lectura se haya producido una activación y una desactivación, y el programa no lo detecta.

En un primer intento, hice exactamente eso, es decir un bucle de lectura con una frecuencia de 100 milisegundos. Al hacer las pruebas, comprobé que efectivamente se perdían lecturas.

El problema es que no se puede aumentar arbitrariamente la frecuencia porque llega un momento que el ordenador no hace otra cosa que leer y releer las entradas y se bloquean el resto de los procesos.

Este problema tiene dos soluciones completamente distintas: una por hardware que consiste en que una vez que una entrada se ha activado, se mantenga activada hasta que recibe una orden de volver a ponerse "a la escucha" Hay unos circuitos llamados latchs que hacen eso, pero me meto en tema de sincronismo que no me apetece nada. Sólo iré por ahí si no tengo otro remedio.

Quise quemar el último cartucho por el segundo camino, es decir, afinando la programación, y parece que lo he conseguido. La forma de hacerlo ha sido hacer la lectura en dos escalones. Un primer escalón hace solamente una lectura y detecta si ha habido alguna variación respecto de la lectura anterior. Si ha habido cambios, pone el nuevo dato en una variable. Así que esta variable funciona exactamente como un latch ya que mantiene el dato leído aunque en la lectura siguiente el dato vuelva a cero. Este ciclo de lectura se ejecuta cada 15 milisegundos. Un segundo ciclo, que se ejecuta cada 100 milisegundos detecta si el valor de la variable es distinto de cero y si es así actúa según lo previsto, dando el mensaje en pantalla, enviando este dato al programa principal, etc Y al final pone la variable a cero. Al ser la primera operación muy simple, su ejecución  es rapidísima de modo que no sobrecarga apenas el ordenador. Todo el trabajo pesado se deja al segundo proceso que se ejecuta muchas menos veces.

Este sistema tiene un posible problema: si dento de un ciclo de 100 milisegundos se producen dos entradas distintas y consecutivas del ciclo de 15 milisegundos, una de las dos, (la primera) se perdería. Esto supone que coincidan en la misma décima de segundo la activación de dos detectores distintos. Creo que la probabilidad de que esto ocurra es bajísima, así que asumo ese riesgo.

Y ¿porqué precisamente 15 milisegundos? Pues he detectado que aunque el programa intente leer las entradas con mayor frecuencia, el número de lecturas no aumenta. Está claro que lo que ocurre es que la placa Velleman tarda ese tiempo en proporcionar una lectura. Este es pues un límite insalvable. Si con 15 milisegundos de intervalo entre lecturas me vale para que no escape ninguna lectura, el sistema funcionará bien. Si no es así tendré que ir al latch por hardware

2 comentarios:

  1. Hola Ignacio

    Ya voy avanzando en mi maqueta y quiero empezar a hacer pruebas con la parte automática. He decidido utilizar los sensores Hall que tu mencionas y antes de pedirlos a RS necesito saber qué tipo de condensador tengo que pedir, ya que he intentado buscarlo en la hoja de datos y no he sido capaz de encontrarlo porque, exceptuando la primera hoja, las demás me salen en blanco

    Un saludo Miguel Pérez

    ResponderEliminar
    Respuestas
    1. Hola:

      Los condensadores que recomienda la hoja de datos son de 100 nF

      Un Saludo

      Eliminar

Gracias por expresar tus opiniones.

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