Comunicación con aplicaciones externas en la misma computadora

[MKES]

Buenas tardes a todos!

Cuál sería la manera más apropiada de entregar una aplicación ejecutable que cumpliera lo siguiente:

• Comuncación serial con un equipo mediante un protocolo propietario (del cual tengo completa documentación para desarrollar un "driver")
• La comunicación se basa en códigos de operación que representan las funciones de lectura/escritura de las variables en el equipo y la interpretación de los códigos con que responde el equipo.
• Los datos de las variables que obtengo al comunicarme con este equipo puedan ser accesibles a otras aplicaciones Windows corriendo en la misma computadora (Comunicación vía DDE, OPC, Activex, etc.)
• Sea una aplicación ejecutable (no quiero instalar mi versión de LabView en la máquina del usuario, sólo el ejecutable producido con el Aplication Builder y el Run-Time para no caer en violación de la licencia que tengo de LabView.

Actualmente estoy trabajando en la implementación de la comunicación con el equipo, una vez que tenga una aplicación probada que se comunique con él, generaría el ejecutable y quiero que los datos que extraje del equipo vía mi aplicación sean accesibles a otras aplicaciones existentes en una PC de operación para que puedan "tomar" datos de este equipo. O sea, mi aplicación sería un "driver" de comunicación y sólo eso.

Gracias anticipadas por sus comentarios al respecto!!

Saludos

Manuel Kovacevich

(Utilizo LabView 7.0/7.1)

[Coamín]

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

http://digital.ni.com/softlib.nsf/webcategories/85256410006C055586256BBB002C130D?opendocument&node=1...

Sin más por el momento nos ponemos a tu disposición.

Coamín Cruz

AELatam

[MKES]

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

[Coamín]

Hola MKES

Con respecto a la pregunta que me comentas de cual sería la manera más apropiada de intercambiar información con otras aplicaciones, eso dependerá de los requerimientos que tengas en tu aplicación y eso no dependerá si es un ejecutable o no. Si te interesa compartir datos con otro programa como hojas de cálculo, la manera más sencilla es utilizar VI's como el "write to text file.VI" o el "write to spreadsheet file.VI" que te formatean los datos para poder ser vistos por otros programas. Ahora si lo que te interesa es manipular a otro programa en su totalidad durante la ejecución de tu programa, deberás hacer uso de las funciones de ActiveX. Ahi usarás los nodos de propiedad y nodos de llamado para acceder a las propiedades del programa externo y de esta manera podrás comunicarte e intercambiar tu información.

Para lograr lo anterior, el programa con el que deberás interactuar debe tener habilitado ActiveX, ya que de otra manera no será posible.

Te anexo un ejemplo de ActiveX con programas externos.

Que tengas un excelente día

Coamín Cruz

AE Latam

[MKES]

No tengo la misma versión de LabView en la que fué creado el ejemplo que me mandas... yo utilizo 7.0/7.1... si el ejemplo puede ser convertido a alguna de esas versiones podré verlo.

Gracias

[Coamín]

Hola MKES

Ahhh perdón!!, mira de hecho mejor sacalo de help>>find examples, y en seach busca excel. Ahi te aparecen varios ejemplos y entre ellos el que te envié. Te envío el archivo pero ahi puedes encontrar más ejemplos.

Cualquier cosa escribeme MKES

Que tengas un buen día

Saludos

Coamín Cruz

AELAtam

[MKES]

Ok, déjame replantear mi pregunta inicial:

He desarrolado un "driver" de comunicación con un equipo vía protocolo propietario a través de RS-232 y necesito que la información que obtengo de este equipo esté disponible a una aplicación HMI existente en una computadora que necesita datos de variables existentes en este equipo.

Mi aplicación sólo es el "driver de comunicación" no requiero una interfase muy elaborada ya que sólo se trata de "configurar" el driver, pero bueno, en sí la pregunta original era cómo intercambiar esta información de mi driver con la aplicación Windows existente en una computadora donde no estará instalado LabView, sólo el ejecutable producido con el AplicationBuilder de mi driver.

Yo he desarrollado en mi PC y quiero hacer que una vez que instale mi aplicación en la máquina donde está el HMI éste pueda tomar datos del equipo vía mi driver de comunicación... la pregunta era (es): ¿Cuál es la mejor manera de hacer la comunicación con una aplicación Windows externa? ¿OPC, ActiveX, etc.?... Entiendo que se necesita que mi aplicación sea el Servidor de datos de la otra aplicación pero más que efectuar la transferencia de datos, necesito yo poner los datos disponibles de modo que la otra aplicación pueda tomarlos sin ningún problema.

Saludos

Manuel

[BeCeGa]

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

http://ae.natinst.com/operations/ae/public.nsf/web/searchinternal/f46e8f2ba898c6c886256958004e3f9b?O...

Espero que esta información te sea de utilidad.

Saludos

[MKES]

Hola BeCeGa,

Gracias por responder a mi pregunta, tengo las sig. preguntas/comentarios:

En cuanto al paso de datos por archivo en disco:

Llegué a pensar en esta opción pero no me agrada porque se trata de un servidor de datos de aprox. 20-30 variables, algunas monitoreadas muy frecuentemente (según yo, para ser a través de archivo en disco), aprox cada segundo... lo cual me generaría mucha actividad en el disco y no creí que sea muy adecuado.

No se trata de pasar "lotes" de datos, sino de valores instantáneos para el monitoreo desde la otra aplicación (mi aplicación sólo es el driver de comunicación)

En cuanto a TCP:

Sé bien como hacer esto si todo fuera LabView, pero no es el caso así que no sé muy bien como recibir los datos en la otra aplicación si los transfiero por TCP desde mi aplicación en LabView.

En cuanto a ActiveX:

La aplicación la he desarrollado en mi equipo donde tengo instalado LabView 7.0/7.1 y no la aplicación HMI por lo que no estoy seguro de si puedo hacer referencias a objetos ActiveX que no están presentes en mi máquina.

Hice una prueba generando un ejecutable con ApplicationBuilder, activé la casilla de verificación "Enable ActiveX server" y dando un nombre al servidor pero una vez que instalé mi aplicación en la otra máquina (la que tiene el HMI) no encontré manera de referenciarla desde la aplicación... Si tiene disponible la opción de "instalarle" elementos ActiveX pero no tengo muy seguro qué es lo que tengo que buscar cuando la otra aplicación busca mi elemento ActiveX para agregarlo a una barra de herramientas suya.

Aquí la pregunta sería: ¿qué es lo que se genera o qué archivo adicional se genera cuando activo la casilla "Enable ActiveX server" al construir mi aplicación con el ApplicationBuilder?

En cuanto a DLL:

Ahí si no tengo mucha experiencia, he utilizado DLL's desarrolladas por terceros (aparentemente en C) refernciandolas desde mis programas en LabView, pero no he creado ninguna por mí mismo así que no sé ahorita los requisitos para crear una y aún tendría que revisar cómo referenciarlas desde la otra aplicación. Como se trata de dos "no sé exactamente como" ...mejor evito esta opción.

En cuanto a OPC:

Aquí sé muy bien cómo referenciar vía OPC desde la otra aplicación, y desde LabView... lo que no sé bien es cómo crear elementos como servidor OPC desde LabView.

¿De qué manera puedo construir mi aplicación para que sea un servidor OPC al momento de construir el ejecutable con el ApplicationBuilder? ¿está incluido el soporte para OPC en aplicaciones creadas y distribuidaas como ejecutables para PC's en las que sólo estará el RunTime de LabView?

Esta opción me gustaría fuera viable ya que la aplicación HMI adquiere datos de otros equipos por esta misma vía y no sería mucho problema agregar mi driver de la misma manera.

Estas serían mis preguntas comentarios... en sí me inclino por ActiveX y/o OPC pero con las dudas que arriba menciono y espero me puedan aclarar.

Saludos y gracias de antemano.

Manuel

[MKES]

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