该内容不适用于您选择的语言

该内容将以另一种语言显示出来。 您可使用浏览器的翻译功能查看内容。

Insane Object or fpsane.cpp Error in LabVIEW

Updated May 18, 2023

Reported In

Software

  • LabVIEW

Issue Details

  • I received a message about an insane object error in my LabVIEW program. What does an insane object error mean and what should I do?
  • My LabVIEW program is getting the following message when trying to compile:
Fatal Internal Error 0x1A7102DF: "fpsane.cpp", line 554 
 
LVFatal.png

Solution

This message means that an object in LabVIEW such as a wire or a loop tunnel does not pass an internal test known as a sanity check (see examples of insane object errors in Additional Information below). If the errors are serious enough, LabVIEW exits because something has become corrupted. Sanity checks occur before each save, to ensure that corrupted VIs are not written over good VIs. They also happen as part of the compilation process. Thus, sanity checks happen frequently. Many insanities are actually fixed (made sane) after the dialog box appears and will not appear again, so the first thing you should do after receiving an insane object error is to try to make a backup copy of the VI, run it, and perform some additional editing to see if the problem was resolved automatically.

VI corruptions do not happen often. They can happen because of disk corruption, but this will often lead to a file that can no longer be loaded. Corruptions can also happen because the programmer did something that corrupts a LabVIEW data type, perhaps as the result of a call to external code.

The following steps will help to diagnose the cause of this error and troubleshoot the issue:
 
  1. If the VI is small, try selecting the entire diagram and copying it to a new VI. After saving the new VI, there is a good chance the insane object error will no longer appear.
  2. If the VI is too large to do the above step, you can copy the VI to disk (or to your network if that is available) and open it on the second machine. If the insane object errors do not appear, save the VI (on the second machine) and transfer it back to the original PC (by disk or by network). The new, uncorrupted version of the VI should now run without generating the insane object error.
  3. If LabVIEW crashes and is not able to load the VI, try opening the VI on a higher version of LabVIEW. In some cases, it is possible to recover part of the VI when it is opened in a different version of LabVIEW.
  4. Look at the error log and determine if the problem appears to be with a component (wires, controls, indicators, etc.) on the front panel ("FPHP") or block diagram ("BDHP") (see Error Log contents section below). Delete and recreate the most recently created objects and make use of the text in the error message in deciding which objects to rebuild. Example: In the case of the second message above, it would be best to delete and recreate the most recently created loop tunnels. There is also a way to directly find the objects from the error log messages as explained in the Finding insane objects section below.

 

Additional Information

Error Log contents
The following are examples of insane object errors:
  • Insane Object at BDHP+4D50, UID 1562, in "sksks.vi": (graphics) (0x80):wire segment (WIRE)
  • Insane Object at BDHP+5CA0, UID 5864, in "CAPL3.vi": (graphics) (0x80):loop tunnel (DCO)
In the first example above, the error message itself gives information about which object is insane. BDHP means the offending object exists on the block diagram heap, as opposed to the FPHP for front panel heap. The +4D50 is the hex offset in the heap where the object is located. Each element in the front panel or block diagram of a VI can be identified through its UID The "Wire Segment" text indicates that the object is a wire object. The "graphics" text indicates that the insanity is graphics-related, which means it is not serious and will most likely be repaired automatically.

The second message above is similar, but refers to a loop tunnel (i.e., the tunnel formed where a wire crosses the edge of a loop) rather than a wire. Many of these "insane objects" are reported as fpsane errors, and you should look for the actual error by opening the log file.

Finding insane objects
There is a way to locate insane objects from the error log in the respective VI directly using the UIDs in the error message.
  1. Close LabVIEW
  2. Add the key "LVdebugKeys=True" in the LabVIEW.ini file located in the LabVIEW installation directory (C:\Program Files (x86)\National Instruments\LabVIEW 20xx)
  3. Open the corrupt VI
  4. Press Ctrl+Shift+D+H to open the heap peek window (see picture below)
  5. Select the VI with the corrupt object and FPHP or BDHP accordingly in the lop left window (Temperature Limit.vi in the example)
  6. Click UO to change the view from memory address to UID in the top right window
  7. Select the object with the UID from the error message in the top right window
  8. Click F, now the according object will be highlighted in the Front Panel/Block Diagram