Error 2: Memory is full occurring at FP.Open invoke node in built application only

[BertMcMahan]

So I have a weird issue I'm trying to track down. I am running an application using the Actor Framework and am using the MGI Panel Manager framework. The error occurs reliably in a compiled executable but never in the development environment.

I have a Panel Actor (not top level) whose front panel is never opened nor used (other similar ones are opened but not this specific one). In part of its initialization, it calls an invoke node "FP.Open" on the reference to the VI's front panel. "Activate" is left unwired, and "State" is set to Hidden.

When I run things in the development environment everything works just fine, but in the built executable I get "Error 2 occurred at Invoke Node [rest of call chain]. Possible reason(s): Memory is full."

Watching my memory usage in Task Manager shows me around 100 MB of memory; nothing too big. I suppose something could be getting massive and then released super quickly, and not showing up in Task Manager, but I can't see any actual big memory usage errors.

Is there any reason this Invoke Node could be bringing up this error code, or could it be something else happening upstream and the error is only reporting at this node?

Is there something special I need to do for ACBR functions running as part of a compiled executable? The functions are launched dynamically within the Actor Framework (and another process or two) but it's not loading it from an external project or anything. The function itself is within vi.lib, installed as part of the rest of the Panel manager framework.

[RavensFan]

Is it possible that something in that framework is generating an error code they numbered "2", but it has nothing to do with memory?

Somebody may have created their own set of error codes for their own messages, and happened to have started at 1, 2, 3, ....  rather than picking numbers out of the band that NI has set aside for user defined errors (5000, or 50,000 or something like that.)  Also, most errors will have a negative sign in front of them, warnings will be positive.

Dig down through the call chain in lists and see if you can find the subVI that is generating the error.

[BertMcMahan]

I have dug through it as best as I can which led me to the invoke node. There aren't any custom error codes that I've found anywhere in the framework. The call chain in the error says that it's occurring at the Invoke Node for some reason.

[BertMcMahan · Accepted solution]

So I emailed MGI and Derek was able to help me out with a couple things- it turns out the front panel was getting stripped during my build process. Dropping a property node onto the block diagram prevented it from being removed, and now my error is gone. It wasn't an error with the toolkit specifically, just how LabVIEW handles front panels during builds- and they have a crappy error code to "tell you" what happened.

No idea why the FP.Open invoke node would respond with THAT error code, but it looks like that was the issue.

For future Googlers trying to figure this one out: FP.Open Invoke nodes require the front panel to be included in the build, and sometimes the compiler will try to remove it. If you try to use the FP.Open invoke node on a built executable front panel, you'll get Error 2: Out of memory even though it doesn't appear to actually use any memory. To fix it, add a Read property node to your block diagram of the front panel that the FP.Open node is acting upon. Read any property (I used the Caption property of one of the controls) and your issue should go away.

Big thanks to Derek at MGI for getting back to me super quickly and helping me  troubleshoot this one, I would have NEVER found it on my own.

[TeraTech]

Thanks for the tip!   This solved by problem too but after reading I was curious if there was a compiler setting to omit/include the front panel. After searching I found this old but still relevant discussion.

https://lavag.org/topic/20603-open-vi-front-panel-programmatically-without-having-to-include-thevi-i...