Argh, Exe builder says my VI is broken, but it's not

[george seifert]

I had built this VI several times with LV 2009. Now since I loaded Service Pack 1 I'm getting an error when I build an executable that says this:

The VI is broken. Open the VI in LabVIEW and fix the errors.

Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi -> AB_UI_Frmwk_Build.lvclass:Build.vi -> AB_UI_FRAMEWORK.vi -> AB_Item_OnDoProperties.vi -> AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

Well my VI isn't broken and it runs fine in the development system. I've shut down and restarted LV with no luck. I can't see anything odd in the project. Any ideas? I just know NI is going to tell me to rebuild the project if I call them. BTW, I am able to build other executables.

<br><br>George<br><br>PS. I just rebuilt the Exe builder with no luck.<br>

Edited February 24, 2010 by george seifert

[gmart]

Just to be clear. The only thing that changed between the build working and not working was the installation of SP1? You made no other changes to the code?

What is the make up of your top-level VI? Does it use classes, variables, drivers, Mathscript etc?

[george seifert]

Just to be clear. The only thing that changed between the build working and not working was the installation of SP1? You made no other changes to the code?

What is the make up of your top-level VI? Does it use classes, variables, drivers, Mathscript etc?

Well yeah I made changes to the code, but I think the point is that the code runs fine. The only thing the error says is to make sure the VI isn't broken and that it runs.

Let's see, nothing too fancy in the top-level VI, no classes or Mathscript. I do use some DAQmx VIs. I built an executable in another project that uses similar DAQ calls.

George

[Antoine Chalons]

Hi,

I had the same issue a few times with LV 8.6, at the time I had the feeling it was due to editing VIs in the LV.Dialog context ; I was debugging some utility VIs I made (VIs started from the File menu).

The solution for me was simply to close LabVIEW, relaunch and my build process would work again.

[george seifert]

Hi,

I had the same issue a few times with LV 8.6, at the time I had the feeling it was due to editing VIs in the LV.Dialog context ; I was debugging some utility VIs I made (VIs started from the File menu).

The solution for me was simply to close LabVIEW, relaunch and my build process would work again.

I rebooted LV a second time and now it's working. Very strange.

George

[Antoine Chalons]

I rebooted LV a second time and now it's working. Very strange.

George

Are you using JKI RCF or are you playing with home-made VIs in another context than the main LabVIEW instance?

[george seifert]

Are you using JKI RCF or are you playing with home-made VIs in another context than the main LabVIEW instance?

No to the JKI RCF and I don't really understand the second part of the question. I'm not doing anything funny with VIs like dynamic launching or subpanels.

George

[Antoine Chalons]

I don't really understand the second part of the question.

Sorry I wasn't very clear.

What I call utility VIs are VIs you can plan in folders such as <LabVIEW folder>\wizard or <LabVIEW folder>\project, they can be launched respectively from the "File" or "Tools" menu bar.

When these VIs execute they are in specific LabVIEW instance(or context), not the same instance were your project's VIs are.

When editing VIs in this specific instance, you get some strange behaviours (e.g. broken arrow but VI is runnable) and I have notice that when I play too much into this, I get the same error as you got. It's just a feeling I had, maybe this issue is totally disconnected from that...

So I was asking this to see if it could be the cause, but apparently not.

[PJM_labview]

Well yeah I made changes to the code, but I think the point is that the code runs fine. The only thing the error says is to make sure the VI isn't broken and that it runs.

Let's see, nothing too fancy in the top-level VI, no classes or Mathscript. I do use some DAQmx VIs. I built an executable in another project that uses similar DAQ calls.

George

I have a very similar thing happen to my customer. He use a lot of classes and he keep getting error 1502 (Cannot save a bad VI without its block diagram.) [Note: Everything run fine in the IDE, nothing broken]. He spent several days trying to fix this, without success. For now he has to enable the debugging flag to be able to build an exe.

Between this error (1502) and error 6 (file I/O=Path too long), building an executable is getting really difficult.

This really need to get fixed.

PJM

[gmart]

I have a very similar thing happen to my customer. He use a lot of classes and he keep getting error 1502 (Cannot save a bad VI without its block diagram.) [Note: Everything run fine in the IDE, nothing broken]. He spent several days trying to fix this, without success. For now he has to enable the debugging flag to be able to build an exe.

Between this error (1502) and error 6 (file I/O=Path too long), building an executable is getting really difficult.

This really need to get fixed.

PJM

It's usually difficult to reproduce 1502 errors since their root cause is typically unique to the setup that has a problem. In order to track down the root issue, I would say try to get a set of code that reproduces the problem and submit that to NI support for evaluation. Regarding the error 6. What were the circumstances where the error occurred? Was the user's destination path for his built very long? What OS? What modules/toolkits were involved? Again, reporting this information also helps with tracking down the problem.

[Aristos Queue]

I have one of those errors... tracked it to a LV class that has in its private data control a strict VI Refnum that used the class itself as part of the conpane. Any chance that's your bug?

[jgcode]

Between this error (1502) and error 6 (file I/O=Path too long), building an executable is getting really difficult.

This really need to get fixed.

I have complained before about Error 6 but am still of the opinion that it is better than having files outside of the build.

I would be nice if NI could do the build in a temp directory (as close to the root as possible) to avoid this, then copy it back to the dist location - all transparently (I currently have to use a script to do this manually).

I have also had the annoying problem of Vague Errors in builds.

The fastest way I have found to identify the issue is to

• Build after integration - so I can keep track of what the problem may be down to
  
• Disabling/removing modules of code and rebuilding until it works - when it works, the last thing I removed may be the culprit and I can build a test VI to confirm.
  

