el 02-13-2007 01:39 PM
el 02-27-2007 09:47 AM
Hola MKES
No se si ya has realizado aplicaciones de ejecutables con el Build Application de LabVIEW, pero es muy sencillo, solo tienes que ir al menú tools>>build application y te aparecerán todas las opciones. Ahí es importante que los archivos de soporte los agregues en la pestaña source files para que puedan ser disponibles en la computadora que lo instales. Si omites algún archivo tendrá problemas la aplicación. En cuanto al Run-Time la computadora que no tiene la licencia de desarrollo de LabVIEW tendrá que contar con el Run-Time que puedes bajar de internet, solo asegurate que sea la misma versión para la cual fue diseñada la aplicación. Te anexo unas ligas que te pueden servir para llevar a cabo tu aplicación.
http://digital.ni.com/public.nsf/allkb/800E68EBF895BD96862570770051FF36
http://digital.ni.com/public.nsf/websearch/24428308FA8259B686257076007C1BD0?OpenDocument
Sin más por el momento nos ponemos a tu disposición.
Coamín Cruz
AELatam
el 02-27-2007 03:18 PM
Gracias Coamín,
Si he practicado un poco con el AplicationBuilder para la creación de un ejecutable a partír de un VI, aunque estos no habían tenido necesidad de comunicarse con otras aplicaciones externas de Windows.
La pregunta principal es el tercer punto de la lista de "requisitos" en el sentido de cual sería la manera más apropiada de intercambiar información con otra aplicación Windows (p.ejem. Excel) cuando la aplicación es un ejecutable corriendo en una máquina con sólo el Run-Time de LabView.
Saludos y gracias,
Manuel
el 02-28-2007 04:35 PM
el 03-01-2007 12:45 PM
el 03-01-2007 02:04 PM
el 03-05-2007 09:18 AM
el 03-05-2007 10:28 AM
Hola MKES, como mencionas hay muchas formas de comunicarte con tu otro programa, ya ahí depende de el otro programa que interfases tiene para comunicarse, lo que puedes o te conviene hacer.
Una opción sencilla es utilizar un archivo de en el disco duro y escribirle los datos de tu driver, así en tu otro programa asolo tienes que leer estos archivos.
Otra es enviar la información por TCP la información entre los dos proyectos y usas local Host para enviarla. (La opción de TCP y la de el archivo pueden no ser las soluciones más eficientes, pero son fáciles de implementar).
Una opción también muy buena es puedes utilizar lo que es utilizar Active X
También puedes usar tu driver como dll y hacer que te regrese los paramentos directo a tu programa.
Si quieres utilizarlos como OPC también puedes, ahí lo que podrías hacer es publicar tu información a variables compartidas y acceder al variable engine OPC.
Con respecto a como usar Labview con ActiveX
http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/activating_lv_activex_srv/
http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/using_activex_with_labview/
http://zone.ni.com/devzone/cda/tut/p/id/2983
En la parte de TCP y escritura de archivos, checa los ejemplos de LabVIEW en Find examples.
De los dlls, el siguiente link te puede dar una idea
Espero que esta información te sea de utilidad.
Saludos
el 03-05-2007 12:26 PM
el 03-14-2007 01:53 PM
Hola nuevamente,
Pues aún batallando con esta comunicación entre aplicaciones, así que me fuí por un camino algo sinuoso
Déjenme resumir mi situación:
Desarrollé un driver de comunicación con un equipo que maneja protocolo propietario vía RS-232 esto fué para que un HMI existente (no NI) pudiera adquirir datos de este equipo.
Como este HMI sólo necesita "el driver" pensé en crearlo como ejecutable con el ApplicationBuilder y pasarle información de las variables adquiridas vía OPC, ActiveX o algún otro medio.
OPC: En la versión que utilicé (LabView 7.0) no parece tener capacidades de servidor OPC, sólo de cliente así que no parecía ser la solución.
ActiveX: Aunque al momento de crear el ejecutable con el ApplicationBuilder te da una casilla de verificación que dice: "Enable ActiveX server" no encotré desde la aplicación del HMI manera de hacer referencia a las variables de mi driver... (si alguien puede orientarme sobre esto se lo agradecería).
Por ahí alguien me sugirió que por TCP y aunque mencioné en mi mensaje anterior que no tenía experiencia en ello y ante lo arriba mencionado no me quedó de otra más que atacar esta opción y ese es el motivo de este mensaje...
Como en el HMI existe un driver de comunicación MODBUS/TCP consideré pasar la información por este medio.
Básicamente MODBUS TCP es igual a Modbus Serial con las diferencias de que el mensaje no lleva CRC (se usa la validación por Ethernet) y se le agrega un "encabezado" al mensaje que indentifica la transacción, el protocolo y la longitud del mensaje.
No tengo problema para agregarle este encabezado a mi mensaje, el problema surge que cuando utilizo las funciones TCP Write para enviarlo por la red, LabView me agrega bytes al principio que aparentan ser los de la identificación del protocolo y no incluye los de la identificación de la transacción... o sea que si yo quito los de identificación de transacción y protocolo LabView sólo agrega los del protocolo y no los de identificación del mensaje... eso lo hace con cualquier cosa que envíe ocasionando que el HMI nunca considere válida la respuesta que envío y la información "no pase"
Sé que la explicación que acabo de dar no es muy clara, pero si alguien ha hecho esto antes, segúramente sabe de lo que hablo.
En sí el encabezado de que hablo tiene esta forma:
BYTES 0-1: Transaction identifier
BYTES 2-3: Protocolo identifier = 0
BYTES 4-5: Length fields (Upper, Lower bytes)
BYTE 6: Unit Identifier (Slave address in "normal" Modbus)
BYTE 7: Modbus Function code
BYTE 8-xxx: Data bytes
Yo genero la infomación de BYTE 4 en adelante, asumí que la del transaction identifier y el protocol identifier se generarían puesto que cuando abro el puerto para escuchar las peticiones de datos voy pasando el "Connection ID" hasta que cierro el puerto, pero no es así
Monitoree una "conversación" entre dos utilerías que probablemente muchos conozcan: Modsim32 y Modscan32... entre ellas el Modscan genera el Transaction identifier y el Modsim lo repite en la respuesta.... el Protocolo Identifier siempre es 0 (así debe ser), incluso utilizé el Modsim para simularle un dato al HMI y no hay problema en recibirlo correctamente en el HMI...
Volviendo a "mi problema"... cuando utilizo TCP Write, LabView genera automáticamente el Protocol Identifier y si yo copio el Transaction identifier que recibo cuando el HMI me pide un dato, aparece en la conversación después de los 0's que LabView genera sólo...
¿es este un problema de LabView? ¿cómo se resuelve?
Saludos y gracias de antemano.
Manuel