Dev Env ok, Successful build, but exe wont run

[chops88]

LV2020 32bit

I have a old project that has been in dev for years. Description: 

Top-level UI/state machine starts a series of modular vi state machines with Open VI ref like this: 

This works for all but the one in the photo. 

Problem is, build compiles successfully, but I can't run the program. I also cant remote debug it either - I can connect, but there are no errors shown, even though there are clearly errors. 

I can also successfully build the failing vi/module and run it as an exe. Just not when included and called as above. For all my module VIs in the Source File Settings I have Remove Front Panel and Remove block diagram disabled. Debugging is enabled for all of them too. 

In the sub-VI that starts all the modules, if I skip over the iteration shown above, even if I include the module's main VI in the build and all the libs, the program runs. 

What am I missing in terms of trying to debug this? 

[altenbach]

Since you create the reference by name, can you ensure that it is in the "always include" list of the build spec.

(In general, a static VI reference would probably be a better choice, because the dependency will be clear to the builder.)

[chops88]

It's definitely Always Included, along with the rest of the async VIs in the system. Curiously, when I DONT include it, it will build _and_ run. 

I guess I'm going to draw up the async call alone for that VI and try to build that and debug it. 

Just don't understand why it knows there are errors but won't tell me what they are...

[Kyle97330]

Right now you are using static constants for the VI path/name and the VI connection pane.  I think it's always better to do any calls to async VIs by getting the connection pane and the path or name from that VI, rather than having them hard-coded.  VI names can change, they can get relocated on disk, and you might want to change the VI's connection pane.  If you do any of that, you'll also have to change those hard-coded constants.  So instead, do this:

1. Drop a "Static VI reference" from the application control palette.

2. Link that static VI reference to your VI that you want to run asynchronously (either drag and drop it on the static VI reference, or right-click the static VI reference and choose "Browse for path")

3. After inserting the reference, right-click it and change it to be a "Strictly typed" reference.

4. Add a property node, link it to the static VI reference, and get either the "VI name" or "VI path" property.

5. Link everything to your "open VI reference", wiring in the name or path you just got as well as the VI reference wire.

If you do all that, any changes you make to your async VI will automatically update the connection pane and its name or path if any of those change, and it will be automatically included in the build!

The main reason you might not want to do that is if you are designing code that you don't know which async VI you want to run during compile-time.  It doesn't appear that this is the case for you, though.

[chops88]

Thanks for that suggestion. That's the way I always meant to look for 😄 

However, exe still wont run or debug if I include the VI in question. I can diagram disable it out of the subVI that references it, and program runs normally. 

Going to try to setup a test where build a simple exe that calls that exe async and see what happens. 

[chops88 · Accepted solution]

Gahhh. Solution was Disconnect TypeDefs from the new SharedVars I created. I knew this years ago when I had to debug something like it back then. I wish LabView would indicate this is a problem in the error msgs instead of just shrugging. Instead, I painstakingly and manually debugged by disabling swathes of the VIs, building again and again, gradually homing in on the issue. 5-6mins of build every time over 5-6hrs. My forehead is bloody from hitting the desk.... 

Thanks for the tip about the static VI ref. Makes way more sense.