Insane object BDHP +828B4 {graphics} (0x80):Front Panel Terminal (Term)

HEllo!
In my vi appears several erros messages like this
insane object BDHP +828B4.....front panel terminal or wire segment.....
I don't know why it appears.
I'm looking for a solution and i thin there are two ways:
-copy to a new block diagrama all this one. But my vi is so big and this is a problem.
-There is another solution in this way:
close labview
put LVdebugkey=TRUE on Labview.ini
open vi
press CTRL+SHIFT+d, the press CRTL+SHIFT+h
then it appears a list box
The problem is that i don't find the LVdebugKey in Labview.ini...where is it??
Anfd when i press CTRL+SHIFT+d, the press CRTL+SHIFT+h nothing appears.
Where can i find this debug key and which is the right way to solve this problem without copying to another VI.
Thanks!!
Larson

Ok, the correct way is like this:
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 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
8) Delete this object and recreate it. It will ususally be a wire.
But whwn i arribe to the point number 7 i click the F button and all the block diagram disappear....all is clear and the scroll bars are disappeared too.
What i have to do??
P.S:i've saved a copy from the original VI
Thanks
Larson

Similar Messages

  • An alert messarge i don't underdant: insane object at BDHP + 83ACC in "VI name's":{graphics} (0x80):Front Panel Terminal (Term)

    Hello!
    I don't know why in just yesterday appear in one of my VI an alert message or error message when i want to close oer save the VI.
    The message is like the following one:
    Insane object at BDHP + 93ACC in "Vi name's": {graphics} (0x80}: Front Panel Terminal   (Term)
    I don't know why now it appears this message because i have no modify the Vi.
    I want to ask you why it appears this message and the most important......how can i solve it?
    Thank you very much
    Larson

    Hi!!! I copy and paste from an NI engineer post asking about what is the "insane object" problem:
    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. If the errors are serious enough, LabVIEW exits because something has become very 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 compile 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 are examples of insane object errors:
    Insane Object at BDHP+4D50 in 'sksks.vi': (graphics) (0x80):wire segment (WIRE)
    Insane Object at BDHP+5CA0 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. 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.
    Solution: If you receive an insane object message, it is best to delete and recreate the most recently created objects on either the front panel or block diagram, depending on whether the error message contains "FPHP" or "BDHP". Make use of the text in the error message in deciding which objects to rebuild. In the case of the second message above, it would be best to delete and recreate the most recently created loop tunnels.
    Another workaround that works best if the VI is small is to select the entire diagram and copy it to a new VI. After saving the new VI, there is a good chance the insane object error will no longer appear. If the VI is too large to cut and paste to a new VI and another computer with an identical version of LabVIEW is available, 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.
    Hope that helps you,
    Jaime
    Regards,
    Jaime Cabrera
    NI Applications Engineering Spain

  • Insane Object BDHP+58EBC, and +58DD4. Please help?

    I have tried the suggestions in the KB "What is an Insane Object Error Mean and What Should I do?", but they did not clear my error. My vi functions normally, but I am concerned that this error may cause a "booby-trap" to be lurking in my distributed application, that may show up at a later date as a crash, or worse. The vi is 4 meg plus in size, so I REALLY have no desire to start from scratch!
    Any suggestions??
    Thanks
    Dave

    Well copying the code to a new blank VI didn't work for me (and it also would have unlocked my state diagram anyways). What _did_ work was to create a copy of the VI, and delete chunks and save until the error went away. I managed to get lucky (with some deduction) and find the offending wires. Is there no way of giving us more information than the heap offset? (Is there any way to use this number to find the offending object?)
    The insane object error started appearing for me when I edited an enum type def that was used all over the place. The offending wires were wired from a constant of this type def.
    Jaegen

  • Need your help, How to write a program such as drag the objects to the front panel like using the LabVIEW Front Platte

    Dear all:
    Sorry for so long title.
    I need your help with how to drag the objects and drop onto the front panel.
    Like the LabVIEW front platte, i can choose the objects i can drop onto every where of the front panel.
    Could drag and drop function can satify?
    Any idea?
    Thank you
    Attachments:
    Image00000.jpg ‏75 KB

    What you want to do is relatively complicated and it seems that your knowledge of LabVIEW is relatively basic. I suggest you try searching this site and google for LabVIEW tutorials. Here, here, here, here, here and here are a few you can start with and here are some tutorial videos. You can also contact your local NI office and join one of their courses.
    In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).
    Try to take over the world!

  • Programmatically resizing Front Panel does not repaint

    I am trying to extend the width of a front panel at run time when a user hits a button. The problem is
    that the contents of the newly exposed front panel section are not redrawn. I have to either drag
    another window over that section or minimize-maximize it to get it to repaint.
    My issue is how can I get the front panel to refresh/repaint, or if that is not possible what other
    ways are there to do resizing. I have tried changing the "Window Bounds" and "Panel Bounds" properties of
    the VI (not at the same time) as well as using LVWUtil32 (Windows API Function Utilities (32-bit) for
    LabVIEW). Each of these methods results in the same problem.
    Thanks for the help!
    Naveen

    HI Naveen,
    It seems to me that you are having Problem with your Graphics Hardware, rather than labview. Generally the window should be repainted by system.
    If you go to Display Properties -> Settings -> Advanced -> Troubleshooting or Graphic Acceleration - You may see the slider to full Acceleration. Under this setting the OS basically relegates most graphic duties to Graphic Hardware.
    What you may want to do is to Move the slider a couple of notches back. And then try your VI's. Infact try all the settings on your Slider. See if it works at No Acceleration.
    The Problem for me is I do not Have this Problem and cannot even simulate it to try a solution.
    Another Solution is this -
    There is a vi Property Class called "Front Panel" Which can be access
    ed from Vi Server. Under this Class you will see a Property "Defer Front Panel Update" Generally this Property is used to Prevent a redraw. But if this Property is set to False, Labview immediately redraws the Panel.
    What you may want to do is after resizing to let you program go through this Property Node set to False and See if this Helps.
    By The way, the way you have to wire this Property is to Open a Vi Ref, Wire it to Property Node, Select Property as "Front Panel". Right Click on "Front Panel" and Click on Create-> Property -> Defer Front Panel Update. Wire the Referneces of the these Objects, with the output of "Front Panel" going to "Defer FP Update".
    I hope your ver of Labview has these Properties. I am Using 6.1
    I hope you can take it from there!!
    Please advise How you solved the Problem. Good Luck!!
    Mache
    Another Solution which you can try is this
    Good Luck!
    Mache

  • Front panel is not shown completely.

    Hi.
    I have worked on a project more than three months and last week I was faced with a strange problem. When I switch from 'block diagram' to 'front panel' window it is not shown completely. I had this problem in LabVIEW 8.0 then I removed it completely and installed LabVIEW 8.5 but after two or three days it happened again. I do not think it is related to my laptop because I tested it on three different computers. I deleted all objects in 'block diagram' and 'front panel' windows but the file still has this problem. I attached my file and some images. When I compile and make an executable file it still has the problem. The 'image3.jpg' shows that file. When switch from another window like word to this window it is not shown completely. I do not know what to do.
    Thanks a lot.
    Attachments:
    Main.vi ‏5 KB
    image2.JPG ‏147 KB
    image3.JPG ‏127 KB

    I tested your VI in 8.6.1 and observe similar redraw problems. I suspect something is corrupt.
    Have you tried starting with a new VI and copying you old code over?
    LabVIEW Champion . Do more with less code and in less time .

  • Save sub-vi's (possibly closed) front panel image to a file

    Hello,
    I would like to dump a file of a sub-vi's front panel when that sub-vi completes execution. I was thinking of using the  "Front Panel:Get Image Method", however the target sub vi's front panel might not be opened. I am looking through the help file, and it says
    "If you do not want to display the front panel but want the image to reflect value changes, create a Property Node from any front panel terminal on the block diagram of the VI for which you want to create a front panel image."
    I'm not quite sure I understand what that means. Can anyone provide an example?
    I am running LV 8.2 for the record.
    Thanks,
    -Ted

    Hi Ted,
     "If you do not
    want to display the front panel but want the image to reflect value
    changes, create a Property Node from any front panel terminal on the
    block diagram of the VI for which you want to create a front panel
    image."
    What that means is to create a property node for something (anything) in your Sub-VI.  
    I have attached an example for you with a dummy property node. And the front panel of the Sub-VI gets updated on the Main-VI. Try removing the property node in the Sub-VI and you will notice that even though the values are correct in the main-vi, the image of the sub-vi doesn't get updated. 
    Hope this helps!
    Warm regards,
    Karunya R
    National Instruments
    Applications Engineer
    Attachments:
    MainVI.vi ‏15 KB
    SubVI.vi ‏10 KB

  • Why does the error message "insane object at BDHP+7404 in the VI(GRAPHICS)0X80;(wire segment)WIRE."show up

    what does "insane object at BDHP+7404 in the VI(GRAPHICS)0X80;(wire segment)WIRE." mean.

    Visit NI knowledge base site and search for "insane object". You will find a full explanation and a solution in this KB: What Does an "Insane Object" Error Mean and What Should I Do?

  • "insane object at BDHP+7404 in the VI(GRAPHICS)0X80;(wire segment)WIRE.

    "insane object at BDHP+7404 in the VI(GRAPHICS)0X80;(wire segment)WIRE.

    Visit NI knowledge base and search for "insane object" you will find a complete explanation and a solution in this KB: What Does an "Insane Object" Error Mean and What Should I Do?

  • Insane object at BDHP+420E30 in "IHMconfig.vi": {graphics } (0x80): Wire Segment (WIRE)

    Hi
    After sending by email my program folder zipped with winrar I receive an dialog box error saving one of the VI   ( Insane object at BDHP+420E30 in "IHMconfig.vi": {graphics } (0x80): Wire Segment (WIRE)  ) and series of the error with another code error.
    I don't know where does that come from , does anybody have a suggestion?
    thanks
    Olivier

    Have a look here.
    Try to take over the world!

  • Error while saving VI - Insane Object at BDHP

    Good Morning,
    While saving Application VI, LabVIEW is giving warning as "Insane Object at BDHP+19CECC IN "Main.vi" : {graphics} (0X80) :Wire Segment (Wire)"
    I am curious to debug this Warning. Would it impact in future development. Without harming to development of VI, I would like to clear it. If anybody has idea about this, it would be great help for me.
    Also I am attaching Error as document file.
    Thanks,
    ii.
    Attachments:
    LabVIEW_Error.doc ‏74 KB

    You should be able to find the object that caused the error and remove it by following the procedure outlined here.
    Try to take over the world!

  • Overlapping Front Panel Objects

    I understand that overlapping front panel controls (booleans, numerics, plots, etc.) will cause a significant update penalty.  What about using tab structures or decorations from the modern/classic pallete (such as raised block, recessed block, frame, things like that)?  Will this cause a severe penalty in processor time?
    Nathan - Certified LabVIEW Developer
    Solved!
    Go to Solution.

    Natan,
    Any stacking of objects will cause a performance hit.  Now, depending on your program, it may not be a big deal.  I did a bit of work with this several years ago, so I am assuming not much (basics, at least) has changed.
    LabVIEW basically draws from the bottom up, so whatever you have stacked, the bottom element is drawn, then the one above it, etc.  Although I do not know for sure, I expect this happens within the control as well.  For example, a numeric control has several layers to it.
    When I did all my work, I saw a tremendous hit on performace without too much stacking.  The test time was 3:30 with th UI I created.  If I did not display the UI at all, I knocked over 45 secs off the test test.  With simnplifying the UI, I think I knocked about 30 secs off.
    What I also found is that the quality of your graphics chip has significant effects.  I was testing with the second model of the PXI controller (this was maybe 12 years ago),  I could outperm the PXI controller with a low end PC using MXI because it had a dedicated graphics card that handles the UI updates much faster than the PXI controller.

  • Closing references to front panel objects

    Short version of my question: are programmatically generated references to front panel objects (controls, etc.) automatically disposed of when the VI exits?
    More details: I'm recursively retrieving references to all the controls on the front panel.  (I say recursively because I'm also getting the individual controls from clusters, subclusters, and so on.)  I then return an array of control references, which does not include the references to clusters--only standalone controls or the actual controls themselves contained in clusters.
    Do I need to explicitly close the references to clusters that this VI generates, or is it unnecessary since the VI will run briefly, return an array, and then exit?
    Or another scenario: in a subVI I open a reference to the parent VI.  Do I need to close that reference at the end of the subVI, or is it pointless because the reference will be disposed of when the subVI exits anyway?
    (I did find this article, which I think addresses my question, but I'm not sure.)
    Thanks,
    peppergrower 

    http://forums.ni.com/ni/board/message?board.id=170&thread.id=159571&view=by_date_ascending&page=1
    Jean-Marc
    Jean-Marc
    LV2009 and LV2013
    Free PDF Report with iTextSharp

  • Printed front panel graphics quality (Print Panel to Printer method vs. Append Front Panel Image to Report.vi)

    LV 6.02 (or 6.1)
    NT 4.0
    I have a vi that the front panel includes all the information I need to print except that it is on different pages of a tab control to conserve screen space. I was attempting to programatically cycle the value of the tab control in a For loop and invoke the Print Panel to Printer method to print 7 pages of the front panel, each with a different tab page selected. The printouts were excellent quality but beginning with the second consecutive Print Panel to Printer method the on screen front panel image of the VI being printed would become jumbled (sometimes, by the time 7 printings were done, the entire front panel image would disappe
    ar and a bitmap of the desktop or underlying windows would be visible in the VI's panel frame) yet the subsequent Print Panel to Printer methods continued to print the panel as they should appear. The visible front panel graphics would never return to normal and the only solution was to close the vi (in the dev system) or exe (compiled) and re-launch. I tried a lot of things (like hiding the panel to print before printing and showing it after printing) with no luck. It appears that two or more of these consecutive invoke methods caused the problem regardless of whether the tabs were cycling, or even if there was no tab control and much fewer controls on the panel to be printed than normal. I also had the same problem with LV 6.1.
    Finally, I was forced to switch to the report generation toolkit vi's, I cycle through the tab pages and use the Append Front Panel Image to Report.vi to append each image to the report. This is faster and control returns to my program quicker but I a
    m unhappy with the printed quality of the graphics of the front panels. They are not as high of resolution as those generated via the Print Panel to Printer method.
    Any suggestions?

    You might try changing the way the VI is printed by going to tools >> options >> printing. Try the postscript and bitmap settings.
    Jeremy

  • Why doesn't LabView scale my objects properly in the front panel?

    In LabView 6.02 (Windows 2000) I have experienced problems when using the "Scale all objects on panel as the window resizes" option under VI properties. Try the following example: Go to the front panel and draw two arrows (from Decorations), one vertical and one horizontal (make sure they are perfectly straight). Now, resize the window, using the bottom right corner several times. You will soon find that the two arrows become increasingly missaligned and are not perpendicular to each other anymore. The problem gets worse the more you play around with the window size and they will never return to their original state. Installing the 6.02 patch did not seem to help at all.

    Dear Gustav,
    First of all, some objects do not scale whatsoever in LabVIEW. These include refnum controls and text.
    As far as the "scale all objects on the front panel as the window resizes" option goes, you have brought attention to an issue that I will announce to the R&D team. Currently, when you resize the screen, the objects on the front panel are resized at the same fraction of the original size, yet small rounding errors occur. As you move the window around, this small rounding error multiplies accordingly. Once you maximize the window, the small rounding error is translated into a large-scale degree change in the orientation of the (previously) perpendicular arrows.
    What action are you trying to perform that caused this issue? If possible,
    please post some screen shots of your front panel or give me explicit details as to your programmatic goal.
    One thing that you may try in order to prevent this misalignment and orientation shift is to highlight the arrows. Then, click the "Reorder" button on the toolbar and select [lock]. This will lock the objects and prevent them from resizing while the rest of the screen resizes (see attached image).
    Again, I'm sorry if the aforementioned phenomenon causes you any inconveniences, and I will be sure to announce this issue so that preventive changes are implemented in future LabVIEW revisions.
    I hope this helps. Please let me know if you need any further assistance. Have a great day!
    Kind Regards,
    Joe Des Rosier
    National Instruments
    Attachments:
    lock.JPG ‏33 KB

Maybe you are looking for