Does anyone has any other/better ways?

In the past, for me, these issues have been caused by e.g.

• Dot Net calls, the client PC did not have the framework installed, but all I got was a Vague Error
  
• Dirty class (once), I have no idea why but it would work in source but not in the build, I had to delete it and start again
  

The first one can be avoided by prechecking registry etc... but a descriptive message would be appreciated

I do not know why LabVIEW cannot return better diagnostic information when this happens?

[PJM_labview]

I have one of those errors... tracked it to a LV class that has in its private data control a strict VI Refnum that used the class itself as part of the conpane. Any chance that's your bug?

I don't think that this is the case (but I will check to be sure). In our situation, the lvclass contain a DVR to a strictly typed cluster.

Something that I forgot to mention is that this is happening with LV 2009 service patch one.

PJM

[PJM_labview]

It's usually difficult to reproduce 1502 errors since their root cause is typically unique to the setup that has a problem. In order to track down the root issue, I would say try to get a set of code that reproduces the problem and submit that to NI support for evaluation. Regarding the error 6. What were the circumstances where the error occurred? Was the user's destination path for his built very long? What OS? What modules/toolkits were involved? Again, reporting this information also helps with tracking down the problem.

My customer tried to isolated it but he was not very successful.

One of the work around that has worked for me in the past (when dealing with this issue [1502]), was to isolate the lvclass with problems in a separate virtual folder in the project, then create a separate rule (as dynamic VI) in the build spec. We were initially successful with this approach (after we pealed off all we could except the dependencies and ancestor from the project) but as soon as my customer started to add back the other classes in, they also start to brake with error 1502.

I would LOVE to be able to isolate this issue so I could submit it to get it fixed.

Regarding the error 6, I have a pretty good handled on it now and I know what to do to get rid of it (basically target build should be short [ie: c:\Build] and rename all VIs that are too long if this is not sufficient).

I have complained before about Error 6 but am still of the opinion that it is better than having files outside of the build.

I completely agree with that.

PJM

[jgcode]

...was to isolate the lvclass with pb...

Hi PJM, what is pb?

[Antoine Chalons]

...was to isolate the lvclass with pb...

Hi PJM, what is pb?

"pb" is a usual abbreviation for "problem", so I think that means "to isolate the lvclass that causes the issue"

being french helps understanding other french << this is an off topic comment, please don't take it as a starting point for "thread hijack"

[jgcode]

"pb" is a usual abbreviation for "problem", so I think that means "to isolate the lvclass that causes the issue"

being french helps understanding other french << this is an off topic comment, please don't take it as a starting point for "thread hijack"

Thanks, I did try google before I posted, now if I try "pb + french" I get it!

[PJM_labview]

Thanks, I did try google before I posted, now if I try "pb + french" I get it!

Oops, I never realized that native English speaker never got that "pb" abbreviation. I shall be more careful in the future...

Thanks Antoine for the translation

PJM

[Rolf Kalbermatter]

I do not know why LabVIEW cannot return better diagnostic information when this happens?

Well, LabVIEW has a LOT of error information and much of it has gotten fairly descriptive over time. So part of the problem may actually be the amount of error information that is already there and that makes identifying areas that can be improved a bit hard. Also maintenance of all that information has to be a real nightmare by now.

[jgcode]

Well, LabVIEW has a LOT of error information and much of it has gotten fairly descriptive over time. So part of the problem may actually be the amount of error information that is already there and that makes identifying areas that can be improved a bit hard. Also maintenance of all that information has to be a real nightmare by now.

Well... "Development Environment is required to fix error" and "Dynamically launched VI cannot run because it is broken" (or whatever) are cases where LabVIEW is not descriptive enough in my book.

[Rolf Kalbermatter]

Well... "Development Environment is required to fix error" and "Dynamically launched VI cannot run because it is broken" (or whatever) are cases where LabVIEW is not descriptive enough in my book.

I know and agree.

But I have been guilty myself sometimes to not create to meaningful error messages when developing a new component, but instead use a catch everything single message, of course with the sincere intention to go back and make it all nice and clear, once I have a grasp about what sort of errors can happen in that component. And then when the release data approaches those intentions are just that, intentions.

And once inside a product only bug reports or improvement requests (through the proper channels though) will really be effective.

[jgcode]

But I have been guilty myself sometimes...

Haven't we all...

[curiouspuya]

Hi all,

So was this problem solved in the end?

I am having similar problems building an exe from a project that uses many GOOP4 classes.

Puya

[hooovahh]

I remember someone mentioning a similar problem, where their code was running fine, but a broken arrow in the build. They said the issue was that during the build process it looks at all the VIs that are dependencies and determines if the code is broken.

He had a test VI that was broken in a disabled diagram structure, so the code would run just fine in development, but the VI was still a dependency. I hope I'm not re-telling his story wrong but I would suggest searching for the disabled diagram structure and see if there is any broken code in any of them. Just a thought.

[CharlesB]

Got it here too. Strangest is that it happened twice. In the same week.

I build the executable quite frequently (not continuous integration though) and never got it before.

The project is quite big (700 VIs not counting vi.lib and OpenG), so finding the error was a pain since building Exe takes 10 mn.

First time was solved by replacing a subVI (which was just updating a cluster) by its code and deleting the subVI.

Second time (happening on a simple VI with a global variable) was solved by unchecking "disconnect typedefs" and "remove polymorphic VIs"

I'm source-controlled so I can give the snapshots of my project when the bug happened, if NI guys want it for repro no problem.

This problem needs to be fixed for real, it's giving pain to a lot of large projects, from what I saw on NI forums