IDENTIFICAR PRIMER DATO DE LA TRANSMISION

[Santherberg]

Hola Amigos, 

tengo un problemilla con mi programa. Estay haciendo una estación meteorológica con un PIC16f877 y labview. 

identifico 8 variables que mi pic envia consecutivamente (sin separadores ni nada, lectura, almacenamiento en variable, envio de variables). Mi problema está en que labview no identifica el primer dato (temperatura) como el primero, el lugar de esto, toma como primer dato leido, por ejemplo, presion que correspondería al tercer dato.

Sé que existen formas de indicar a labview cual es el inicio y final de la cadena de datos, pero las desconozco y por más que he buscado información sobre ello no la localizo.

Por favor, podría alguien darme alguna pista o indicarme como puedo informarme sobre ello. 

(he tratado de usar temination char, pero no me sirve, la serie de datos se trunca y no obtengo el resuyltado deseado)

GRACIAS.

[HZRJ]

Hola Santherberg,

          Primero quiero comprender bien tu problema. Lees los datos en el pic, los guardas en variables y posteriormente envías estos datos. ¿A dónde se envían estos datos y cómo se envían? Si estás utilizando NI-VISA, la siguiente página te puede ayudar.

http://zone.ni.com/devzone/cda/tut/p/id/4256

          Espero que la información te sea de utilidad. Si pudieras explicar mejor tu problema podría buscar información más específica para ti. Si llegas a tener alguna pregunta no dudes en escribirme.

Saludos,

Héctor Rojas

[Santherberg]

Buenos días Héctor, gracias por tu respuesta.

Intentaré explicar un poco mejor mi problema.

Estoy desarrollando mi PFC que consiste en una estación meteorológica mediante PIC y LabView. La idea es tener una tarjeta de adquisición de datos mediante el PIC16F877. Este toma los valores de los puertos analógicos (temperatura, radiación solar y presión atmosférica), el tiempo del TIMER1 mediante el CCP1 y CCP2 (velocidad de viento y humedad) y los valores de un puerto digital (veleta). Estos valores los almacenos en sus respectivas variables para luego (al final de las adquisiciones) enviarlos todos consecutivos a LabView donde se realizarán los cálculos necesarios.

Envío los valores de los datos (que son bytes usando los 8 bits), unos tras otros sin identificadores ni nada.

EL PROBLEMA: El problema es que el PIC empieza a adquirir y enviar con normalidad. Cuando LabView inicia su funcionamiento lee el primer byte que le llega y lo asigna (conforme a mi programación) al que correspondería como primer dato y que en realidad no lo es, por lo que asigno, por ejemplo, al valor y cálculos de temperaturas, la captura de presión atmosférica. UN DESASTRE!!!.

LA SOLUCION: Mi intención es poder decir a LabView cuál es el primer byte que debe considerar como 1º, aunque no sé cómo hacerlo. He intentado documentarme y he leído que algunos dispositivos envían un dato de valor conocido (?, *, !, ...) que al leerlo determina el inicio de datos (aunque sigo sin saber cómo se hace en LabView), pero por otro lado, mis variables usan la resolución de los 8 bits. Como ?=d63=h3F, *=d42=h2A, o !=d33=h21, estos valores pueden corresponder a valores adquiridos como señal. ¿Cómo los diferencio entonces?

No sé si consigo explicar mi problema y la dificultad que encuentro en mi posible solución. Estoy seguro que existe una solución viable y que podéis orientarme a ello.

También he pensado que quizás no vea claramente la solución ya que no tengo una larga experiencia en LabView y puedo tener problemas de conceptos básicos (ya no descarto nada).

Voy a leer el enlace que me has enviado, aunque una vez explicado mi problema, si tienes otra aportación, será MUY AGRADECIDA.

Muchas Gracias Héctor.

[alipio]

Hola.

No es fácil imaginar el programa que has hecho en Labview. Por eso sería interesante que lo pusieses aqui para ver como lees y procesas los datos.

De esa manera Héctor o alguien podrian tratar de recomendarte soluciones, que haberlas, hailas.

Tambien da la impresión de que el PIC envia los datos a su aire, lo que no es recomendable.¿Tienes posibilidad de modificar el programa del PIC?.

Saludos.

Alipio

[Santherberg]

Buenas tardes Alipio, 

Puedo modificarlo todo, aunque debo reconocer que no me haria mucha gracias ya que me ha costado mucho llegar hasta aqui. Jajajaj He optado por esa forma de comunicacion del PIC ya que no tenía ninguna especificacion y desconocía por completo las posibilidades existentes, asi que opté (para ser sincero) por la mas sencilla. Luego he sescubierto sus defectos. Propones alguna idea al respecto.

Gracias. 

[Santherberg]

Os dejo el VI por si alguien puede ofrecer una solución.

Un saludo. 

[alipio]

Hola.

Aun no he visto la vi. Mientras tanto:

A falta de lo que opine Héctor, que de comunicaciones seguro que sabe más que yo, voy a proponertee algunas soluciones.

Asumo que estás usando un enlace serie RS232 normal y corriente y que los datos se envian en binario U8 (si los enviases en ASCII, no habria problemas).

