LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build error: LabVIEW: (Hex 0x3EC) The VI is not in memory.

Solved!
Go to solution

I'm getting this error when building. The application runs without any issue in the development environment, and as can be seen in the image below, the VI in question is clearly in memory. My guess is this has to do with the VIM that the VI in question is calling. The previous build attempt failed on the same error for a different VI that also calls this VIM. I've now replaced the VIM with two VIs and trying build again. Any other suggestions?

JohnG3k_0-1691596270938.png

 

0 Kudos
Message 1 of 6
(1,229 Views)

Removing the VIM fixed that issue, but now fails for the same reason on another VI, also that references a VIM. Trying a mass compile at the moment, but looks like I may need to resort to getting rid of all (or at least more) of my VIM.

0 Kudos
Message 2 of 6
(1,205 Views)
Solution
Accepted by topic author JohnG3k

While I can't address your specific issue, I can tell you that in my own personal experience VIMs work less well the more nesting they contain.  If you have any VIMs inside of your VIM, see if you can reduce the nesting. 

 

If there's a VIM in a VIM, consider right-clicking the inner VIM and choosing the "Replace with SubVI contents" option.  This gives you the same code with the drawback that you don't get any updates to the inner VIM if it has code that might get updated separately, but many nested VIMs are in my experience the "Assert" VIMs or other very simple ones that shouldn't matter if they get disconnected from the source VIM permanently (things like "Stall data flow", for instance).

 

Also, weirdly enough it seems that sometimes a "Mass compile" or other recompile won't fix a broken VIM, or VI containing a VIM, but deleting the wires leading to the VIM and reconnecting them does.  I suspect doing so forces it to re-run the type propagation code again from the beginning, which sometimes it seems doesn't work like it should if the wire passing through it gets an updated type (via type definition update or class private data update).

Message 3 of 6
(1,195 Views)

I might approach this as a Ludicrous debugging problem

 

Thankfully,  there are Ludicrous Ways to Fix Broken LabVIEW Code.


"Should be" isn't "Is" -Jay
Message 4 of 6
(1,179 Views)

Thanks for the info Kyle97330... I was thinking that the nesting of VIM may have been the issue since it was the top level VIM that were identified by the build as the cause of the failure. I just didn't want to commit to replacing them right away, but after your suggestion I canceled the mass compile, and went back to the strategy of just getting rid of VIM as they broke the build. It was always the top level VIM that was identified as the cause of the build failure and after a couple level were removed the build was successful.

 

My code up till recently only had a few malleable VIs and only one level. With the latest rev a needed to implement a change that was easily done by turning a bunch of VI's into malleable VIs. I think I ended up with 4 or 5 levels of nested VIM in some places. Now down to a maximum of 3 with the successful build.

0 Kudos
Message 5 of 6
(1,127 Views)

Thanks for the link, Night Of NI. I'm only ten minutes in, but its awesome so far. I have avoided PPLs like the plague for over 10 year now after a really bad experience with them. Look like I'm going to need to add Xnodes and VIM to that list as well. I've still got a bunch of VIMs in this project that I will leave for now since it is not broken anymore, but won't be adding any more.

 

I couldn't agree more with his comment about fixing all the bug in the IDE / build process as what I would vote for as the number one new feature. I have had this thought in my head forever... as nice as they can be, we don't need any more features. We just need a stable and reliable IDE! One of the bigger reasons why most programmers don't take LabVIEW seriously 😞

0 Kudos
Message 6 of 6
(1,118 Views)