Unable to load VI in LV runtime engine - AGAIN AGAIN

[Sromero6tl]

Hello there. I've been bonking my head against this issue for a while. I've seen people encountering similiar issues but I haven't been able to reach a solution yet.

I am developing a sequence in Testand 2017, with VIs in Labview 2021 SP1 32-bit. All works fine in Development mode of the adapter, but after switching to runtime (which is the same version as Labview), I get these error messages for all the VIs when I analyze the sequence:

Unable to load VI <VI_name> with the LabVIEW Run-Time Engine version <LabVIEW Version>.

The message is followed by this is some cases:

The VI is broken. Please refer to the log file from TestStand for more information

Or by this in the rest of the cases:

Dependent File 'filename.lvlib' is missing.

But none of this is true, as when I open the VI it can actually run it and it's not missing any dependencies (run arrow is not broken).

I've already checked that the VIs are actually present in the directories, recompiled everything in LV2021 just in case, I have the search directories set up, etc. Basically I've checked everything suggested here:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARNSA4&l=es-ES

I am not using a packed library though, I have all my VIs in the instr.lib folder as this is how we've always done it in our company and haven't encountered this issue until now. I'm pretty convinced this is a Testand issue, not Labview, but have no idea how to proceed now.

Any help would be appreciated.

[Oli_Wachno]

First of all: generally speaking, I am surprised that TS2017 still works with LabVIEW2021!

I am pretty sure there is some kinda mix up with the search paths. Have you already seen https://forums.ni.com/t5/NI-TestStand/Wrong-search-directory-with-LV-run-time-engine-Correct-with/td...?

[Sromero6tl]

Hi Oli, thanks for your fast response.

I've looked at the thread you linked and it has been usefull to better understand how Teststand manages paths, but has not actually worked for me. I do not load VIs from Labview projects, I directly specify the VI Path in each step. I've tried using both relative and absolute paths. I could try packing everything into a packed library as suggested, but we've never needed to do it before, so I'd prefer finding another solution.

I'll give you a real example. I use this VI for initializing a power supply:

But it gives me this error message when I analyze the sequence in runtime mode. It says missing 'Error Cluster From Error Code.vi':

Said file is used here in the VI, and the VI is not broken, so it's not missing any dependencies. This 'Error Cluster From Error Code.vi' is just a VI from the VI library already installed with Labview:

Maybe this better illustrates the issue.

[Oli_Wachno]

Thanks for the tangible example, this makes things easier to undertand

Sounds pretty much like https://forums.ni.com/t5/NI-TestStand/Unable-to-find-vi-lib-VIs-when-using-the-Run-Time-Engine-in-th...

[Sromero6tl]

Thank you very much for your support, Oli.

Okay, from what I have gathered, NI and most users really emphasize using packed libraries, so I've tried that from some of my VIs and it actually looks like it solves the issue, no more VIs "broken" nor missing dependencies.

I guess I'll have to go this way, and make packed libraries for all the instruments, interfaces and such, that should solve all the issues. But it really bugs me that I cannot just call standalone VIs, since in the past I've done it many times, I don't understand what's different now.

Anyway, as I said, thanks for the support, at least I have learn some things in the process. I'll post again if I discover something new that could help other users.

[Oli_Wachno]

We are heavily using PackedLibraries, though they introduce different challenges....

I suspect the behaviour you are seeing is rooted in issues with the CodeModule hierachy.

Out of curiousity, I created a .seq file (pristine TestStand 2025 and LV2024  installation) which calls a LabVIEW Code Module which call Trim Whitespace.vi from VILIB. Maybe a little too simple...

Nevertheless -_> no loading errors when using the RTE