LabVIEW 8.6 fpsane.cpp 434

I had an internal error when I started working on updating a medium sized application (roughly 500 vi) from Labview 8.5.1 to LabVIEW 8.6. I am trying to use the classes and objects to reorganize my application to get a eaiser maintained solution. I had about 8 classes with controls that were strict type def'd before. I allowed the strict type defs to carry forward into defining the class object. I'm a rank beginner with the OOB stuff so I'm not sure if I broke something by doing something crazy or unnecessary.
 Here is the error printout, which I did allow the app to send it in to NI. But I haven't actually asked for help on it yet. I'm not sure that it's a killer bug.
#Date: Thu, Feb 05, 2009 2:53:35 PM
#OSName: Windows NT
#OSVers: 5.1
#AppName: LabVIEW
#Version: 8.6
#AppKind: FDS
#AppModDate: 06/26/2008 01:25 GMT
Insane object at BDHP+C77BB9C, UID 1089, in "NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi": {flags } (0x1000): Call Library Function Node (NODE)
c:\builds\penguin\labview\branches\Saturn\dev\source\panel\fpsane.cpp(434) : DWarn: Insanities(0x00001000) exist in ReportInsanities, 'NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi'
$Id: //labview/branches/Saturn/dev/source/panel/fpsane.cpp#10 $
0x00F3566A - LabVIEW <unknown> + 0
0x00F35E28 - LabVIEW <unknown> + 0
0x005AA7BA - LabVIEW <unknown> + 0
0x005ABC4A - LabVIEW <unknown> + 0
0x005AB190 - LabVIEW <unknown> + 0
0x005AB4F5 - LabVIEW <unknown> + 0
0x005AB7D8 - LabVIEW <unknown> + 0
0x006AA3A3 - LabVIEW <unknown> + 0
0x006AA9D5 - LabVIEW <unknown> + 0
0x006AAD7B - LabVIEW <unknown> + 0
0x006AAD31 - LabVIEW <unknown> + 0
0x006AAFEA - LabVIEW <unknown> + 0
0x006AB4AA - LabVIEW <unknown> + 0
0x011CE3BA - LabVIEW <unknown> + 0
0x01225F28 - LabVIEW <unknown> + 0
0x0122D155 - LabVIEW <unknown> + 0
0x01228903 - LabVIEW <unknown> + 0
0x00B0A055 - LabVIEW <unknown> + 0
0x00AD4792 - LabVIEW <unknown> + 0
0x116F804C - <unknown> <unknown> + 0
0x09C5CB60 - <unknown> <unknown> + 0
0x00ADC260 - LabVIEW <unknown> + 0
0x0008D8EC - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
#** sanity checking heap: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
#** sanity checking: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
#** compile: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
*** End Dump ***
Insane object at BDHP+C77BB9C, UID 1089, in "NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi": {flags } (0x1000): Call Library Function Node (NODE)
c:\builds\penguin\labview\branches\Saturn\dev\source\panel\fpsane.cpp(434) : DWarn: Insanities(0x00001000) exist in ReportInsanities, 'NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi'
$Id: //labview/branches/Saturn/dev/source/panel/fpsane.cpp#10 $
0x00F3566A - LabVIEW <unknown> + 0
0x00F35E28 - LabVIEW <unknown> + 0
0x005AA7BA - LabVIEW <unknown> + 0
0x005ABD95 - LabVIEW <unknown> + 0
0x005AB190 - LabVIEW <unknown> + 0
0x005AB4F5 - LabVIEW <unknown> + 0
0x005AB7D8 - LabVIEW <unknown> + 0
0x006AA3A3 - LabVIEW <unknown> + 0
0x006AA9D5 - LabVIEW <unknown> + 0
0x006AAD7B - LabVIEW <unknown> + 0
0x006AAD31 - LabVIEW <unknown> + 0
0x006AAFEA - LabVIEW <unknown> + 0
0x006AB4AA - LabVIEW <unknown> + 0
0x011CE3BA - LabVIEW <unknown> + 0
0x01225F28 - LabVIEW <unknown> + 0
0x0122D155 - LabVIEW <unknown> + 0
0x01228903 - LabVIEW <unknown> + 0
0x00B0A055 - LabVIEW <unknown> + 0
0x00AD4792 - LabVIEW <unknown> + 0
0x116F804C - <unknown> <unknown> + 0
0x09C5CB60 - <unknown> <unknown> + 0
0x00ADC260 - LabVIEW <unknown> + 0
0x0008D8EC - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
#** sanity checking heap: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
#** sanity checking: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
#** compile: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
*** End Dump ***
Insane object at BDHP+C77BB9C, UID 1089, in "NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi": {flags } (0x1000): Call Library Function Node (NODE)
c:\builds\penguin\labview\branches\Saturn\dev\source\panel\fpsane.cpp(434) : DWarn: Insanities(0x00001000) exist in ReportInsanities, 'NI_Gmath.lvlib:Matrix left divisionMM_general_direct.vi'
$Id: //labview/branches/Saturn/dev/source/panel/fpsane.cpp#10 $
0x00F3566A - LabVIEW <unknown> + 0
0x010088F2 - LabVIEW <unknown> + 0
0x0100CC3E - LabVIEW <unknown> + 0
0x0100D9E9 - LabVIEW <unknown> + 0
0x0100DF9B - LabVIEW <unknown> + 0
0x0100E4BB - LabVIEW <unknown> + 0
0x00D56559 - LabVIEW <unknown> + 0
0x013F61C1 - LabVIEW <unknown> + 0
0x00D54B61 - LabVIEW <unknown> + 0
0x006AA616 - LabVIEW <unknown> + 0
0x006AA9D5 - LabVIEW <unknown> + 0
0x006AAD7B - LabVIEW <unknown> + 0
0x006AAD31 - LabVIEW <unknown> + 0
0x006AAFEA - LabVIEW <unknown> + 0
0x006AB4AA - LabVIEW <unknown> + 0
0x011CE3BA - LabVIEW <unknown> + 0
0x01225F28 - LabVIEW <unknown> + 0
0x0122D155 - LabVIEW <unknown> + 0
0x01228903 - LabVIEW <unknown> + 0
0x00B0A055 - LabVIEW <unknown> + 0
0x00AD4792 - LabVIEW <unknown> + 0
0x116F804C - <unknown> <unknown> + 0
0x09C5CB60 - <unknown> <unknown> + 0
0x00ADC260 - LabVIEW <unknown> + 0
0x0008D8EC - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
#** sanity checking heap: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
#** Saving: "N:\ATEST\Automation\PAT_2.0\Working_Source\PAT_Ver2\Matrix left divisionMM_general_direct.vi"
*** End Dump ***

