Build Issue with Reentrant VIs

[theoneandonlyjim]

As part of my latest debug process, I've been building EXEs with a basic test platform and the necessary support files - hopefully cutting down on places to look for problems in each component.

The test platform in each case is a basic UI where I can enqueue messages (start, stop, do something) or receive messages (data, status, errors) plus the control code I want to trace. I've been successful with debugging and building several components (temperature readout and calculations, stage control, voltage measurement), but have hit a wall with building the last (a pair of power supplies). I have changed no settings from build to build.

For all components, I can do what I want in the development environment. With most, I can build and get the same expected function. With the power supplies, I can do what I want in dev, However, the build completes without error, but the EXE is broken. I get a "The VI is not executable. The full development..." error. The major difference that I'm able to discern is that the power supply test platform has reentrant VIs (some are inlined). Since I'm using OOP and dynamic dispatch, they're sharing clones. If I put a "diagram disable" box around the top level VI for one of the supplies, the app builds and runs successfully, albeit with only one supply functioning.

I've looked on the web and the causes I've been able to find for the error aren't relevant for my test. I'm using an emulator for the supplies (no drivers), I'm not dynamically loading anything (path name failures don't happen), and there are no DLLs (I'm not that good yet). Has anyone else run into problems with this? Why wouldn't the error appear in the build process?

I'm running LV2011.

[bgapske]

We have suffered similar issues with our plugin-based application using packed project libraries. Any time we loaded more than one packed library that called the same "inlined" VI (say for instance, a VI in our reuse library) as another loaded packed library, it would break with a similar message. Individually they loaded fine. In the end we just turned off the inline feature on the reuse code and all was well.

We haven't yet got around to thoroughly investigating and reporting the issue, but I might suggest experimenting with removing the inline settings and trying again.

[mje]

Are you running the executable on the same computer as the development environment?

These issues can be really tough to debug. For me it always end up being unresolved dependencies which are either not distributed with the executable, or system level libraries that are unavailable. Basically the executable was successfully built and there's nothing wrong with it, but it's not until you try to run it that you find out something critical is missing.

You may not have explicitly included external dependencies or done any dynamic loading, however are you sure the emulators don't do as much? Or other code you may use?

One trick you can play is this: open your LabVIEW project and look at your Dependencies. If you don't see the dependencies in the project explorer, make sure the menu item Project: Filter View: Dependencies is checked.

There you should see anything that your project uses which isn't explicitly included in your project. You can probably ignore the things in user.lib and vi.lib, but you may also see things like some DLLs or .NET assembly references here that need to be brought into the project.

If you find dependencies, is it a system-level library? Stuff like kernel32.dll, or other Windows components. Chances are you won't need to worry about these, although they may restrict which operating systems you can use your executable on. If it's not a system-level dependency, make sure it gets included in your build. LabVIEW will usually pull any of these into a build automatically, but dynamic loading can leave no clear traceable path to them and easily result in them not being picked up when building.

As an aside, a few stabs in the dark. Two issues I've repeatedly run into:

1. Various flavors of the Microsoft Visual C/C++ runtimes not being available on the system. Despite what many people think, there is an RTE for the various MSVx incarnations (just like there is LabVIEW), they're just so common may people forget about it.
   
2. If any LabVIEW code uses .NET (either your code or third party code), you'll be needing a .NET 2.0 compatible installation. That would be any of the 2.0, 3.0, or 3.5 installations as they're all additive and include 2.0-- but beware later versions do not.
   

[theoneandonlyjim]

We have suffered similar issues with our plugin-based application using packed project libraries. Any time we loaded more than one packed library that called the same "inlined" VI (say for instance, a VI in our reuse library) as another loaded packed library, it would break with a similar message. Individually they loaded fine. In the end we just turned off the inline feature on the reuse code and all was well.

We haven't yet got around to thoroughly investigating and reporting the issue, but I might suggest experimenting with removing the inline settings and trying again.

Unchecking "Inline" throughout the project did the trick. Thanks.

I guess I have some learning to do about to what level I can use that option. Accessors only? Small operations like array indexing, adding, comparison? I'll look on LAVA and NI, but any insight is welcome.

These issues can be really tough to debug.

Agreed. The debug tool wouldn't connect and generated an access violation, so I was left with forum and Google crawls.

I considered that it was reentrancy, but didn't think of inlining. When the VI got stripped to little more than an event structure, initialization code, and empty while loops and the EXE was still broken, I thought something was wrong with one of my classes. I got stuck on "Well, if it's because the VIs are reentrant, the solution is going to be code duplication, and that's not what I want."

You may not have explicitly included external dependencies or done any dynamic loading, however are you sure the emulators don't do as much? Or other code you may use?

One trick you can play is this: open your LabVIEW project and look at your Dependencies. If you don't see the dependencies in the project explorer, make sure the menu item Project: Filter View: Dependencies is checked.

There you should see anything that your project uses which isn't explicitly included in your project. You can probably ignore the things in user.lib and vi.lib, but you may also see things like some DLLs or .NET assembly references here that need to be brought into the project.

If you find dependencies, is it a system-level library? Stuff like kernel32.dll, or other Windows components. Chances are you won't need to worry about these, although they may restrict which operating systems you can use your executable on. If it's not a system-level dependency, make sure it gets included in your build. LabVIEW will usually pull any of these into a build automatically, but dynamic loading can leave no clear traceable path to them and easily result in them not being picked up when building.

I wasn't clear on this before, either. What can I leave in dependencies? Some of the classes explicitly contained in the project have parents that weren't. There was some reuse code in dependencies, too. I've moved all but the instr.lib, user.lib, and vi.lib into the project just to be safe, but I thought the build would capture them.

This experience shows me that I should shore up my knowledge on app builds. I've run most of my projects in the dev environment and this was the first where I've tried to make a serious attempt at a formal app build.

Thank you both.

[mje]

I wasn't clear on this before, either. What can I leave in dependencies? Some of the classes explicitly contained in the project have parents that weren't. There was some reuse code in dependencies, too. I've moved all but the instr.lib, user.lib, and vi.lib into the project just to be safe, but I thought the build would capture them.

Sorry about the confusion, when I said "that need to be brought into the project" I didn't mean you need to do so, I meant that the development environment needs to bring into memory to successfully load all of your project items.

Just because your project contains items doesn't mean they will be included in any build specifications you make in that project.

My projects are usually littered with many test VIs that I use to validate functionality, run unit tests, demonstrate proof of principle, etc. They do not go into the build because they are not part of the core code. Some projects also have many different build specifications, such that different components from the project go into different executables.

The dependency tree in the project explorer though is very useful because once you have something in your project, you're telling LabVIEW, "Hey, I'm going to use this widget somewhere!" and it will do it's best to figure out what else it needs to bring along for the ride. If you go ahead and plop that widget down on a block diagram of a VI that goes into your application, LabVIEW will bring along all the dependencies it can figure out automatically. But if you dynamically load that widget and there's no static link from your application to that widget, LabVIEW will be clueless about the relationship and you'll need to manage it yourself. Similarly if you use something like a DLL, LabVIEW will know about the DLL if you use it somewhere, but who is to say that DLL doesn't dynamically link to other DLLs? (This is where the MSVC dependency has bitten me many times over.)

You can generally leave as much as you want in dependencies, there's nothing wrong with that and I'm sorry if I implied you should not do so. The trick to the dependency tree is using it to track down items which you might need to include into your builds which you would otherwise be unaware.