Discusiones sobre Productos NI
Decodificar un protocolo serial
Que tal amigos del foro:
Tenemos una aplicación en la cual tenemos que monitorear en LabVIEW unas celdas de carga que se comunican via RS-422 para indicar el peso. No existe información disponible respecto al protocolo que estas manejan, pues es información propietaria del fabricante, y la idea es reemplazar el sistema de control actual. No conocemos la velocidad de transmisión de datos ni detalles adicionales, solo sabemos que es RS-422
Tenemos un equipo que permite escuchar lo que es transmitido por el bus RS-422 y tenemos registros de esta información. Ahora estamos analizando esta información. Al momento no hemos podido encontrar alguna secuencia lógica en la información. Hemos buscado los valores de peso que aparecen en el sistema actual, codificados de alguna forma dentro de los registros, pero no hemos encontrado nada.
Me pregunto si alguien ha alguna vez desarrollado una aplicación similar o ha trabajado en un proyecto con estas características, para saber como han atacado y/o resuelto el problema.
Cualquier idea es bienvenida.
Saludos.
Robst.
Hola Benjamin:
Gracias por responder.Intentamos contactar al fabricante por todos los medios posibles, pero la respuesta, tanto del fabricante como de sus distribuidores ha sido negativa, la información respecto al protocolo no es pública, y la unica opción que ofrecen es reemplazar las celdas por otras con protocolo abierto.
Como comentas, efectivamente tenemos un software para monitorear lo que se transmite por el bus RS-422 y ya tenemos algunos registros. Por desgracia, no conocemos los parámetros de la comunicación (baud rate, data bits, parity, stop bits, flow control). ¿Sabes si existe alguna forma de determinar estos parámetros a través de los datos? ¿O tendremos necesariamente que muestrear con cada posible combinación de parámetros?
Saludos!
Robst.
Que tal Rodrigo:
Gracias por responder. No se si me pudieras dar una respuesta más detallada respecto a como puedo hacer ese análisis de la señal RS-422 en un osciloscopio. Cuales serían los pasos a seguir para hacer el análisis.
Te agradezco de antemano tu respuesta.
Saludos.
Robst.
Recorde haber visto algo parecido espero que te ayude
http://www.automationdirect.com/static/manuals/d006usermsp/appxk.pdf pagina 5
Gracias Antonio por el documento, muy bueno, y gracias Rodrigo por la sugerencia de usar el osciloscopio.
Trataré de conectar las señales del bus RS-422 a un osciloscopio para hacer el análisis que sugieren. Por ahora solo cuento con los datos que registramos a traves del adaptador para escuchar el bus y su software, y como no existe certeza de que el software este configurado con los settings correctos, los datos interpretados por el software podrían estar mal.
En cuanto pueda hacer estas pruebas, publico aqui resultados.
Mientras tanto cualquier otra idea o sugerencia para decodificar el protocolo es bienvenida.
Saludos!
Robst.
Buenas noches,
Yo hice eso mismo para un equipo del que igualmente no tenía la información del protocolo, deja te platico:
Se trataba de un computador de flujo de una marca ya obsoleta, para el cual necesitaba crear un driver de comunicación para interfasarlo con un HMI.
El problema es que para este computador, sólo se tenía un software para configurarlo y "monitorearlo" que corría en MS-DOS (¡nada que ver con acceso a este programa desde Windows!)
La conexión con el compuador era por puerto serial RS232
En mi caso yo además necesitaba accesarlo vía internet así que eso complicaba más las cosas, pero eso fué resuelto mediante una tarjeta que convierte un puerto RS232 a un puerto ethernet a la cual se le configuraban los parámetros del puerto serial y de la red deseados... así, mediante una tarjeta de estas podías engañar al HMI para hacerle creer que estabas conectandote por puerto serial cuando en realidad el equipo estaba en otra red, a la cual accesaba por la dirección IP.
Bueno, al final de cuentas, la tarjeta que menciono era sólamente para resolver la parte del enlace, pero al igual que tú sólo tenía un software en MS-DOS que se comunicaba mediante un protocolo propietario y no tenía información para desarrollar mi driver para interrogarlo desde el HMI.
LO QUE HICE FUE:
1) Corrí en una PC con el software en MS-DOS interrogando por el puerto serial al equipo, PERO, en el puerto serial NO ESTABA CONECTADO el computador de flujo, sino una de estas tarjetas que menciono, de modo que los comandos generados por el software MS-DOS se iban a la IP configurada en la tarjeta
2) Con otra tarjeta serial/ethernet tenía conecatado al puerto serial el computador de flujo.
3) En mi laptop con LabVIEW tenía un "programa de escucha" que leía los datos que estubieran en la IP-Puerto de la tarjeta mencionada en el punto 1) y los retransmitía a la IP-Puerto de la tarjeta mencionada en el punto 2)... y con ese mismo programa hacía la operación inversa: leía las respuestas del equipo en la tarjeta del punto 2) y los retransmitía a la tarjeta del punto 1)... de esta forma el programa MS-DOS no se daba cuenta que mi programa en LabVIEW recibía sus comandos antes de pasarlos al computador de flujo y las respuestas del computador las recibía primero mi programa antes de enviarselas a el como si fuera el equipo mismo.
Con lo anterior lo que logré fué que mi programa de LabVIEW estaba enmedio del programa MS-DOS y el computador de flujo y retransmitía los comandos del programa MS-DOS al computador y las respuestas del computador al programa MS-DOS... y éste no se daba por enterado!!! 
En lo que hacía ésto, llevaba registro en un archivo de texto de los bytes en uno y otro sentido...
OJO: Repitiendo comandos desde el programa MS-DOS fuí descifrando la estructura de los mismos (el protocolo) y viendo (en la pantalla del programa MS-DOS) las respuestas del computador y la captura que para estas mismas me daba mi programa "espía", fuí descifrando este protocolo.
No fué fácil, pero ayudó mucho ese arreglo... lo puedes hacer sin las tarjetas de conversión serial/ethernet, lo que tendrías que hacer en tu caso es que la máquna con la aplicación espía en LabVIEW tenga un puerto serial recibiendo los comandos de tu aplicación propietaria y los retransmita (por otro puerto serial) al equipo quedándose con un registro de la comunicación en ambos sentidos.
El programa en sí lo que hace es tener dos loops corriendo en paralelo, uno leyendo de una IP-Puerto y transmitiendo hacia la otra y el otro loop hace lo mismo pero con las direcciones en sentido contrario... ah... y como no sabía la longitud del mensaje ni nada de eso... lo hacía 1byte a la vez... símplemente, cuando se generaba el Timeout en un sentido, asumía que ya había terminado de transmitir y entonces se generaba la información en el otro sentido cuando el equipo estaba respondiendo.
Si crees que te sirva... lo debo de tener aún en un directorio de mi máquina... pero ésa es la técnica que yo empleé... ¡y sí funcionó!
Saludos
