Insane object error causes LabVIEW 6.0.2 to quit (crash)

When I made a small modification of the wiring diagram and try to save the vi, the insane object error comes up and trashed all the modification. If I restart LabVIEW and apply the same modification, I can usually save the vi without problem. But next time when a new modification is made, LabVIEW would crash again when I try to save the vi. I am running LabVIEW 6.0.2 under Windows 2000.

I have seen the same error as well. It has occured during edit sessions (attempts) on very large (complicated) diagrams when my video settings were at 1600x1200. I have discovered that the errors seem to be related to the video resolution settings AND the size of the block diagram. I have a Gateway twin-cpu workstation with a 1x AGP video card with 16MB of RAM; however, the problem only occurs at high resolution settings. If I set the video to 1024x768, the errors stop occuring. For those applications that require high-res settings, I code at low resolution, close the diagram, change to high resolution, and can work on the front panel with no problems.
PS...
I was able to freeze the screen during one of the failures and found that all of the objects were literal
ly extruded to the same heigth as the wires -- it was really bizarre! The computer was "locked up" so that a screen shot was not possible. I called NI tech support and was told it was a "most likely" a video card problem.

Similar Messages

  • The eig() instruction in my matlab script is causing an insane object error

    I have matlab script in a vi that I want to use to calculate eigenvectors and eigenvalues of a large array. I started with a small array (3x3)and it calculated them incorrectly. However when i ran the same script in Matlab the correct values are returned. On top of that when I try and save the vi after running it I get an insane object error at FPHP+DC. I tried rewriting the vi without copying and pasting etc. but it wont go away. I then simplified the vi to simple integer addition and removed the eig()instruction and error doesn't appear anymore, so it seems that the eig() instruction is causing all of this and it isn't even giving the correct answers! Where does this leave me? I can't get the e
    igenvectors using the Labview vi because the array i will using eventually is (944x944) and the labview vi gives me an error saying I have exceeded maximum iterations. This is why I am using Matlab in the first place.
    Thanking you in advance!!
    Marion

    I had a similar error message come up in the jump from LV 7.1 to LV 8.0.  It would cause a couple of hard crashes of Labview whenever I worked with one particular VI.  I found it was related to a wizard lock control that I had created in LV7.1 using the HMI Wizard options of my DSC module.  I actually had two such loops in my original program, one behaved, the other caused problems in the upgrade of the VI to LV 8.0.
    I discovered this by creating multiple copies of the VI in LV 7.1 and deleting different block diagram elements from each and seeing which opened without error in 8.0 and which caused the problem until I finally discovered the problem piece of code.  It was really a divide and conquer technique.
    I liked how LV 7.1 HMI wizard automatically created code that I could unlock and modify as I needed.  It seems that the HMI wizard was eliminated from the DSC module of LV 8.0 and 8.2. There were several other major changes in the behavior of the DSC module from 7.1 to 8.0 which I am still trying to learn.
    If you can discover which control or what piece of code (hopefully it is only one) is causing the problem, perhaps you can delete it in the older file version, upgrade the VI, then recreate it in the newer version VI.

  • Insane Object Error - Image.cpp

    Is any other LV8.2 user having problems with customizing controls?
    I have only needed to do this today since the upgrade to 8.2, and am having a hard time.  I have yet to come up with an exact method to reproduce this, but it's getting to be a big problem, as LV crashes about 60% of the time when I'm editing controls.
    Is this a known issue?  I did some digging but didn't find anything specific to my problem.  I never had this problem with 7.1 (same hardware in my PC).
    Message Edited by Day on 10-10-2006 04:04 PM
    Attachments:
    Insane Object Error - image.jpg ‏16 KB

    I had a similar error message come up in the jump from LV 7.1 to LV 8.0.  It would cause a couple of hard crashes of Labview whenever I worked with one particular VI.  I found it was related to a wizard lock control that I had created in LV7.1 using the HMI Wizard options of my DSC module.  I actually had two such loops in my original program, one behaved, the other caused problems in the upgrade of the VI to LV 8.0.
    I discovered this by creating multiple copies of the VI in LV 7.1 and deleting different block diagram elements from each and seeing which opened without error in 8.0 and which caused the problem until I finally discovered the problem piece of code.  It was really a divide and conquer technique.
    I liked how LV 7.1 HMI wizard automatically created code that I could unlock and modify as I needed.  It seems that the HMI wizard was eliminated from the DSC module of LV 8.0 and 8.2. There were several other major changes in the behavior of the DSC module from 7.1 to 8.0 which I am still trying to learn.
    If you can discover which control or what piece of code (hopefully it is only one) is causing the problem, perhaps you can delete it in the older file version, upgrade the VI, then recreate it in the newer version VI.

  • How do I fix an "Insane Object" Error ?

    I am receiving an "Insane Object" error when I load one partuclar VI. Is there any way to "copy" the diagram to a new file to fix the corrupted Object ? I am using Win N/T 4.0 and LabView 6i. The module was originally designed using LabView 5.X and the Module appears to work OK after accepting the Error Messages.

    I think the most complete discussion of this situation can be found in the NI KnowledgeBase. Just go to the main ni.com site, search for "insane object" and follow the first hit.
    That KnowledgeBase entry was created with a lot of input from some of the LabVIEW developers, so it's a pretty good guide.
    Regards,
    John Lum
    National Instruments

  • Insane object error does not resolve upon re-load

    http://digital.ni.com/public.nsf/allkb/AFA28DCC3DE89839862566B200594E8C
    does not resolve this issue.  Even when I close the VI & re-open it, I get the following error message:
    I tried doing dozens of undo edits of the last 10 or 20 changes.  None of them work.  None of the suggested fixes work at all, either.
    Worse yet, I can tell that my code is not what is looks like. It is not running the code that is on the diagram, it is running some previous version of the code.
    Solved!
    Go to Solution.
    Attachments:
    insane object error.PNG ‏12 KB

    Hi Greg,
    Thanks for your reply.  It sounds like you've been on both ends of a serious error/crash resulting in code loss before.
    As Murphy's Law would have it, it happened right before quitting time.
    I decided to stick it out & make it a late night while I remembered most of my changes.
    I quit & restarted LabVIEW, pulled the VI from a backup done the day before, opened up the backup version of the VI, opened up the bad code, and tried pasting changes in.  However, I soon got oodles of "insane object" errors, and gave up on this route.
    I quit & restarted LV, opened up the backed up VI, opened the bad new VI on a 2nd monitor (after configuring the display etc.), and manually re-drew (i.e., "re-wrote") all my code just by inspection.
    This worked. (To play it safe, I also forced a system backup before going home, and saved lots of revs. along the way during my edits.)
    I rarely have experienced "insane object" errors in my 10+ years of LabVIEW programming.  Therefore, I have used little of other languages the past 10 years, and have developed so much re-usable code that I know well, I don't want to move away from it.  It is quite unsettling / scary when it happens, especially on a large program.  It makes me consider going back to text-based programming, where at least there's some inspection of all but the most messed up files (vim/binary mode, for example).
    Anyway, I am on my way now, but will be even more diligent about "Save As" to save interim versions during long code writing sessions.
    Also, I ran chkdsk per Apps Engr suggestion on a ticket I did later open after doing this post.
    Thanks, Matt

  • Insane object error(The string control not getting any values)

    In LabVIEW 8.2 i am using the string control to get the text from the users, and initially there was no problem at the time of development it works perfectly, after building the installer,
    these string controls are not getting any string input, it seems like a disabled one, but actually it was not disabled, when we try to click over that through the mouse,
     that text inputting cursor was not blinking over there,I screen looks as below, some error messages are thrown from the LabVIEW like insane object error, even
    now there was the same problem in the source code itself, what to do rectify this. Only this part generates error all other remaining screen panels are working perfectly.

    This kind of problem can be a pain to locate. This often occurs when the wiring to or from a control or indicator is bery long, convoluted and hidden inside of structures or behind things. So first, you need to identify which VI specifically is generating the error by individually saving VIs and subVIs until you find the one that is generating the error. Now try and remember the last time that VI saved without a problem and what edits you made since then. Places where I have had this occur was when I drag-copied a control and a couple VIs into a small structure. Sometimes the wires would seem to conect up properly, but when I tried to save the VI I got this error. The solution was to disconnect all the wires associated with the VIs I had copied and rewire them.
    Also, can you post the VI that is doing it? Shouldn't need the subVIs for this...
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • Insane Object errors

    I'm suddenly getting a lot of insane object errors on my program, I've tried everything listed in the Knowledgebase topic. They're only wire and sgnl graphical errors, but they aren't resolving themselves. When I change constants in the program, more insane objects pop up.
    It's a little bit frightening, please help.
    -Capuchin

    Hi Capuchin,
    As you probably are aware from reading through that KB, insane objects mean your VI has become corrupt and you may need to rewrite your code.
    I have some debugging tools I can use to try and debug this for you. Could you post your code please?
    I also have the email you sent to UKSupport so I can contact you directly by email if you would prefer.
    Kind regards,
    Sarah
    Applications Engineer | National Instruments | UK & Ireland

  • Insane Object error while saving: Can i identify case from error message?

    Hi,
    I get the following message "Insane Object at BDHP+36C8c in "Data Logger.vi"{graphics}(0x80):Wire Segment (WIRE). I have seen errors like this in the past. It usually happens when the wire gets coiled like a snake or gets behind a place that cannot be viewed etc. The last time i had the problem, i had to delete the wire and rewire to have the problem solved. Is there any way for me to identify the case that has this wiring problem from the error description? I get this annoying dialog everytime i save my vi. Thanks for your time in advace.
    Anand.

    The message means there is a problem with an object on the block diagram (the BD of BDHP). Fixes include copying the diagram to a new VI, and randomly deleting objects and replacing them. You might also try pressing control-shift-run arrow on the VI to perform a binary recompile of the VI. It is a long shot but it is quick and easy do do. Ususally you will not see anything happen but occasionally LabVIEW can highlight the error or even correct it.

  • I can't fix my insane object error!

    Hi all,
    I'm getting the following error messages when I try to save my VI after running it:
    Insane object at FPHP+208BC in "backup.vi":{sub}(0x10): Scale (DDO)
    " " FPHP+20634 " " Waveform Chart (DDO)
    " " FPHP+20E78 " " Scale (DDO)
    " " FPHP+20CB0 " " Waveform Chart (DDO)
    I read all of the info on insane objects available on the web site, and followed the instructions to fix the problem when it first appeared last week. I deleted and recreated the last charts and scales that I made, and eventually I recreated every chart and scale. This seemed to fix the problem, as I had no more error messages...until this morning.
    I'd like to avoid having to recreate everything all over
    again if possible. It's probably best that I send the VI to someone to take a look at and try to fix. We're using an opto22 interface for our readings, if that helps at all. Hopefully someone can help me fix this problem....
    Thanks,
    Andrew Poyton
    McMaster University
    Hamilton, Ont.

    Andrew,
    I was having a very similar error this morning. It turns out that the source of my problem was the range on the y-axis on one of my waveform charts was messed up. I had it set to autoscale and had been running the program and it plotted some really huge numbers because of a calculation error in one of my formulas. In any case, it seemed to run fine despite plotting bogus information, but when I went in to make changes and then tried to save I received the error messages similar to your situation and could not save. I fixed it as follows: I simply changed the values on the upper and lower end of the y-axis to something reasonable like +10 and -10. Then I tried to save and it worked just fine.
    So you might take a good look at your waveform plots and check
    the values on all of the ranges. I hope that helps you.
    tony

  • How do I fix the "shockwave flash" error, causing firefox to lock up, slow, or crash?

    continous errors about "shockwave flash", "script has stopped working" etc, causing numerous slowdowns, lock-ups, and crashes. have tried several fixes, but none have worked.....please advise

    Is it a permissions problem? Here's another way.
    (1) In a My Computer or Windows Explorer window, open this folder:
    C:\Windows\SysWOW64\Macromed\Flash
    If that folder does not exist, then you are using 32-bit Windows, and you can open the following folder instead:
    C:\Windows\System32\Macromed\Flash
    ''(Note: This folder exists on both 32-bit and 64-bit Windows, but on 64-bit Windows Firefox uses the Flash player in the SysWOW64 folder instead.)''
    (2) Check for a file named mms.cfg:
    (A) ''If mms.cfg exists,'' drag it to your '''Documents folder''' where you can edit it without being bothered about administrator privileges
    (B) ''If mms.cfg does not exist,'' open your '''Documents folder''', right-click > New > Text File and name the new file mms.cfg
    (3) Open mms.cfg from Documents into a text editor such as Notepad. Add this on its own line (I put it last):
    ProtectedMode=0
    Save the file and close Notepad.
    (4) Hold down the Ctrl key and drag the mms.cfg file back to the Flash folder to make a copy there, keeping the original in Documents
    This change should take effect the next time you restart Firefox.
    Hopefully that works around the permission issue.

  • 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?

  • 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

  • Insane Object CIN

    Using MS Visual C 6.0 and Labview 5.01f I'm trying to
    write a little C program for a CIN with a 1d-array in
    it.
    I've had a look for examples but I either found none with 1d-arrays or the examples were not complete and
    wouldn't work or even compile.
    So I took a sample of code by (labview's?) A. Rafiq and
    tried to complete it (Source attached).
    Code will compile, if I try to write into the array the
    vi will crash. If I don't I get an array of set length
    (i.e. 100) but trying to save my vi with the fresh
    loaded CIN will get me an "insane object" error
    Where did I go wrong?
    Please, if anyone should bother to answer: Could You
    provide me with both code examples for READING and
    WRITING into arrays within CINS?
    The problem OF C
    OURSE not being a labview but rather a
    C-problem ... I know, I know ... (it's the handlers and
    the pointers that are scaring me ... off ).
    Christoph Klein
    Attachments:
    ARafiq.c ‏1 KB

    You're better off using NumericArrayResize - let LabVIEW handle the details - it would have caught your mistake.
    Your example sizes the array large enough for 100 integers (404 bytes) and sets the dimSize to 100. But the prototype says that LabVIEW is expecting float64s. You told it there were 100 in the array, but the memory (804 bytes) wasn't there.
    Steve Bird
    Culverson Software - Elegant software that is a pleasure to use.
    Culverson.com
    Blog for (mostly LabVIEW) programmers: Tips And Tricks

  • Insane objects - can't fix by copying to new VI

    I'm using LV 8 and Windows XP.
    I have a VI that has been working and saving fine since I moved it to LV 8. The other day I added a few things and tried to save it. I keep getting insane object errors when I save it. It eventually saves and lets me use it, but I need to fix this. I tried the usual fix of copying the BD to a new VI, but that didn't help. I tried backing out the changes I remember making, but that didn't work either. I've enclosed a doc file that has a couple of the errors I'm getting. What can I try next?
    George
    Attachments:
    Insane.doc ‏30 KB

    Looking at the errors, you seem to have either one or two wires that are insane.  You can either delete all the wires (I would advise doing this one at a time) and reconnecting them, or you could post the VI and I could take a closer look with some tools that I have.  I would just post how to use the tools but I have been asked not to.  Previous posts of mine may still exist that show how to fix insane objects.  Try searching the devzone for replys by me to postings with the key words insane and BDHP.
    Hope that this helps,
    Bob Young
    Bob Young - Test Engineer - Lapsed Certified LabVIEW Developer
    DISTek Integration, Inc. - NI Alliance Member
    mailto:[email protected]

Maybe you are looking for