Test Exec Loads LLB Dynamically but flawed....why ?

[Chris R]

I have written a Test Executive type application that has been built into an Executable , it calls and runs a number of Test modules , these are .llb's. Each .llb contains all the vi's it needs to run as I understand the issues that the RTE has with un-resolved links etc etc. However I have a Globals llb wich is also distributed. Each test module llb uses the globals llb as does the Test Executive. When I built my Executive everything was fine. Now I have changed my Globals llb the built executive no longer works , the llb version of the executive works fine however.

I had a peek inside the executable version of the Test Executive by renaming it and using Vi library Manager and sure enough there is a copy of the Global vi inside it. Obviously when I then modified the Globals the Test Executive became incompatible with my Test llb's

The whole idea of me doing this was so I could distribute a Test Exec to various sites (Some off-shore) and then simply release Test Modules llb's and a Globals llb whenever I like without the Test Exec needing to be modified.

It would appear I have a problem with my method , any suggestions ?

Thanks in advance
Chris

[Joe_Guo]

Never tried it myself, but instead of using labview globals, use function globals (a vi which has multiple cases with shift registers that manipulate local variables).

-Joe

[Dennis_Knutson]

An exe resides in it's own memory space. I know that globals cannot be shared between two different exe files and would presume that the same is true between an exe and an llb but frankly, I've never had this situation. Between executables, several things are possible. You could use an external txt or ini file, datasocket, or TCP/IP.

[Aaron_G]

Chris,

LabVIEW only allows one version of a VI with the same name into memory at a time. Thus, your executable is loading the executable version of global.vi into memory (first) and subsequent calls to that global from LLBs will always return the executable version of the global even though there is a different copy available within their own LLB.

As a work-around, you could separate your program and force loading in a quasi-reversed order. You would create a launcher program that first dynamically loads the global.vi from an external LLB into memory and than dynamically loads your main VI. Thus the main VI would find the external global.vi already in memory and use that one. The downside to this method is that if a name or type of a global variable changes from what the executable expects, it will break the executable. Thus, you can only add new globals and never change existing globals.

Regards,
Aaron

Edited for spell-checking

Message Edited by Aaron G on 04-22-2005 09:45 AM