Error 2002220 - LabVIEW EXE - CentOS 7.6 Desktop Linux, LabVIEW 2019

[RVallieu]

This is a first for me.  I am using a plug-in architecture (not my first time) in my code where instruments are launched dynamically based on connections on a port.

The port listening is working fine.  The issue comes in when the instrument VIs are called to be launched Dynamically via VI Server.

I am getting error 1003 from the Open VI Reference node since the VI appears to be broken.  I added code to the VI to open the front panel after this, and that lets me click on the broken run arrow.  The small pop-up window that shows up (not the usual error debug window in LV Development) states this:

"VI has an error of type 2002220. The full development version of LabVIEW is required to fix the errors."

It seems from research that this is from possible name collisions with vi.lib VIs that are used by the main app and the dynamic VIs.

After the first warning that I could not reference Dynamic VIs included in the EXE any longer on Linux RT (maybe the same applies to Linux) I removed the Dynamic Instr VIs from the Always Included part of the EXE build.  I put them in a separate Source Distribution build and install them in a support folder under the main application folder.

Does anyone have any insight into this error when running a LabVIEW EXE on a Linux machine? or maybe I am doing something stupid with my build.  I've not ever had this show up in a Windows EXE build or a LabVIEW RT build in the past.

[RVallieu]

Of course everything runs nicely in the Development Environment.

OK - so to troubleshoot a little and try to narrow things down I made a small VI that only increments a heartbeat in a user event structure when the 250ms timeout occurs.

I used the same Stop Event library code as all the other Dynamic VIs that is a common User Event used to stop multiple processes - trying to see what I am using in all of them that could be causing a name collision (if indeed that is the source of the errror).

Dynamically loading this VI that was included in the Source Distribution folder as Always Include worked perfectly.  It was found VI Reference opened, front panel control value set, VI Run, VI ref released.  It is happily counting away.

I will add another set of VIs from the central library that the other dynamic VI utilize and see if I can get the VI to break when loaded dynamically.  This is all that I can think of that might be causing the issue...but each VI is in its own library, and the library names should be preventing name collisions.  We'll see what I find.

[RVallieu]

Adding in components of Libraries I wrote - adding some functions from one of the libraries that multiple VIs share caused the error.

No problem in Dev environment using these VIs.  All the VIs in the library are set to Reentrant, so there shouldn't be any issue with multiple VIs calling the subVIs from the library.

Interesting conundrum. 

They are used by statically linked VIs in the EXE, as well as the Dynamically linked VIs.

I will tell the Source Distribution to ALWAYS EXCLUDE that library and see if that helps.

[RVallieu]

Hmm that didn't help.  The statically linked VIs still work properly with the subVIs from that library working perfectly.

I hope the presence of a Malleable VI in the library isn't the issue.  I guess I will test that theory.

[RVallieu]

Well shoot.  It was the presence of the malleable read VI in the dynamically called VI that is the issue.

Interesting!  But not cool.  Hmm.

I guess I will research issues with Malleable VIs in EXEs....

[RVallieu]

Not found explicitly for LV 2019 64-bit on Linux, but found the following:

 

EXE containing Malleable VIs can only run when Enable Debugging and Disconnect Unused Inline SubVIs are selected

Codebases with many classes and Malleable VIs can have problems when building EXEs. In some cases, the EXE process starts but the code never runs. If you build with Enable Debugging selected, the EXE will have a broken run arrow and refers to a broken Malleable VI.

Workaround:

Build with Enable Debugging and Disconnect unused inline SubVIs selected.

I will try this - barring that I will just remove the Malleable VI from the Dynamic VIs.  Not fun, but workable solution.

[RVallieu]

As I suspected - that did not work.

Not really sure of the underlying issue with a reentrant Malleable in a class being called in a Dynamic VI...it's not compiling at run-time, but I suspect something with the auto-adapting part of the compiler is not working properly.  Just guessing at this point.

At least I have a solution, replace with the non-malleable version...  😞

[TiTou]

I use quite a few home made malleable VIs in my apps, we compile - without debug or extra exclusions - on Linux Desktop (Ubuntu 20 and OpenSuse Leap 15.x) with LabVIEW 2020
Not trying to nag... but maybe at some point upgrading labVIEW will be an option for you.

[RVallieu]

At some point that will happen.

[RVallieu]

Are you then running the main VI in the Embedded Runtime and having the main VI calling a Dynamic VI with those same malleable VIs on its BD as are found in the Main VI?

That seems to be where the issue is stemming from.