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

Similar Messages

  • Insane Objects

    Just installed LV5.1 on a Dell running NT at work. I have a 32 DIO card,
    GPIB card and a DSP board. I keep getting the those INSANE messages (along
    with LV crashing) when I do the following:
    1) Execute LV VI(s)
    2) Stop VI(s)
    3) Make any changes
    4) SAVE
    After attempting to save new changes, even small changes like constants or
    indicator sizes, I get the INSANE OBJECT error.
    Any clues on resolving this? We have the exact same setup on a Compaq
    running WIN95 with no problems.
    -Jeff
    email = [email protected]

    > Just installed LV5.1 on a Dell running NT at work. I have a 32 DIO card,
    > GPIB card and a DSP board. I keep getting the those INSANE messages (along
    > with LV crashing) when I do the following:
    >
    > 1) Execute LV VI(s)
    > 2) Stop VI(s)
    > 3) Make any changes
    > 4) SAVE
    >
    > After attempting to save new changes, even small changes like constants or
    > indicator sizes, I get the INSANE OBJECT error.
    >
    > Any clues on resolving this? We have the exact same setup on a Compaq
    > running WIN95 with no problems.
    >
    This sort of problem shouldn't be machine specific. It probably is VI specific.
    Insane Objects are objects in a panel, or more likely a diagram that somehow
    don't make sense to the editor. The editor performs what is called a SanityCheck
    before each compile and save operation to make sure that what it is
    working on
    looks correct and isn't diagnosed as insane. If it finds something
    wrong, it reports
    the insanities. The details aren't that important to you, but they can
    help us
    to fix the VI, if it is fixable. Some insanities are automatically
    fixed when the
    dialog is put up. This usually means that LV deleted a wire segment or sometimes
    the entire wire.
    What to do?
    Open the troublesome VI and immediately recompile it. Hold down the Ctl
    key for
    PC or Option key for Mac, basically whichever modifier key would be used
    to copy
    an object. Then with the key down, click on the Run button. The VI
    won't actually
    run, but will be Sanity checked and recompiled. This will determine if
    the VI is
    insane at any point. Do this recompile immediately after loading the VI
    to see if
    it is corrupt on disk. If you aren't sure which VI might be bad, you
    can hold down
    Shift and Ctl and click on the run button. This shift tells LV to
    recompile all VIs
    in memory, and it will determine the state of all the VIs.
    If a VI is corrupt when it first loads, then the edits and running the
    VI has nothing
    to do with the problem. Either the VI was corrupted by a file system
    corruption or
    an older version of LV did less Sanity checking than the new version.
    The reason LV
    does the Sanity check during save is to make sure that corruptions
    aren't saved to disk.
    Basically if the editor has a bug where it corrupts VIs, it will be
    caught sooner
    rather than later. So, presumably the VI passed the last time it was
    saved, it is very
    likely that the VI was corrupted on disk. You should definitely run
    ScanDisk or some
    other Norton or some other utility to check and repair your disk's
    directory and cluster
    information. Once disks have corruptions, this type of corruption
    becomes common as
    files are saved into a section that is crosslinked with other files.
    Changing one file
    changes both, and things get scrambled. So definitely make sure the
    disk is good at this
    point. If you have a recent backup of the VI, you may want to check it
    and see if it is
    OK so that you can recover.
    If the VI was not corrupted when loaded, but becomes corrupted after
    performing some
    operations, go ahead and make the edit, run the VI or whatever sequence
    of operations
    that seemed to corrupt it. At various points do the Ctl-click on the
    run button
    to determine at which point it goes bad. Record the steps and send that information,
    along with the VI to NI tech support via email or snail-mail. If the VI
    becomes corrupt
    after running, then it is often due to CINs or DLLs. The most common
    reason will be that
    the CIN or DLL will write past the end of a LV string or array and
    corrupted whatever
    memory was near it. So be sure to check for that before sending it into NI.
    Greg McKaskle

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

  • 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

  • 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

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

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

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

  • 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

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

  • Erreur "insane object" dans labview

    Bonjour à tous,
    J'ai actuellement un gros probleme sur un VI qui ne veux plus se démarrer suite à plusieurs erreur "insane object".
    Je sais que mon VI posséde une erreur dans le déclaration et l'exploitation de variables globales mais l'aimerais pouvoir le relancer pour le modifier car il représente quelques semaines de travaux.
    Connaissez - vous un moyen de démarrer un VI en ignorant ces erreurs pour que je puisse le déboguer ?
    Merci de votre aide

    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.

Maybe you are looking for

  • Not getiing  spool if zprogram excutes in background which calls a submit

    Dear All, I have two programs with same selection screen , one is a z one and the other a standard one . i am calling the standard program from my z program using Submit with some restriction value in the selection screen of the standard program. Eve

  • IPod Touch wont play music or connet to iTunes!

    My ipod touch wont play music through the headphones or docking station, it only plays music through the actual iPod and it isnt found when i connect to itunes, help!

  • Web Deploy error - "This method is not supported by this class"

    I have an MVC project which I am trying to deploy to one of our internally-hosted web front end servers via a TFS build process. Our server hosts the MS Deploy service, and other solutions deploy without problems to the same box. The parameters for t

  • Replacing superdrive with a laptop drive or a 3.5" drive.

    Is it possible to take out the superdrive and somehow mount a laptop drive in it's place or a low power 3.5" drive? I see that MCE has an "optibay" for laptops who would like to replace their superdrives. I'm just wondering if it's possible to use th

  • Adobe apps not opening

    I recently transferred the data in my older MacBook Pro to my new MacBook Pro.  When I try to open the apps, I receive an error message 11 and info to notify Adobe.com/support.  What is happening?