Build breaks because vi is broken ... but it's not :/

[kutt]

Hey everyone!

First of all: I wish you all a Happy new year!

I'll try to get it compiled next week.

To get on track, what I tried (and not changed anything):

• always include all files
• don't use: "Conditional Disable Structure"
• Tools->Advanced->Clear Compile Object Cache
• Do you have an uninitialized shift register that contains a class? --> no
• I use x64 DLL's (dotNet) (PE32+ executable (DLL) (console) x86-64 Mono/.Net assembly, for MS Windows, 2 sections)
• Tried everything in:  Error 1003 Occurs When Trying to Create an Executable
• Tried everything in:  Error 1502 When Building an Application in LabVIEW
• reinstalled LabView
• save Project "as new"

I still have to try the things which came in after the 23.12.2024, but the PC is switched off right now. I have start it up next week for some further tests.

PS: I also pointed the NI Support to this topic. They asked me the same questions you did in this topic anyways 😉

[daveTW]

Hello kutt,

happy new year back to you!

Now when I had a look to the beginning of your thread I think I would try it with exclusion procedure.

1. Are you able to build an executable just from the "broken" VI? (perhaps you need a wrapper VI -> place it on a blank diagram, select it, then Ctrl+space, Ctrl+d)
2. You can uncomment parts of the BD with the "Diagram Disable Structure" -> first disable all, then successive add parts of the code

[Kyle97330]

Something else you can try:

The build process is just a series of VIs that run.  Many are password-protected, but many are not.  If you look at the call chain of the code generating the 1003 error, you can see that "AB_Targetfile.lvclass:Open_Top_Level_VIs.vi" is 2nd from the top.  That VI is not password-protected and you can find it here:

<vi.lib>\AppBuilder\AB_Classes\TargetFile\Open_Top_Level_VIs.vi

This is its block diagram:

In theory, you should be able to find that VI on your PC and modify it to be something like this:

My example here does two extra things. 

First I added an error handler inside the "Bad" frame.  The "Get broken VI message" subVI there is outputting a blank, so it's possible that the property node reading Exec.State is throwing an error, since "Bad" is the default output if the property node isn't working.

Second, whatever VI triggers the error is passed out and I set it to get all of its dependencies, and make a list of which ones report as bad (i.e. broken) as well.  That should hopefully not only list out the main VI, but all the subVIs that are broken and you can hopefully narrow it down to which sub-sub-subVI the actual problem is inside and do more intense debugging/analysis on that.

If neither of these changes helps, you can try other things inside this same VI, since the whole "can't click on the run arrow because the build process has focus" thing shouldn't apply if you're running code in parallel to it that should be running while the VI is open and broken.  Without being able to try this on your actual broken VI and seeing what happens, I can't get too creative on your possible options available.

[thols]

---

@daveTW wrote:

Hello kutt,

happy new year back to you!

Now when I had a look to the beginning of your thread I think I would try it with exclusion procedure.

1. Are you able to build an executable just from the "broken" VI? (perhaps you need a wrapper VI -> place it on a blank diagram, select it, then Ctrl+space, Ctrl+d)
2. You can uncomment parts of the BD with the "Diagram Disable Structure" -> first disable all, then successive add parts of the code

---

Agree. Another approach is to create a new "InSanuCore.vi" with no code or just anything that is required for the code not to break, and see if that compiles. Then you add pieces from the original VI bit by bit and see where it breaks.

[kutt]

OK, I'm a bit closer ...

What did I do:

I removed the InsanuCore.vi as "startup vi" and replaced it with a empty vi.

Then I startet to remove vi's from the "always include" section until a build was sucessful.

Now I have a bunch of vi which will break the build. One of the simplest ones look like that:

I kinda was affraid that it has to do something with the "EddyCusClusterAll".

Let me explain a bit further why. I got some code from a colleague to talk to some piece of equipment. This is done by a bunch of DotNet dlls. TBH: It's quite complicated, because I have to deal with a lot of refnums in this pocess. And I mean really a lot. Some are generated in between and need to be closed right away to prevent "Out of Memory" Errors and preventing the RAM to fill up. Some I need to keep for quite some time to close them later properly.

Since I need to calls some tasks dynamically to stop a measurement properly (e.g. my system is running but at some point I don't get any triggers anymore and the DotNet call will wait indefinitely, causing the vi to hang itself up). Since this vi. is running in a seperate Thread, I can stop the measurement in the Core vi, which will lead the hanging vi to continue with a message "No measurement running". To transfer data between the Threads synchronously, Notifiers and Queues are used. For the rest I use shared variables, which are often made from custom type definitions. In this case it's a cluster array. So I can easily pick or update some data for each measurment box. 

Due to the ongoing changing refnums I have to keep, it has also some placeholders for those refnums.

Well it works in the deveoplment enviroment, but I have the feeling the builder can't find the dll's used, which are needed to create thos placeholders in the type definition.

Can it be that simple, that LabView expects the dll's in the root of the project? Right now thy are located in a subdir called "dll", located in the root of the project?

[kutt]

Hey,

I found a workaround by setting the TypeDef as control.

I'm in contact with the NI support and they reported this issue to R&D and marked it as Error/Bug. Maybe I helped to make LabView just a little bit better? 🙂