Insane Objects

Firstly, there is no need to necessarily report generically to NI that LabVIEW has insane objects, as they do know about insane objects. Secondly they are NOT merely bugs: insane objects can be generated as part of the LabVIEW verification process. If you get such a message, it is good to check the known bugs of LabVIEW at ni.com and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its "checksum". In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the front panel itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

The cryptic nature of the message can be deciphered as follows: Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)

• FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
• 4C -- this is a hexadecimal number indicating which object.
• name.vi -- which VI had the insanity
• {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
• Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

Using Heap Peek

The number "4C" is described above as the number that tells you which object. Not exactly helpful to an end user. There is a way to find and delete an insane object. When you get an insane error, you will get a code that shows the object that is insane - write down that code and then:

• Close LabVIEW
• Put the key "LVdebugKeys=True" in your LabVIEW configuration file
• Open your VI
• Press CTRL+SHIFT+D+H. On Mac, use the command key instead of CTRL. This will open a window known to LV R&D as "heap peek" since it gives internal views into the front panel heap and the block diagram heap.
• The window is divided into 4 sections: top-left, top-right, middle, and base. The functionality of the various parts is obscure and mystical, so we're just going to focus on the bits that help with finding and deleting insane objects.
• Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
• In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
• In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
• LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

Note: Care must be taken with heap peek. It has the possibility to change states of objects and doing that without knowing EXACTLY (and I think only a few people in the LabVIEW developer team really do) what you are doing can completely mess up your VI or maybe even more.

I do not think that heap peek has any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, I do not know of any edits. They may exist. The previous author is quite correct in saying that few developers really know the capacities of heap peek. It's a debugging tool, and it gets hacked up to display whatever anyone needs to display.