Error Message

[forestrock]

Hi guys:
I have a new problem now. When I try to run my VI. It generate the following error message:

"LabVIEW: An exception occured within the external code called by a Call Library Function Node. This might
have corrupted labVIEW's memory. Save any work to a new location and restart LabVIEW.
"VI 'test.vi' was stopped at node 0x0 of subVI 'NI_APPLPro.lvlib:Real SVD decomposition.vi"

However, when running the VI on other computers or with LabVIEW 8.2, I never encounter this error message.
I've read a few other posts regarding this kind of error messgae. Some claim that it's the "result of badly
configured or wired Call Library Nodes."
http://forums.ni.com/ni/board/message?board.id=170&message.id=223900&query.id=305602#M223900
But I never used Call Library Nodes myself and I didn't change any configuration. I've attached the VI's
with this post.
Can some one help me out? Thanks

[M_B1]

Hi Forestrock,

Thanks for posting to the discussion forums.  There are a couple of things you can try to get rid of this error.  You can try saving and renaming all the VI's that are called by test.vi and test.vi into a new location.  A second thing you can do is physically delete the Nonlinear Curve Fit.vi and replace it.  If neither of these options work you may have to reinstall your LabVIEW.  I ran your program and it ran error free on my computer.  I hope this helps out.  Have a good day!

[bostonscot]

we have exactly the same problem with labview 8.0.  The code works fine on other machines.  We tried deleting the offending library and copying the "good" library from another machine.  This didn't work either!  Anyone got a more recent solution?

[Eric_R]

Hi Gavin

What VI are you opening that provides you with this error? In your case what liberary did you replace?

[bostonscot]

Sorry, a little lacking in detail there!  The error message is exactly as reported in this thread (down to the SVD algorithm).  We were opening fit ellipse.vi (one of the example vis).  I renamed and then copied NI_APPLPro.lvlib from an alternative machine (where the example works fine).  Since then, we have also run a repair on the labview install.  We have not yet done a remove/msiblast, but thats probably our next step.

[Eric_R]

Hi Gavin

Where is this ellispe.vi found? I did not find this VI when searching our functions pallets or in the example finder?

[bostonscot]

On my machine

C:\Program Files\National Instruments\LabVIEW 8.0\examples\math\curvefit.llb\Fit ellipse.vi

[Eric_R]

Hi Gavin

I took a look into this VI and did not see any references of it calling the NI_APPLPro.lvlib. What operating system are you using? Open the ellipse VI and try running it in highlight execution, when doing this which sub VI throws the error?

[bostonscot]

we are using windows XP.

As I said, the error message says that the faulting vi is "Real SVD decomposition.vi".  This shows up in the hierarchy for "fit ellipse.vi" (and is listed there as belonging to NI_APPLPro.lvlib.  It may be that it is the polymorphic state of "Nonlinear curve fit.vi" that matters?  It is set to Lev-Mar.

If I do search for the string "NI_APPLPro.lvlib" on (fit ellipse.vi) and its sub-vis to search for that library, I don't see it either, but if I search using objects and select "VI by name" there are four VIs showing related to this library (three SVD and three matrix).  

If I run in highlight execution the failure is in "Nonlinear curve fit".

If I progressively tunnel down in each faulting vi then the thread is:

"Nonlinear curve fit LM.vi" -> "LM get new coefficients.vi" -> "Matrix left divisionMV.vi" -> "Real SVD decomposition.vi" where it appears to fault during the call to "C:\Program Files\National Instruments\LabVIEW 8.0\resource\lvanlys.dll", specifically the function SVDEx_head.  I attach a screen shot of the "configuration" for this library function.

Is it possible that lvanlys.dll is corrupt? 

[bostonscot]

Quick follow-up.  I tried renaming lvanlys.dll and copying this dll from a computer I know works (although I did not reboot in between).  No effect.  They both have the same byte count.  Oddly the one that isn't working has a date of 10/6/05 1:14am and the one that does work is 10/6/05 2:14am (I suppose that could just be some glitch with the clocks?).  They are listed as having the same version numbers.