Shared Variables and Dynamic VI's - Build Problems

[Castechvb]

I have an application that loads a TestSequence from an INI file. The INI file specifies a series of TestSteps that should be called.

I have a VI that dynamically calls the TestStep VI's and some of the sub VI's contain explicit shared variables. The only way I can get the application to build into an EXE that works is to include the TestStep VI's within the list of dynamic VI's in the build specification. This causes me a problem as I may want to add new TestSteps at a later date without having to rebuild the application each time.

In the development mode I can do everything I want and it works well. However, I need to create an EXE for use on the shop floor.

What am I doing wrong?!!

***LabView 8.20***

[JamesC]

Hi Castechvb,

I think the problem you are seeing is with the shared vaiables you are having to deploy with your application.

Please can you follow the details in this KB. To deploy your shared variables, but don't add your dynamically called VIs to the support files.
What you might want to do there is use this KB as a base, but instead of creating an LLB, create a support directory to put you VIs in, so you can add more VIs at a later time.

Regards
JamesC
NIUK and Ireland

[Castechvb]

Hi,

Thanks for the response.

I was certain this was not the problem but added the deploy variables as you suggest. This did not improve the situation.

The problem is definately to do with the shared variable though. If I use a 'diagram disable' structure around the shared variable, everything works fine. Similarly, if I address the shared variable using datasocket, everything works. The problem only exists when I use explicit shared variables (the ones that look similar to local/global variables).

[JamesC]

Hi Castechvb,

I have been working on the code you sent in and to the office and have found a solution, however I am not sure if it is acceptable to your architecture. In your project please add the file NGwrite_imp.vi from "c:\program files\National Instruments\LabVIEW 8.2\vi.lib\variable" in your build specification please add this file as dynamic VI along with your lvlib file.

If you have any more problems on this issue. Please post back or contact the UK office.

Regards
JamesC
NIUK and Ireland

[Castechvb]

It sounds like this is a bug as I would have thought a LabVIEW support/system file would have been pulled in automatically.

I actually hit a bigger problem. I didn't want to include the test steps in the build script to allow me the flexibility of adding test steps without rebuilding the EXE. This does not work anyway as my TestSteps contain sub-VI's. It appears that when the TestStep is run dynamically, the connection/path to the sub-vi's is lost even if they are stored in an identical directory structure.

Thanks for your help.

[JamesC]

Hi Castechvb,

I have been working with the code you sent in, and have added a subVI to the sub.vi that you call from your main VI.
Using the EXE we had working calling the sub.vi worked perfectly, when the caller vi (sub.vi) called its SubVI.
the SubVI was stored in a directory called subvi at the folder level of problem.exe

we also created a new VI called multi.vi with its own subVI and that worked too.

In fact the LabVIEW side of this will work perfectly, as the Example Finder is a built exe, that dynamically creates the examples list and then opens them for you using VI server and most examples have multiple subVIs.

From this your application should work. If you could send in a small example using the teststand calling code we can look into this further.

Regards
JamesC
NIUK and Ireland

[Castechvb]

James,

You are correct that you can call a sub-vi in a seperate directory and these paths are maintained as you say. The problem actually shows itself if you have one of your subvi's calling one of the NI library files. For example, add Clear errors to one of the sub-VI's that you were calling and you will see what I mean.

This does make sense I guess. Not having the dynamic VI in the build script means that any support files that they call are not automatically added. I could get around this I suppose by saving all of these support VI's within my project but I do not have the energy!!

Thanks

Colin