Parece que el PIC habla continuamente y el Labview escucha a su aire. Poco más o menos como los políticos en cualquier país.
Es necesrio establecer un protocolo que les permita sincronizarse.

1.- No me parece muy inteligente que un PIC esté largando datos sin preocuparse de si alguien le escucha. Podrias modificar los programas de modo que el PIC solo envie datos si el Labview se los pide. En este caso no solo no tendrias problemas para identificar los datos puesto que sabes cuando llegan, sino que te permitiría mejorar el proyecto, ya que podrias solicitar datos cada n segundos y si se observa variaciones rapidas, aumentar la frecuencia de solicitud de datos.


2.- Tambien es posible enviar un comienzo de trama en la forma FFFF. Obviamente, ninguna variable podria adoptar este valor, que tendria que ser cambiado por FEFE. Se piede 1 bit en el nivel de saturación, pero ¿a quien le importa?.

3.- Otra opcion es evitar que el PIC envie datos no se sabe muy bien para quien. Tendrias que temporizar el envio de forma que enviase todas las variables en serie cada .....500 mS o similar. De este modo, Labview sabria que tendria que recibir los datos despues de un tiempo muerto y podria determinar quien es quien.

4.- enviar entre los datos unas secuencia fija de mayor duracion que los datos. Supongamos que los datos son 14 bytes. Enviar 28 nulos entre serie y serie de datos, por lo que labview sabria que despues de una serie de nulos, llegaran n datos conocidos.


Espero que alguna de esta sugerencias te sirva. En cualquier caso tendras que tocar el PIC. Y si las soluciones soft no te sirven, siempre te queda utilisar RTS/CTS para sincronizar el asunto.

Saludos.
Alipio.

[alipio]

Hola.

En principio, tendrás que modificar el PIC para que envie los datos segun alguno de los métodos que te dije.

Despues, tendras que modificar el programa para que acepte esoso datos.( el proceso de lectura actual no sirve).

Y deberas modificarlo para que funcione en modo simulado en PC que no tengan puesrtos COM. Ahora da error.

Cuando todo esté modificado, avisa y veremos de ponerlo todo en su sitio.

Saludos

Alipio.

[Santherberg]

Hola Alipio, sobre todo agradecerte tus sugerencias y ayuda. Por motivos de salud me ha sido imposible contestarte antes aunque si he leido tus sugerencias y son bienvenidas. 

En cuanto a las modificaciones del PIC: 

1ª.- Esta opcion me parece perfecta debo muestrear cada segundo por lo que podría requerirlo desde labview. El PIC deberia mantenerse a la escucha del puerto serie hasta que reciba una señal de labview para que inicie el proceso de muestreo o envio (ya que algunos procesos no tienen un tiempo determinado) ¿no es asi? Creo que podría hacerlo. 

2ª.- Eliminar un bit de resolucion para usarlo como caracter de terminación. Entiendo que para ello se comprueba el valor muestreado y si es FF lo cambiamos por FE. ¿es así de sencillo? En ese caso seria el caso mas sencillo de implementar de todos.

3ª y 4ª.- Estos casos no se como afrontarlos. Se que en ASCII existen unos caracteres llamados NULL y entiendo que puedas referirte a ellos ¿no? ¿Seria enviar una serie de caracteres NULL para completar tiempos? ¿en ese caso deberia usar envios en ascii? ¿o simplemente no hacer envios durante un tiempo? 

¿Estas opciones pueden complementarse? Si te parece empezaré con los casos 1 y 2 que creo que puedo afrontarlos.

Perdona estas dudas pero nunca me he enfrentado a esto y no he encontrado donde aprenderlo. 

En cuanto a Labview, no estoy muy suelto en ello y si que me presenta problemas  ya que no conozco bien sus herramientas por lo que para encontrar soluciones no siempre utilizo las herramientas mas apropiadas. 

La simulacion de datos la he empleado alguna vez en mi PC y si que me funciona, aunque no sean datos reales asi que no se te refieres a ese problema o es otro que has apreciado. 

Muchas gracias por tu ayuda, me pondré con la modificacion del pic en los puntos 1 y 2 y te avisaré para que me orientes con la modificacion de labview si no te importa, por que no tengo ni idea de como he de modificar el proceso de lectura. 

Un saludo y mil gracias.

Santherberg

[alipio]

Hola.
Espero y deseo que hayas superado los problemas de salud.

En mi opinión, la manera más elegante de hacerlo es usando el punto 1: que labview solicite datos cuando crea conveniente y que el PIC responda si los tiene . Puedes complementarlo con el punto 2, es decir, que la respuesta tenga un flag de comienzo FFFF seguido de los bytes que proveda. Y es así de sencillo. Que si algun valor de saturación fuese FF se cambia por FE en el PIC antes de su envio. Este metodo es viejo pero efectivo.

Para ver que todo funciona usa el programa que hay en este enlace

Una vez solventadas las comunicaciones con el PIC, seguiremos con el programa en labview. Fijate en la forma de comunicar que usa el hyperterminal, ya que tendras que implementar algo parecido en Labview.

En cuanto a la simulación, asegurate que si esta seleccionada, no haya nada que tenga que ver con comunicaciones serie como ahora. Si el PC no tiene puertos COM ( normal en los portátiles), el error VISA inicial evita que funcione.

Saludos.

Alipio.