LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"there is not enough memory to load this vi"

I have a rather large Labview build application (LV 2013). Sometimes it happens that immediatly after application start the application crashes showing the following error and afterwards a non-conclusive crashlog.

"Sometimes" means that it crashes around every 10th time, sometimes everytime. If it didn't crash at startup it won't crash during runtime anymore.

 

 Capture.PNG

 

One problem is that the number of crashes depends on the computer (always Win 7 64bit ) the application is running on. On some computers it happens very rarely on the others every 2nd time.

The good thing is I already know the component where it comes from, which is the ftdi 2DXX library I'm calling. The bad thing is I don't know how to fix it. It looks to me like a memory corruption, but I I took every precaution regarding dll loading and data handling in labview.

Once I thought I fixed it by forcing recompile of all vi's of the project. It disappeared on the computer I was checking, but later appeared on another computer. Last time I thought I fixed it when I switch the dll calls to "run in any thread". It disppeared on the computer I was checking the problem on but now showed up on a different computer.

I'm running out of ideas. I already asked Labview support for help a while ago but they couldn't help me as well.  

 

0 Kudos
Message 1 of 13
(4,983 Views)

Hi,

 

LabView load error code 23 appears if your VI may have become corrupted.

In this case, you should try to rewrite your VIs in a new project an then build an application. Have you also tried replacing the library file with a new one?

 

Best regards,

 

Thomas

0 Kudos
Message 2 of 13
(4,871 Views)

You say that you know the issue is connected to a specific library. What kind of library is this? DLL?

Do you have access to the code of this library, meaning: can you debug in the code?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 13
(4,857 Views)

The question is which vi got corrupted. I am not calling the TwoButton vi. At least not explicitely. Up to now I thought that maybe the twobutton vi is an vi Labview tries to call because of memory corruption but then can't call it anymore because of the memory corruption. If that makes sense.

In case the vi is corrupted where the dll is called, would it be enough to copy/paste the code into a new vi or do I have to explicitely rewrite the code?

 

The library is the well know ftdi2dxx.dll from ftdi which is probably used thousands of times already with. I also exchanged the dll already and made sure that there is only this one dll in the system which can be called.

Unfortunately I don't have access to the source code. would be nice though.

 

I also just made again sure I obey every single step of http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672. 

 

 

0 Kudos
Message 4 of 13
(4,747 Views)

OK why are you using the dll and not the VCP driver API?  Do you also have the VCP driver running?  What is the LabVIEW bitness?


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 13
(4,739 Views)

I wasn't aware there is a vcp driver api. I thought the vcp driver just sets up a virtual com port in windows? I can't use a virtual com port because the device doesn't have a serial protocol running.

However, the VCP driver is installed and yes, it is running for other devices at the same time but not for the one the dll is operating on. Labview is 32 bit.

0 Kudos
Message 6 of 13
(4,720 Views)

is there any solution?

 

I got also this error message. I restart Labview, made a backup of the file named in the error message, create a new VI und copied the content into this new one... I tried several things mentioned here and in the internet. The size of the vi is 1,1 MB, Labview 2014.

 

Strange is: I never open the mentioned VI in the error message, I have never changed or used it.

 

I extened a .ctl, there is an Enum and I added some items to this Enum. When I choose in the running Main.vi one of my added items, go to next, then a window appears and I want to cancel this window (there is a separate cancel button, not the x), then Labview is crashing, the attached error message is appearing. When I choose an item which exists before, everything is working fine. Any ideas what I can try?

0 Kudos
Message 7 of 13
(4,499 Views)

Hi Susanne,

 

Any ideas what I can try?

Get a backup of all your VIs and start over again…

 

The size of the vi is 1,1 MB, Labview 2014.

This is rather big. Any intentions to modularize your code into smaller (and more managable) subVIs?

 

I never open the mentioned VI in the error message, I have never changed or used it. … I extened a .ctl, there is an Enum and I added some items to this Enum.

But you changed this Enum CTL file (probably a type definition). And changing a type definition used in your VI forces a recompile of your VI - even when you don't touched the VI itself! So you (probably) DID changes to your VI!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 13
(4,491 Views)

I did a backup now of the whole project but when I add more items to the Enum the problem occurs again. So you are right, it could be the size. I attached the VI mentioned in the error message. Don't have a clue to minimize the VI because the client needs every information in this VI. So, I need - highly probably - a consultant for this.... ggrrrr

 

I don't understand why new items don't work and items which exist before are working. Is Labview working like "I don't like new items" or what logic is that?

 

PS: I dont' work with the attached VI and it's not using in the program from the client. It seems that it is still used from sth else.

0 Kudos
Message 9 of 13
(4,476 Views)

Hi Susanne,

 

Don't have a clue to minimize the VI because the client needs every information in this VI.

Needing "information" in a VI doesn't mean you cannot create "modules" from it's tasks…

 

- Put UI handling in a separate loop/VI…

- Put measurement handling in separate loops/VIs…

- Put data storage in separate loops/VIs…

 

Is Labview working like "I don't like new items" or what logic is that?

I explained the logic before: you changed a typedef, which in turn forces recompilation of other code. And due to size (or whatever) that compilation fails…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 10 of 13
(4,466 Views)