Hi,
Looks like you have an insane object error.  Check out the following: http://digital.ni.com/public.nsf/allkb/AFA28DCC3DE89839862566B200594E8C?OpenDocument
Since the errors are DWarns (warnings), you probably don't have anything to worry about unless they keep coming up.  Usually they will be fixed automatically.  If it comes up repeatedly, let us know.
Regards,
Jeremy_B
Applications Engineer
National Instruments

Similar Messages

  • Fpsane.cpp

    After changing the History chart length in waveform chart and trying to save the vi, an error message popped up and it reads as follows,
    Fatal Internal Error: "fpsane.cpp", line 397
    LabView 8.0
    Can anyone tell me what the problem is?

    I also get this error, which is totally annoying.
    I am currently working with some classes into a shared variable. After I add the variable to to routine, the LabView becomes really slow and crashes finally with the mentioned error.
    This bug seriously hampers my development progress!
    Bart
    Logfile:
    #Date: 2008 Feb 19 10:27:30 AM
    #OSName: Windows NT
    #OSVers: 5.1
    #AppName: LabVIEW
    #Version: 8.2
    #AppKind: FDS
    #AppModDate: 07/27/2006 11:08 GMT
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x0080305A - LabVIEW <unknown> + 0
    0x00D128A8 - LabVIEW <unknown> + 0
    0x00D13E4A - LabVIEW <unknown> + 0
    0x00C2AA85 - LabVIEW <unknown> + 0
    0x00F31429 - LabVIEW <unknown> + 0
    0x00F72B79 - LabVIEW <unknown> + 0
    0x0123EF6B - LabVIEW <unknown> + 0
    0x055D6CA4 - lvMax <unknown> + 0
    0x0559CF80 - lvMax <unknown> + 0
    0x748B560C - <unknown> <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    Loading Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x006C03F6 - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C06CC - LabVIEW <unknown> + 0
    0x00C38C46 - LabVIEW <unknown> + 0
    0x00C48ADE - LabVIEW <unknown> + 0
    0x00C497C6 - LabVIEW <unknown> + 0
    0x004CCB39 - LabVIEW <unknown> + 0
    0x004D7C95 - LabVIEW <unknown> + 0
    0x004DAF97 - LabVIEW <unknown> + 0
    0x004E10B1 - LabVIEW <unknown> + 0
    0x00C14A89 - LabVIEW <unknown> + 0
    0x00C14C90 - LabVIEW <unknown> + 0
    0x00C172E6 - LabVIEW <unknown> + 0
    0x008032EF - LabVIEW <unknown> + 0
    0x00D128A8 - LabVIEW <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    Loading Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x006C03F6 - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C070A - LabVIEW <unknown> + 0
    0x00B7BA47 - LabVIEW <unknown> + 0
    0x00CA8CCF - LabVIEW <unknown> + 0
    0x006C055A - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C06CC - LabVIEW <unknown> + 0
    0x00C38C46 - LabVIEW <unknown> + 0
    0x00C48ADE - LabVIEW <unknown> + 0
    0x00C497C6 - LabVIEW <unknown> + 0
    0x004CCB39 - LabVIEW <unknown> + 0
    0x004D7C95 - LabVIEW <unknown> + 0
    0x004DAF97 - LabVIEW <unknown> + 0
    0x004E10B1 - LabVIEW <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    Loading Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x006C03F6 - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C06CC - LabVIEW <unknown> + 0
    0x00C38C46 - LabVIEW <unknown> + 0
    0x00C14B7B - LabVIEW <unknown> + 0
    0x00C14C90 - LabVIEW <unknown> + 0
    0x00C172E6 - LabVIEW <unknown> + 0
    0x008032EF - LabVIEW <unknown> + 0
    0x00D128A8 - LabVIEW <unknown> + 0
    0x00D13E4A - LabVIEW <unknown> + 0
    0x00C2AA85 - LabVIEW <unknown> + 0
    0x00F31429 - LabVIEW <unknown> + 0
    0x00F72B79 - LabVIEW <unknown> + 0
    0x0123EF6B - LabVIEW <unknown> + 0
    0x055D6CA4 - lvMax <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    Loading Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x006C03F6 - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C06CC - LabVIEW <unknown> + 0
    0x00B7BA5D - LabVIEW <unknown> + 0
    0x00803579 - LabVIEW <unknown> + 0
    0x00D128A8 - LabVIEW <unknown> + 0
    0x00D13E4A - LabVIEW <unknown> + 0
    0x00C2AA85 - LabVIEW <unknown> + 0
    0x00F31429 - LabVIEW <unknown> + 0
    0x00F72B79 - LabVIEW <unknown> + 0
    0x0123EF6B - LabVIEW <unknown> + 0
    0x055D6CA4 - lvMax <unknown> + 0
    0x0559CF80 - lvMax <unknown> + 0
    0x748B560C - <unknown> <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    Loading Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    .\diagram\proptype.cpp(306) : DWarn: typeprop caused typeprop a third time! give up
    $Id: //labview/branches/Europa/dev/source/diagram/propt​ype.cpp#79 $
    0x006C03F6 - LabVIEW <unknown> + 0
    0x006C01C2 - LabVIEW <unknown> + 0
    0x006C06CC - LabVIEW <unknown> + 0
    0x00B7BA5D - LabVIEW <unknown> + 0
    0x00CAA12C - LabVIEW <unknown> + 0
    0x00CA8FA3 - LabVIEW <unknown> + 0
    0x00CA9515 - LabVIEW <unknown> + 0
    0x00CA9F42 - LabVIEW <unknown> + 0
    0x00D13F2F - LabVIEW <unknown> + 0
    0x00C2AA85 - LabVIEW <unknown> + 0
    0x00F31429 - LabVIEW <unknown> + 0
    0x00F72B79 - LabVIEW <unknown> + 0
    0x0123EF6B - LabVIEW <unknown> + 0
    0x055D6CA4 - lvMax <unknown> + 0
    0x0559CF80 - lvMax <unknown> + 0
    .\typedesc\TDOMIdRefnum.cpp(1373) : DWarn: Insane dataspace: contexts do not match for udclass type at data=0x08f820f0
    $Id: //labview/branches/Europa/dev/source/typedesc/TDOM​IdRefnum.cpp#23 $
    0x00501B06 - LabVIEW <unknown> + 0
    0x0050339B - LabVIEW <unknown> + 0
    0x0112DFDA - LabVIEW <unknown> + 0
    0x010C452B - LabVIEW <unknown> + 0
    0x010C452B - LabVIEW <unknown> + 0
    0x00C501E2 - LabVIEW <unknown> + 0
    0x0076BB5A - LabVIEW <unknown> + 0
    0x0076FCD9 - LabVIEW <unknown> + 0
    0x00C05721 - LabVIEW <unknown> + 0
    0x0076CFE5 - LabVIEW <unknown> + 0
    0x00C05721 - LabVIEW <unknown> + 0
    0x0076CD42 - LabVIEW <unknown> + 0
    0x007707DC - LabVIEW <unknown> + 0
    0x00CA9A5E - LabVIEW <unknown> + 0
    0x00CAA33B - LabVIEW <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    sanity checking heap Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    sanity checking Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    Insane object at FPHP+10C in "Main window 800x600.vi": {dso } (0x200): Panel (FPSC)
    .\panel\fpsane.cpp(392) : DAbort: Fatal insanities(0x200) exist in ReportInsanities, 'Main window 800x600.vi'
    $Id: //labview/branches/Europa/dev/source/panel/fpsane.​cpp#35 $
    0x0076CEF3 - LabVIEW <unknown> + 0
    0x007707DC - LabVIEW <unknown> + 0
    0x00CA9A5E - LabVIEW <unknown> + 0
    0x00CAA33B - LabVIEW <unknown> + 0
    0x00CA8FA3 - LabVIEW <unknown> + 0
    0x00CA9515 - LabVIEW <unknown> + 0
    0x00CA9F42 - LabVIEW <unknown> + 0
    0x00D13F2F - LabVIEW <unknown> + 0
    0x00C2AA85 - LabVIEW <unknown> + 0
    0x00F31429 - LabVIEW <unknown> + 0
    0x00F72B79 - LabVIEW <unknown> + 0
    0x0123EF6B - LabVIEW <unknown> + 0
    0x055D6CA4 - lvMax <unknown> + 0
    0x0559CF80 - lvMax <unknown> + 0
    0x748B560C - <unknown> <unknown> + 0
    *** Dumping Bread Crumb Stack ***
    sanity checking heap Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    sanity checking Z:\bart\LabVIEW\projects\CDM waveform monitor\1.05 LV8.2\Main window 800x600.vi
    *** End Dump ***
    Message Edited by Bart_NLD on 02-19-2008 03:37 AM

  • LV crashes when I try to save a VI - "fpsane.cpp line 269 error"

    Dear LV users:
    “Fpsane.cpp, line 269 error”
    I have this error when I modify the VI and try to save it. Often I run it once and save it without problem. When I modify it again and try to save it, the error appears and LV crashes.
    First I made a 6.0.2 upgrade and later I followed the “solving troubles” procedure at NI home page, like empty the TEMP directory and so on.
    Later I sent my VI to NI support and I received the confirmation that they were able to reproduce the error, but not able to isolate it. Also they wrote that “Maybe can be a problem with the charts” and “it could be a bug in LV 6.0.2 which is fixed in LV 6.1”.
    They saved my VI as a 6
    .1 version and there were no problems (any error).
    The problem is:
    “ LV 6.1 is the next release (newest version) of LV and it will be released this year (the date is not fixed). That's not an update like LV 6.0.2 but a new version of LV. It must be purchased”
    So I have a trouble here. I have some VIs that contains some parts in common. Now they are crashing too. I’m not confident anymore to make tests and modifications, since LV will crash again. What I’m doing after run my VI is exiting LV and open the VI again. Only after I can realize (and save) the modifications. This way is really a pain in a neck....
    Please, can someone tell me a good way to isolate this problem or to solve it? I really don’t want to wait LV 6.1 nether to buy it to solve this “bug”....
    Thank you in advance
    Rodolfo
    OS: Nt4 sp 6
    LV 6.0.2

    Dear LV users
    Sorry for not have included the VI.
    "test time save format.vi" is a learning program that contains some ideas to be used in another one. The error (fpsane.cpp) that appears here also was detected in LV 6. On the first time after grouping/edit some controls.
    This error occurs when you modify the VI and try to save it. Often you run it once and save it without problem. When you modify it again and try to save it, the error appears. This is the same problem that happened with 2 other VI, even with one LV original example (after grouping).
    The same error happened in another computer (also running NT4). All libraries were rebuilt during the installation of LV 6.02 and the TEMP directory is empty.
    I hope that this vi will help us.
    Thanks ag
    ain
    Rodolfo
    Attachments:
    Test_time_save_format.zip ‏92 KB

  • DAbort 0x1A7102DF in fpsane.cpp when opening a 2011 vi in a machine with 2012 vs

    DAbort 0x1A7102DF in fpsane.cpp
    Error message appears when i try to open a vi with LV2012 created in other computer with 2011 version.
    Does anyone know how to fix it?.

    Does the VI open correctly on the 2011 machine?
    Do new VIs work correctly on LV 2012? What about opening shipped examples?
    Norbert
    CEO: What exactly is stopping us from doing this?
    Expert: Geometry
    Marketing Manager: Just ignore it.

  • "fpsane.cpp" in line 269 appears when trying to save ma VI after the 1st run!

    Hi LV-users,
    this is a problem some of you may had before. But I still don't know how to solve this problem.
    LV crashes when I try to save my VI after the 1st run telling me about the fpsane.cpp-error. It also tells about "INSANE object at FPHP+3EE4 in my VI" and it says
    "{sub } (0x10)wave chart" and so on.
    I wonder if their is a mistake in a sub VI, maybe because I'm working with references for my wave charts and their histograms which have to be saved if the acquired datapoints are not within tolerance.
    I already upgrades my LV-Version to 6.02 and so on...I read about this solution in the Discussion Forum.
    I added my VI and Sub VIs using references.
    Can anybo
    dy give me some advice?
    Thanks, Kathrine
    Attachments:
    2405_D_Kurven_in_Cluster.vi ‏199 KB
    Kurven_Sichtbar.vi ‏38 KB
    3_Historie_speichern_B.vi ‏51 KB

    Insane error are not due to your programming. There are several good pages on our site that discuss solving these errors. Goto www.ni.com >> support >> advanced search (it is at the bottom--click on the words). This lauches the best way to search our site because under option 2, you can limit your search to resources of interests. Enter insane in the all the words field and search everything. One of the first hits is a knowlegbase that discusses solving this issue.
    Jeremy Braden
    National Instruments

  • Fpsane.cpp error

    Hello,
    Following an fpsane.cpp error, all open vi's crash and when they are reloaded they are temporarily reloaded in mandarin chinese. After a minute or so the language reverts back to english. Has anyone ever seen an error like this before?
    Thanks,
    Chase
    Test Engineer - Subzero Freezer

    1984 is most likely correct about the corrupt files.  The fpsane.cpp error usually indicates something has become "very corrupted" as listed in the explanation of the error:
    http://digital.ni.com/public.nsf/allkb/AFA28DCC3DE89839862566B200594E8C
    Have you located the origin of the error?
    Applications Engineer
    National Instruments

  • The last time you ran LabVIEW, an internal error or crash occurred at fpsane.cpp, line 444. WHY?

    I keep getting this error every time I open LabVIEW 10. Everything seems to be working fine whenever I'm using it but for some reason, LabVIEW would not close properly and linger in the background. I still see the icon in the task bar and I would sometimes close it with task manager in order to re-use LabVIEW. Does anybody out there know how to fix this problem?
    Attachment:
    Solved!
    Go to Solution.
    Attachments:
    lvlog2010-11-30-09-23-36.txt ‏3 KB

    Thanks Hinz,
    I believe I was able to solve this particular problem myself by using "LVdebugKeys". I was able to isolate the offending VI using the debug and it came out that an old "Write Test Data to File vi." does not work well with LV2010. I replaced this vi and it no longer gives me the error.
    Thank you for your help.
    Attachments:
    Write Test Data To File.JPG ‏3 KB

  • Message "fpsane.cpp" line 269

    I get this message when I try to save or find problems with program. After I hit the ok button 10 times it comes to failure screen and then shuts down.

    Robby,
    This error is related to what LabVIEW refers to as an 'insane object.' These errors, along with some possible solutions, are discussed in the following Knowledge Base article:
    Knowledge Base 1F398NU0: What Does an "Insane Object" Error Mean and What Should I Do?
    I recommend looking through this article and trying the various solutions listed there. Also, it appears that there was a bug in LabVIEW 6.0.x that caused these types of issues. If you are using this version of LabVIEW, you may want to consider upgrading. LabVIEW versions 6.1 and later have fixed this issue.
    JohnM

  • LabVIEW 2010 F2 - Crash - Localization issue ?

    Hi fellows !
    I am using LabVIEW 2010 F2 (French localized version) and I am facing this strange behavior. Can you confirm that this is a bug and / or this is because I am using a localized version of LabVIEW ?
    When using the Modifications:VI property node  (CTRL+SHIFT+B) and connecting its output to a case structure everything works fine (it looks like that).
    But now if I change the Modifications:VI property to Modifications:Front Panel and let the output of the property node connected to the case structure, LabVIEW crashes or the broken arrow appears.
    If I click on the broken arrow or try to save the VI (CTRL+S), I get the following error message :
    Fpsane.cpp line 442
    Thanks for your help.
    Regards,
    Da Helmut
    Attachments:
    err.PNG ‏11 KB
    test.png ‏14 KB
    test.vi ‏7 KB

    Hi,
    Thanks for the answer.
    There is another bug with LabVIEW 2010 (F4 this time).
    To reproduce it you have to create a (strict) type definition that consists of a cluster and put a constant which is linked to this typedef on the BD (just select the .ctl file in the BD) and then delete the type definition from the hard drive.
    Close the VI that has the constant in the BD.
    Re-open the VI, and in the BD, right click on the cluster constant and select "View as Icon". Now you get LabVIEW crashed. (ok it is useless doing that on a non existing typedef but this is crashing LabVIEW, so I thought this should be reported).
    Keep me informed if you have any further informations about that.
    Regards,
    Da Helmut

  • LabVIEW 2010 F2 - Plantage - Problème de localisati​on ?

    Bonjour à tous,
    Je rencontre un comportement assez bizarre de la part de LabVIEW. En effet celui ci plante lorsque je passe d'un noeud de propriétés (VI Server) à un autre.
    Pour reproduire le comportement placez un noeud de propriétés de VI Modifications:VI (CTRL+SHIFT+B). Reliez la sortie de ce noeud de propriétés à une structure condition. Jusque la tout va bien vous obtenez ce diagramme (plus ou moins ) !
    Seulement, maintenant si vous changez la propriété Modifications:VI pour Modifications:Face Avant, soit LabVIEW plante, soit il affiche la flèche brisée et si l'on clique dessus, ou tente de sauvegarder le VI, créer un extrait de VI etc...On obtient dans tout les cas l'erreur suivante :
    FPSane.cpp ligne 442
    Est-ce un bug de version localisée ou un bug pour toutes les versions de LabVIEW ? Si oui y'a t'il déja un CAR en cours ?
    On peut contourner ce plantage en créant directement le bon noeud de propriétés et en le reliant ensuite à la structure condition, mais au milieu d'un développement c'est exaspérant.
    VI de test téléchargeable ici
    Cordialement,
    Da Helmut

    Bonjour,
    Brice et moi même avons remarqué le problème. En effet, dès lors que la représentation de la valeur de sélection de condition est changée en un certain type, il apparait soit une erreur, soit les différentes conditions ne sont pas mises à jour.
    La version 2009 FR de LabVIEW accepte le type quad non signé en sélection de condition, ce qui n'est pas le cas de la version 2010 FR.
    Ceci étant, nous ne savons expliquer cette erreur et recherchons l'origine du problème (localisation, ou toute version).
    Cordialement,
    Romain P.
    National Instruments France
    #adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
    >> NIDays 2011, le mardi 8 février au CNIT de Paris La Défense

  • Labview 2011 FDS (64bit) crashes when saving a vi with MATLAB node

    After running a vi which includes a MATLAB node, the vi cannot be saved, because Labview crashes every time with error: "DAbort 0x1A7102DF in fpsane.cpp".
    Why does a MATLAB node with simple array I/O corrupt LABVIEW's sanity ???
    I have attached a minimum configuration, which gives a reliable crash. First run, then push save.
    Configuration: Windows 7 (new installation), Labview FDS (64bit), MATLAB (64bit)
     

    Amd1480 wrote:
    did anybody could solve or got a work arround this problem?
    I am getting the same error code when I use the Call Library Function to call external DLLs in my application.
    I am using the following system configuration:
    - Windows 7 32bit with SP1
    - LabVIEW PDS 2011 32bit
    Additionally to this error I am getting the following message (Ausnahme: Access violation (0xC0000005) bei EIP=0x00C0503F) (see attachments)
    Note: calling the same DLLs using previous LabVIEW versions (8.2) works fine.
    When such errors happen in an application that uses the Call Library Node, you can be almost certain that it is a problem in how the Call Library Node was configured (wrong!) or a bug in the DLL. That you happen to see this error, only means that the external code happend to overwrite memory that it was not supposed to do, and that memory happened to be some data structure that LabVIEW uses to represent some front panel element. That it didn't happen in 8.2 doesn't mean that it didn't have that error there too, only that it overwrote some different memory location, that had unluckily for you no visible consequences.
    For all other cases with no Call Library Node included, it means that the VIs front panel resource got somehow damaged (and yes this could also happen from running the VI in an application with misbehaving Call Library Node, and then saving the VI). The most easy solution is to rewrite the VI, another option is to try to force a recompile with the Ctrl button pressed and then activating the run button in the VI toolbar. Other than that there is little we normal users can do. The only people who can do more here are the LabVIEW developers who can look inside the VI and identify the damaged data structure and repair it, but that is a lot of work and time, and NI doesn't commit to doing this normally.

  • Labview 2011 Error code 3

    I am having the same Error code 3 using Labview 2011 student edition.  I tried adding connPaneRecoveryMode=True to the ini file and it did not solve the problem.  Can anyone help me to recover the vi?  It will set me back by days if I have to recreate it.  Your help will be much appreciated! 
    Attachments:
    Analyze_EMG_Data.vi ‏258 KB

    I'm glad it saved you so much work.  It is the first time I attempted to follow the procedures to fix this problem. I used LV2012 and saved it back to LV2011.  I know that when I didn't follow the procedures precisely, it crashed LabVIEW with an FPSane error.
    I mentioned the sequence structures because in general, the stacked sequence is being discouraged as a part of good LabVIEW style.  It hides code, and the sequence locals force you to have wires running in the wrong direction in one or more cases which confuses someone trying to follow the code.  If you have too much code that makes your block diagram too big, that is a time to consider consolidating code into logical functional groups that can be placed into subVI's.

  • Labview merge crashes

    We've just moved from 8.2 to 8.5, including a recompile of all our .vi's. 
    LVMerge seemed like an exciting new feature - unfortunately, it crashes on us on all but the most trivial .vis.  Only a few, specially-created (tiny, very simple) vi's do not result in a crash for us.  The crash is usually not accompanied by an error message, but occasionally a message about fpsane.cpp (line 367) comes up - this is probably a separate problem, related to an (already-noted) issue in the knowledge base about locking tabs (although I'm not sure why opening in lvmerge would result in locking a tab).
    We've tried a lot of different conditions - running straight from the GUI, the command line, subversion's context menu (identical to running from the command line).  We've tried copy/pasting just the controls into a new .vi (for all three of the merging .vis), ommitting the code.  Nothing seems to help.
    We're running Windows XP, LV 8.5, using subversion for source control.
    Anyone else having this issue?  Any workarounds?
    Regards,
    Don

    Hi Don,
    I would suggest going to www.ni.com/ask and creating an email service request.  You are welcome to post the files that are causing you problems to the forum, but an individual service request is probably the best avenue to resolve this issue. 
    Brian R.
    District Sales Manager
    Washington DC
    National Instruments

  • Why do I receive error on datasupp.cpp line 3563?

    I am running a serial communication program and often the program crashes, when I restart Labview, I receive an error message referent to the datasupp.cpp line 3563

    When LabVIEW generates a .cpp error, an internal error has occured within LabVIEW where a condition exists such that LabVIEW cannot continue execution. Generally, LabVIEW has reached a point in its internal code where it checks to see if certain conditions are true. Under normal circumstances, these conditions are indeed true, and LabVIEW is equipped to handle them. If they are not true, LabVIEW reports an internal error. LabVIEW reports the internal error and shuts down because to do otherwise would be to risk corrupting any VIs in memory.
    Unfortunately, we do not have any record of the datasaupp.cpp line 3563 ever causing an error. When LabVIEW does throw internal .cpp errors, it will store a failure log file in your My Documents/LabVIEW Data/lvfailurelo
    g directory by default. If you allow investigation of these internal errors, you can submit your error log file to National Instruments and we can see how the error message was generated.
    You can check out http://www.ni.com/failure for more information.
    Thanks again.

  • Lo labview freezes up

    Hello everyone,
    I'm having some trouble with LabVIEW freezing up as I scroll across my front panel trying to locate indicators.  I'll attach the VI and hopefully some of you can test it out for me, or let me know why this peculiar behavior is occurring.  The VI isn't even running, LabVIEW just doesn't respond when I scroll to the far left of the front panel to locate some indicators.  I'm using LabVIEW 8.2.1, and there is no trouble in terms of memory or running the program on my computer...it is more than capable of running very detailed programs.
    Thanks in advance,
    Attachments:
    prism analysis 2-11.vi ‏531 KB

    Hi Steve,
    I could load your vi in LV8.5 and found some controls/indicators to the very left of the front panel (using the navigation window , ctrl-shift-n). I moved them back the to rest of your front panel. I could save the vi in LV8.5...
    But then I couldn't save the vi back to LV8.2 - I get an error message from Labview "error in memory.cpp blabla"...
    In LV8.2 I get the same error as you - as soon as trying to scroll the front panel LV freezes...
    So I attach the LV8.5 version with moved front panel items - maybe someone else has an idea
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome
    Attachments:
    prism analysis 2-11_LV85.zip ‏280 KB

Maybe you are looking for