Dynamic call does not work on standalone PC!

[Norick_17]

Hello

I do have a strange behaviour when I run my application (*.exe) on a standalone PC#1. This application makes simply one dynamic call to vi, but I do

get an error 1003 on the "Run Vi invoke note". On the other hand I can use the same application and run it on a different standalone PC#2 and it works

without problem. The differences to the PC#1 is that a LabView Version 2010 is already preinstalled.

The application itself was developed on a Win7 PC with LabView 2011 SP1 (it also works here). Does anybody know where the problem is? Is there any

specific flag which needs to be set in the build configuration?

Thanks in advance

[CCornish]

Have you verified that both stand-alone systems are using the same version of the LV Run-time Engine?

Have you verfiied that both stand-alone systems also have the same supporting files and installations?

[Freelance_LV]

Hi

Did you notice that the error '1003' says that the vi is broken or not executable?

Please check if all the sub vis are present on the other PC too.

Are you running the VI or the EXE of this VI?

If it is an EXE that you are running, then include this dynamically called vi in 'Always included' of source files.

[pallen]

Freelance LV might have the right idea. 

If you include a dynamically called VI in your build, you must make sure that VI is listed in the VIs to be included in the build.  This might be new to you if you have not built exe's with dynamically called VIs before.

Top Level VIs that do not call anything dynamically will have all SubVIs loaded into memory when the top level loads.  This means you can build a working .exe by only including the top level in the build.  Everything else is loaded into memory automatically, so the code is all there when you build. 

Dynamically called VIs are not in memory until they are called.  So these have to be included in your build manually. 

A helpful "trick" is to create a "compiler VI".   This is just a block diagram VI that has copies of all of your SubVIs, including your dynamically called ones.  Just include your compiler VI in your build and you'll always have all of your dynamic VIs. 

[Norick_17]

Hello

@CCornish

Have you verified that both stand-alone systems are using the same version of the LV Run-time Engine?

- I installed again the latest RTE as I used on the development PC -> problem still exists

@Freelance

Did you notice that the error '1003' says that the vi is broken or not executable?

- the vi is not broken because I can run the .exe without problem on the dev. PC

I am running the .exe on the standalone PC and the dynamic called vi is included to the build!

In my opinion there is a problem that the .exe does not find the dynamic called vi on the standalone PC. Is there a mistake in calling this dynamic called vi in my test.vi?

best regards

[Intaris]

---

@Freelance

Did you notice that the error '1003' says that the vi is broken or not executable?

- the vi is not broken because I can run the .exe without problem on the dev. PC

---

But the entire problem is that the exe is behaving differently ont he dev PC than the target PC theref0re you cannot state with certainty that the VI is not broken on the target PC.  If a single sub-VI is missing from the exe then that portion of code WILL be broken ont he target.  If you only deploy half an application, even though it works ont he dev PC it will not work on any other PC.

Also check the path being called on the EXE because there's an issue between dec-time paths and exe paths (one level is extra int he exe).

Shane.

[Freelance_LV]

Hi

I was not able to check your vi as i use a lower version of LabVIEW.

however, i can suggest that you use static VI reference when you are using the Invoke Node.

if you are using a dynamic vi reference, be sure that the path is correct when called in the EXE. as suggested in the previous post, by Shane, the relative path gets chagned when you call in an EXE.

So, one suggestion is, display the path going into the 'Open VI ref', function, if you are using it. You can see the vi path when called in the EXE. This will tell you where the problem is.

Else, remove the dynamic reference and palce a static vi reference for the vi. Include the vi in the 'always included'.

[JW-JnJ]

I believe Intaris is correct. The VI may be broken because it doens't have a SubVI that the machine with the full LabVIEW install has.

IMHO, the easiest way to ensure portability is to include all dynamically called VI's in the main VI's "always include" list. Then call the VI which is inside the executable. Otherwise you will have a never ending battle of tracking down every SubVI every time the code changes and globals won't work between the executable and dynamic SubVIs. However, this may not be an option depending on your application.

Upon rereading your reply, it looks like you're including the SubVI, but not calling the VI included within the executable itself. The VI outside of the executable will not include all of the SubVIs.

[crossrulz]

You also have to be careful because some of NI's VI's are called dynamically.  For example, have a look inside of the Report Generation VIs and you will see dynamically loading of classes.  If you don't include them in the EXE, then your EXE will be broken.

[Norick_17]

Hello

thanks for all the suggestions. For a better illustration of the problem I attached two screenshots with the vi of my application and the build-settings which shows

that the called vi is included.

On the second printscreen the same application (*.exe) but used on the standalone PC. There I get the error 1003 as already mentioned. An open question is

about the path of the called vi. Do I have to use the complete path after ".exe\" meaning including the harddrive letter or is it correct in the way its shown on the attachment?!

best regards