Build error 1502 - but no broken VI

[lgk]

I get error 1502 when building my application. I have attached a screen shot of the error message.

The indicated VI (TLP DSV Main.vi) is not marked as broken in LabVIEW, nor is any other VI in the application.

If I turn on debugging in the build properites, I can successfully build the application, but this is not an acceptable solution.

I loaded the top-level VI in the application (TLP DSV Main.vi) and did a mass compile (held down Ctrl and Shft and then clicked on the Run button) and then tried to build the application. The result was the second screen shot attached (Corrupt VI message.bmp). I then tried pressing the Revert button, the Cancel button, and the X button (close the window) on the title bar and none of them had any effect - the error message window immediately reappeared with the original text. I was forced to use TaskManager to kill LabVIEW. 

I then restarted the computer and tried to build the application again, but the result was the same: error 1502.

What shall I do now?

(Both of the above mentioned screen shots are in the attached "Error 1502.zip" file.)

[Rudi_N]

lgk:

I am sorry you are experiencing such issues with the application builder, I have a few questions for you:

1. Why is it that "turning on debugging" is not an acceptable solution for you? Is there anything about it that is affecting your application?

2. What version of LabVIEW do you have?

Please let me know what you find out.

Regards,

Rudi N.

[fredb]

LGK;

I ran into the same problem. I am using LV 8.20. If you are too, it may be the same problem.

In my case, it was an embarassingly simple problem (which took me over 6 hours to track down). Hope this helps. Open up the VI that Labview is unhappy with - in your case, TLP DSV MAIN. See if you have any case structures hooked up to a constant. If you do, replace the constant with a control (or replace the whole structure with an diagram disable structure).

I ran into a message from NI while upgrading from LV 8.00 to LV 8.20 - something to the effect that it no longer liked to see constants wired into case structures. Someone on my team (most likely me!) probably ignored it - at least on this vi.

The annoying part is that the problem is only reported if I add one extra dynamic vi, in a different library - completely unrelated to the one with the problem.

I hope this helps. Best of luck,

fredb.

[lgk]

Thank you for the feedback.

I remember seeing the warning that you described at a number of places in my application when it was first converted. I did follow the advice and changed the code per the instructions. That was not the problem in my case.

Recently, I did find the problem. It took me approximately 32 hours over two weeks to disassemble the whole application, section by section, but I finally found a particular section of code in a subVI that caused the problem. I deleted the code, recreated it (exactly, no alteration), and the problem went away. Something in the conversion process must've hiccupped and inserted a fatal flaw into the diagram. I knew I was onto something when I deleted a wire, saved the diagram, and then watched LabVIEW crash in pieces around me.

Let's see, 32 hours times $27/hour equals $864. That goes a long ways toward the purchase price of LabVIEW.

[cs42]

---

@Rudi N wrote:
lgk:

I am sorry you are experiencing such issues with the application builder, I have a few questions for you:

1. Why is it that "turning on debugging" is not an acceptable solution for you? Is there anything about it that is affecting your application?

2. What version of LabVIEW do you have?

Please let me know what you find out.

Regards,

Rudi N.

---

I have a similar problem with LV 8.20. A version compiled with debugging activated works, but without doesn't (I get an error on starting the app, not on compiling!).

It is not an acceptable solution because:

1. the exe is much bigger (about 6 MB instead of 2 MB),
2. I suppose the performance is worse (esp. higher memory usage)
3. block diagrams are not removed
4. on loading there's some information about loading SubVIs shown for a short time (takes longer with the debug version, but is shown with the "normal" version as well in LV 8.20, wasn't with LV 7.1.1)

Esp. 3 and 4 are not acceptable if I want to deliver a software to a client!

BTW, I know there're some bugs that can be avoided by changing the code. E.g. subcluster bundling and unbundling. But I have some big projects moved to LV 8.20 and it would take much time to find all occurences of this (too much time). I'd rather prefer a patch, and I expect one!

I'm really wating for 8.2.1!

Cheers,
Carsten

[Rudi_N]

Carsten:

It would greatly help if you could post the smallest amount of code that reproduces this error so that I can test it on my side.

Regards,

Rudi N.

[cs42]

---

@Rudi N wrote:

Carsten:

It would greatly help if you could post the smallest amount of code that reproduces this error so that I can test it on my side.

Regards,

Rudi N.

---

Sorry Rudi, but I can't 😞 It's a quite big project. Not all of the code is nice, but I think my problem is related to ID: 423GHDQ4 described in http://digital.ni.com/public.nsf/websearch/6FA9C264C41FC67D8625724A0069C1DE?OpenDocument It's a GUI project and there I use sub-clusters quiten often...

I'm just waiting for an LV update. I hope this will be fixed in 8.2.1.

Cheers,
Carsten

[Rudi_N]

Carsten:

Thank you for narrowing it down for me. Did the workaround mentioned in the document helped with the issue? Please let me know !!

Regards,

Rudi N.

[Mirko]

I had the same problem with a project in LV 8.20. I replaced the case structures that were wired to constants with diagram disable structures and the application builds fine now. Thanks fredb for mentioning this.

Regards,

[Rudi_N]

Mirko:

I am pleased to hear that things are working fine for you as well.

Regards,

Rudi N.