Plug-in architecture as exe in 8.5

[zythum]

Hi,

I read about do a dynamic call of a VI inside a exe into 7.1. That's working well. I try to do the same into 8.5, I can't. The reason I need that is because we have the MRP software for production (I just recompile it from LabView 6.0 to 7.1 and now into 8.5) that call the specified exe versus the step and setup in production. So the production need to call only the MRP and fallow the step. I don't really want to change the method because the code was done a long time ago from outside companies. Everything is working fine in 6.0. If I want to push for 8.5 upgrade, I need to redone the same way that was already done. I already talk to my LabView Architect's Instructor (I fallow the course last week) and he told me the exe on 6.0 and 7.1 was very close as a LLB. But, into 8.0 and up, the exe are different. I need to keep the exe aviable for engineering and r&d. I don't want two different way because if something work with one but not with the second, it will be software issues (my fault)

This is a example what I try to do.

Thank you

Edit

http://digital.ni.com/public.nsf/allkb/854...62571DA005B896C said we can't do anymore starting into 8.2 :

There are two primary motivations for the change:

• Security and program design - EXEs are designed to be stand-alone programs, and DLLs dynamic modular code plugins. The users of EXEs and DLLs should generally be unaware of the details of the implementation. With an executable, users should only be aware of how to execute the program, and whether or not the executable implements certain access technologies like ActiveX or TCP/IP. For example, if you were to build an executable containing a VI designed to halt the program and shutdown your system, you would only want that VI called in specific times. You would not want other programs to access this VI and use it inappropriately.
  
• Microsoft Vista compatibility - Vista recommendations state that EXEs be signable and restrict their access from other programs. These requirements forced changes in the way the LabVIEW Application Builder creates executables and DLLs so that they could be digitally signed. This change forced a modification in the way the LLB was embedded in the LabVIEW EXE/DLL which prevents the LLB from being accessed from outside of the EXE/DLL.
  

[Rolf Kalbermatter]

QUOTE (zythum @ May 11 2009, 06:10 AM)

Hi,

I read about do a dynamic call of a VI inside a exe into 7.1. That's working well. I try to do the same into 8.5, I can't. The reason I need that is because we have the MRP software for production (I just recompile it from LabView 6.0 to 7.1 and now into 8.5) that call the specified exe versus the step and setup in production. So the production need to call only the MRP and fallow the step. I don't really want to change the method because the code was done a long time ago from outside companies. Everything is working fine in 6.0. If I want to push for 8.5 upgrade, I need to redone the same way that was already done. I already talk to my LabView Architect's Instructor (I fallow the course last week) and he told me the exe on 6.0 and 7.1 was very close as a LLB. But, into 8.0 and up, the exe are different. I need to keep the exe aviable for engineering and r&d. I don't want two different way because if something work with one but not with the second, it will be software issues (my fault)

This is a example what I try to do.

Thank you

Edit

http://digital.ni.com/public.nsf/allkb/854...62571DA005B896C said we can't do anymore starting into 8.2 :

There are two primary motivations for the change:

• Security and program design - EXEs are designed to be stand-alone programs, and DLLs dynamic modular code plugins. The users of EXEs and DLLs should generally be unaware of the details of the implementation. With an executable, users should only be aware of how to execute the program, and whether or not the executable implements certain access technologies like ActiveX or TCP/IP. For example, if you were to build an executable containing a VI designed to halt the program and shutdown your system, you would only want that VI called in specific times. You would not want other programs to access this VI and use it inappropriately.
  
• Microsoft Vista compatibility - Vista recommendations state that EXEs be signable and restrict their access from other programs. These requirements forced changes in the way the LabVIEW Application Builder creates executables and DLLs so that they could be digitally signed. This change forced a modification in the way the LLB was embedded in the LabVIEW EXE/DLL which prevents the LLB from being accessed from outside of the EXE/DLL.
  

Well the documentation link you provide says it all. If you want to access the VI from the same executable where it is embedded into, just change the path input to the Open VI Reference to a string only, containing only the VI name of the VI. This requires you to know the VI you want to execute of course.

In LabVIEW >= 8 you can however not peek into an EXE or DLL anymore through VI server. So if you have some situation where you want to call a VI that is contained in an EXE or DLL that is different than the application runtime that is currently executing this will always fail.

Rolf Kalbermatter

[zythum]

QUOTE (rolfk @ May 11 2009, 07:48 AM)

Well the documentation link you provide says it all. If you want to access the VI from the same executable where it is embedded into, just change the path input to the Open VI Reference to a string only, containing only the VI name of the VI. This requires you to know the VI you want to execute of course.

In LabVIEW >= 8 you can however not peek into an EXE or DLL anymore through VI server. So if you have some situation where you want to call a VI that is contained in an EXE or DLL that is different than the application runtime that is currently executing this will always fail.

Rolf Kalbermatter

Thank you

I think I will compile into a llb. So, I will able to open any VI from outside exe. Il will make a other interface for call the specified VI outside Production environement

Thank again, fast answer!