A VI called by reference with a express VI included does not work!?

[Ben]

Hi Michael,

Please take a look at the attached zip for what may be a viable solution.

If I undestand correctly, you want to have a built app that does not change.

This built app has to do dynamic calls to VI's that can change.

The attached files include two .bld files. One for the main app the other for the dynamic VI's.

I modified your main app to look inside the "appl_support.exe" to find the dynamic VI's.

If you need to mod the dynamics only the ...supprt needs to be re-built. The top level stay un-changed.

What was happening in the code you posted for me.

The first VI you called dynamicly is part of the main's hiarcht so it gets included as part of the build by default. Since it is part of the build it gets compiled and included as part of the exe. It is also loaded into the memory space of the LV run-time engine when the top level gets loaded. When it was called, the run-time engine found the VI in memory and used it. This all worked fine.

In the case of the second dynamic VI, it was not part of the build and not spec'd as a dynamic VI. When the run time engine went looking for the VI, it was not a built VI and since the run time engine can not compile VI's it reported that VI was not executable.

Using the supplied .bld files you can compile your dynamics VI and prepare them for use by the executable.

I think this may be what you need.

I am a little confussed what the Express VI's have to do with this issue. Once I adjusted the calls and build it worked on the first try for me.

Please let me know if I am in left field here.

If the is a bug in this somewhere please let me know how to reproduce it so I can report it.

Trying hard to help,

Ben

[Michael Winkler]

Have a nice weekend, I answer your questions on Monday!

Best Regards
Michael

[Michael Winkler]

Hi Ben,

Take my example appl.zip and open the called2.vi. Replace the build text express VI with a constant text. Now run the appl.exe and it works fine. And who blames: the build text express VI. If you need further information on dynamically called VIs refer to the shipping example called plugin example. After that you will see that only one dynamically called VI must be built with the application, and the others must be strictly typed. Just the ones with the build text express VIs does not work.

Trying hard to explain 🙂

Michael

[Ben]

Ok Michael,

I am apparently missing something because you think it still broke I did not notice anything unusual.

Please post a new zip that has a working and a non-working version of the code and its dynamics.

Make sure you point out what seems odd to you.

Maybe some other readers can spot what I am missing.

Confussed re:what is wrong,

Ben

[Ben]

I just reveiwed the example you mentoned.

I am still confussed as to what you think is not working!

Ben

[Michael Winkler]

Hi Ben,

In the File try2.zip you'll find a "working" and a "not working" directory. The only difference between the content of these folders is the called2.vi.
In the "not working" directory the String Output is generated with the "build text" Express VI, and in the "working" directory it is generated with a constant.
The appl.exe are the same. They are built from the appl.vi and the called.vi is added dynamically. You just have to tell the application ONE never-changing dynamically called VI. In this case the other dynamically called VIs must have the same input and output parameters as the one dynamically called VI you told the application. Note: called.vi and called2.vi have the same input and output parameters, it is also called strictly-typed. If you not believe in me, just refer to the shipping example called plug-in example in your LabVIEW examples or I think it is also in the VI Server documentation.
It is no solution to build everytime a new application when a dynamically called VI changes!!!
The appl.vi is just in the directories that you know the source code of the appl.exe.
The appl.bld file is only there that you see the called.vi is only added dynamically in the appl.exe.

Again in one sentence: the appl.exe cannont call the called2.vi dynamically by reference in the "not working" directory, because of the build text Express VI.


Trying very hard to explain 🙂

Michael

[Michael Winkler]

Sorry I forgot the try2.zip

[Ben]

Hi Michael,

I checked with one of the CLA's I work with and who also teaches all of the advanced LV courses.

It looks like I am going to learn something here!

He just demo'd a VI were he could open any VI PROVIDED it was compiled in the same version of LV.

So it sounds like what you are attempting could work.

I am going to follow-up on this when I get a break.

There two things that I will look into, (when I find the time).

I beleive it was Michael Aviol.... (sp?) who posted to Info-LabVIEW about an issue with "disconnecting typedefs".

The other thing is looking into a mass compile.

With what I know at the moment, you may indeed have discovered a bug.

Maybe someone else will chime in here, but lacking that I will have to beg some more time to follow-up on this.


Thank you for the leason! I will try to retun the service.

Ben

[Donald]

---

I beleive it was Michael Aviol.... (sp?) who posted to Info-LabVIEW about an issue with "disconnecting typedefs".

---

Apologies if this is a false lead, but I remember the thread that Ben mentions and have a bit of it in my snippets from InfoLabVIEW:

“By default, LV7 AppBuilder does not include type definitions and unused instances of polymorphic VIs into executable in order to decrease size of application. If some VI in your exe calls a VI outside (that was not planned by AppBuilder) and uses a type definition in order to pass parameters, you will meet such kind of problem for sure. I was offered a few ways to solve the problem but I really like only one. There is undocumented ini setting that disables this new feature. Put the following line to your labview.ini file:

BldApp.RemovePolyVIsandTypedefs=False”

More info can be obtained by searching the InfoLabVIEW archives at
http://www.searchview.net/ for “lv7 app builder problem”

It’s also discussed at:
http://forums.lavausergroup.org/index.php?showtopic=69

[Michael Winkler]

Thanks Donald,

In LabVIEW 7.0 you must add this line to the labview.ini file. In 7.1 it is a checkbox in the appl builder that you don't have to set.

Best Regards,
Michael