Insane Errors - how to get rid of

[Lori]

I have LabView 8.0 with a good sized app. I've tried all the suggestions in the prior posts to get rid of the "insane errors" that suddenly cropped up. Nothing has helped. I've tried removing newer components, rewiring, and opening the VI on another computer, saving it and trying again from mine. I created the VI on the demo 8 since we hadn't gotten our licenses yet and then upgraded to the licensed 8. The insane errors started when I was still on the demo. The "insane" error are of a graphic nature, but there is nothing else to suggest what might be causing them.

How does one get rid of these "insane errors"?

I have a lot of them and closing out all the windows is a pain, not to mention I am unable to make an exe because of them.

It would be nice if NI would just list them all in one window instead of popping up a window for each one and point out the bad component.

[bsvingen]

I had the same problem when i wanted to save to LV7.1 format from LV8.0 and i made graphs in LV8.0. I think it's because of a major bug in LV8.0 concerning the graph property causing properties in the property window to be different from the actual properties that can be set directly in the graph window (i think??). LV8.0.1 does not have this problem. The only solution i found was to make completely new graphs "from scratch" (a real pain, but it worked).

[george seifert]

I have LabView 8.0 with a good sized app. I've tried all the suggestions in the prior posts to get rid of the "insane errors" that suddenly cropped up. Nothing has helped.

I haven't seen the previous posts, so I don't know if this came up. This appeared on the NI forum. It worked in one case for me. I had another problem once where a timed loop went bezerk on me. I was getting tons of insane objects. I finally tracked the problem to the timed loop. I replaced it and that solved the problem.

George

The insane objects question comes up from time to time. Here is one way to find the particular problem:

1) Close LabVIEW

2) Put the key "LVdebugkeys=True"in the LabVIEW.ini file

3) Open your VI

4) Press CTRL+SHFT+d, then press CTRL+SHFT+h (I had to press CTRL+SHFT+h+d).

This will turn on an object browser.

5) In the top left list box, select the element that contains the name of your VI and the letters BDHP

6) In the top right listbox, find the line that begins with the error number.

7) Click on the F button to find the offending object.

8) Delete this object and recreate it. It will ususally be a wire.

Bob Young - Test Engineer - Certified LabVIEW Associate Developer

DISTek Integration, Inc. - NI Alliance Member

e-mail: BobY@DISTek.com

[Lori]

That did it George!

Thanks!

[bsvingen]

Christ, and i used a day just to delete and recreate graphs

Suggestion: What about a separate folder here on LAVA for solutions like the one posted? No discussions or remarks, just the solution. I think that would be great.

[crelf]

Suggestion: What about a separate folder here on LAVA for solutions like the one posted? No discussions or remarks, just the solution. I think that would be great.

It already exists: the LabVIEW FAQ. Looks like this one could do with the addition of the object browser reference.

[JasonKing]

A general note about insane object errors:

To avoid saving corrupt VIs, we have sanity-checking code that makes sure all fields of an object are within a valid range (obviously this is a bit of a simplification, but being more specific is unnecessary). We run the sanity checking code before we save a VI (and perhaps when we re-compile, but I am not certain). Ideally the sanity checking code will report the error but also correct the value or reset it to a value to ensure the VI is not corrupt, but it is not always possible to safely "guess" a valid value for each field. This code is both for us to detect errors in our code, but also protects users (read: you) from unknowingly saving off VIs with corrupt objects.

As suggested above, the best course of action is to delete the insane object and start over. It's unfortunate, but it's a lot better than having your whole VI hosed.

While I won't necessarily recommend or condone using internal tools (obviously they ship with and can be turned on in the release version of LabVIEW), what George suggested will help in identifying which object is the offender.

J

[crelf]

...we have sanity-checking code...

Is it LabVIEW-based? Any chance of it ever becomming public? Or even better still, becomming part of the save routine in LabVIEW?

[Rolf Kalbermatter]

Is it LabVIEW-based? Any chance of it ever becomming public? Or even better still, becomming part of the save routine in LabVIEW?

But it is already part of the save routine! That is why you get those error dialogs when saving VIs.

And sometimes recompiling (shift-run tool) the VI helps but often deleting the offending object is the only course. I haven't seen it often since about LabVIEW 6.1 but can't really comment to much about LabVIEW 8.0.x. It's possible that LabVIEW 8 introduced new ways to create insane objects.

Rolf Kalbermatter

[crelf]

But it is already part of the save routine! That is why you get those error dialogs when saving VIs.

What error dialogs? I've never had an "insane error" dialog when saving a VI. I'd like to be able to access it whenever an insane error occurs - like a "more information" drop-down in the insane error dialogs - something like:

...and maybe have access to the last button through a LabVIEW option that's hidden by defualt...

[i2dx]

[...]Ideally the sanity checking code will report the error but also correct the value or reset it to a value to ensure the VI is not corrupt, but it is not always possible to safely "guess" a valid value for each field. This code is both for us to detect errors in our code, but also protects users (read: you) from unknowingly saving off VIs with corrupt objects.

Jason, is this sanity check the reason for "self altering code"? (don't panic) I experience such behaviour maybe every third year, but sometimes it happens (the last time with LV 7.0.x) that e.g. a bundle by name changes the cluster element which is overwritten. This "correct the value or reset it to a value to ensure ..." could be a plausible explanation for such behaviour. ...

CB

[Yair]

but sometimes it happens (the last time with LV 7.0.x) that e.g. a bundle by name changes the cluster element which is overwritten.

That is probably more of a relinking issue with reordered clusters (and more particularly typedef clusters and subclusters).

When you change the order of cluster elements, LV has to relink the bundle and unbundle by name nodes to the right element. There was a bug where this linking would not always happen properly (I'm not sure whether it was fixed yet).