Error 1003 when dynamically calling VI within an executable

[thutch79]

Hey all!

I'm having trouble with a executable build of a large application. The build works fine, but when starting the app, it reports that a few VI's that are called dynamically are broken (error 1003). These VIs within the development environment compile just fine. I've done some poking around and found that it works fine when the advanced option "Use Labview 8.x file layout" was selected on the advanced page in the build definition. My next thought was something within the heirarchy of these VIs is not included in the build. However, everything within the project is already under "always included" section within the build. Not sure where else I could have missed something.

Does anyone have any ideas of what I can try next? Is there anyway to get a more meaningful error message from LV?

Thanks!

Tim

[crossrulz]

Can you show some code of how you are dynamically calling your VIs?

[thutch79]

There is a couple of dynamically called VIs that exhibit this issue. There are a few others that don't. Attached is a screen cap of the code that launches one of the offenders.

[Karen_M]

This has been shown to happen when building a VI that includes a subVI containing a Shared Variable in the older versions of LabVIEW. 

Here are some potential workarounds:

1. Check the Enable debugging option in the Advanced category of the application executable properties.
2. Disable the Remove Panel option for all SubVIs containing Shared Variables in the build
3. Uncheck the Disconnect type definitions and remove unused polymorphic VI instancesoption, also in the Advanced category of the executable properties
4. Move shared variables to the top level VIs and pass the data through the SubVI connector
5. Upgrade to LabVIEW 8.20.

[thutch79]

Sorry, I should have listed this before. We are on LV 2013. We also don't use shared variables anywhere in the project.

Tim

[crossrulz]

Move your Open VI Reference to be INSIDE of the FOR loop.  You are telling the same VI instance to run repeatedly.  By moving the Open VI Reference inside of the loop, you are creating another instance of it.  I am assuming that VI being called is set to reentrant.

You will also want to autoindex the reference coming out.

[thutch79]

The way it is written works just fine in development environment. Why would it work there and not in an executable? I spent alot of time working on how to properly call these VIs dynamically and if I remember correctly, putting the open ref in the for loop caused issues. I'll have to research to figure out what those were.

Attached also is the code that launches the other problematic VIs. As you can see, these are called differently, but still exhibit the same behavior on build into an exe.

[dan_u]

Do you get error 1003 in the launcher or in the dynamically called SubVIs? I guess in the subVIs. What functionality do you use in the SubVIs that are broken? Can you post one of the dynamically called VIs that is broken when called in the exe?

Somehow the dynamically called VIs seem to not find a dependency (subVI?) when using the new (not 8.x) file layout.

[thutch79]

The error comes from the launcher. That's my frustration. The dynamically called sub compiles just fine in the dev environment.

I agree it's likely looking for something it can't find. However, those dynamically called VIs are specifically called out in the build spec to "Always Include". Shouldn't that take care of including anything it would need?

This VI does use a number of classes. I get many warnings with regards to naming conflicts. However, that, in many cases, is the whole point of using classes. I have many dynamic dispatch VIs. How is this handled within executables? Is it OK that many of my method VIs have the same name by design? Not sure if that's the root of the issue, but I suspect it could have something to do with the issue since many of our recent changes are around moving towards more object oriented code.

[crossrulz]

---

thutch79 wrote:

This VI does use a number of classes. I get many warnings with regards to naming conflicts. However, that, in many cases, is the whole point of using classes. I have many dynamic dispatch VIs. How is this handled within executables? Is it OK that many of my method VIs have the same name by design? Not sure if that's the root of the issue, but I suspect it could have something to do with the issue since many of our recent changes are around moving towards more object oriented code.

---

You will run into the name conflicts when using the 8.X file format for your executables.  In the 8.X format, the EXE is actually a flat file structure.  So any VIs with the same name will conflict with each other.  Starting in 2009, NI went to something more like a zip file format, so the executable has a file hierarchy inside of it.

My thoughts are that your relative paths are being messed up when you build up the executable.  You might want to set up some indicators so you can figure out where those paths are pointing to and then see if you can actually find the VI in that location.  It is a little more difficult to do that with the VIs in the executable, though.