Unable to find vi.lib VIs when using the Run Time Engine in the developer environment.

[DLMC]

Windows 11 enterprise

LavVIEW 2022

TestStand 2021

Using the development environment, not using a deployment on another computer.

Using VIs and sequences ported from NI2010 days.

I have ported VIs from a NI2010 environment, made all VI calls in TestStand relative addresses, made sub-VIs access support files as relative addressing.  Have configured the search Directories to include the LV vi.lib directory.

I can run the sequence files using the execute->test UUTs and everything runs.

I have built exe launchers for my OI when the development is chosen, and those run fine.

When I try to run the TestStand sequences using the RTE, I immediately get this error:

 mode: "VI_BROKEN";
callSite: "CheckVIRefsForMissingDependencies";
timestamp: "2025-07-18T16:12:47.200056";
vi: { name: "Generic Scan_SN_OrderNumber.vi"; path: "D:\Projects\project\LabVIEW Modules\Generic Scan_SN_OrderNumber.vi";}
callchain: [];
callers: [];
dependencyIdent: { name: "Trim Whitespace.vi"; path: "<vilib>:\Utility\error.llb\Trim Whitespace.vi";};

I have followed all the rules to create a deployable test, why can't the RTE find core labVIEW VIs?  I have read through a bunch of other issues like this one, but they never seem to get solved or the OP never says what solved it. I have the lv.lib directory in my search directory, near the top.

I have not changed much in the guts of this code other than to update to newer VIs where old ones were no longer supported or were deprecated.  This code all ran in the NI2010 LV/TS system with the RTE.  Is there some secret sauce in the newer LV/TS that I need to follow?

Needless to say, I have not tried creating deployed solutions since I can't even get it to run in the dev. environment.

This discussion was great, but even it did not solve my problem:

https://forums.ni.com/t5/NI-TestStand/Wrong-search-directory-with-LV-run-time-engine-Correct-with/td...

I note the OP did not report back whether it solved their problem.

This is so basic I have to have missed something obvious.  Can someone point it out to me?

be well,

DLC

[Oli_Wachno]

You have encountered a special offender here...

There has infact been a change with this vi, though it should be transparent.

In 2019 and before, this vi is indeed located in an llb 

I don't know when it has changed exactly, but nowadays, there's a folder called error.llb containing the VI in question.

So my guess is, that in this context, this might be the cause for the issue.

I'd recommed mass compiling and make sure, the search directories match.

[DLMC]

---

@Oli_Wachno wrote:

You have encountered a special offender here...

There has infact been a change with this vi, though it should be transparent.

In 2019 and before, this vi is indeed located in an llb 

[graphic removed]

I don't know when it has changed exactly, but nowadays, there's a folder called error.llb containing the VI in question.

[graphic removed]

So my guess is, that in this context, this might be the cause for the issue.

I'd recommed mass compiling and make sure, the search directories match.

---

Thanks for the reply.  I have Mass Compiled the project holding the VIs used by the TestStand sequences and I have Mass Compiled the entire folder which has these project files, the files for the OI and the SupportFiles folder.  I still have the same problem.  Following your discussion I find the Trim.Whitespace VI folder in in a sub folder of vi.Lib and I have set the Search Directory entry to include sub directories.  Still, no dice.

I have not turned my project into a PPA nor created a vi.Lib LLB, I just call the VIs from the TestStand project.  Which works fine when using the developer engine, but not so much with the RTE.  Whenever I restart TestStand, the path to vi.Lib is never there, I have to add it again, which does nothing, so I guess TS doesn't think it is useful.

I specifically added the error.llb folder to the Search Directory list and this same error still shows up.  

Do these two symptoms point to the potential problem?  That the RTE does not look at the Search Directories list at all?  Why is the RTE even a configurable option if it doesn't work with the IDE?  I know that in NI2010 and NI2013 the RTE worked in the IDE, and used these same VIs.

be well,

DLC

[Oli_Wachno]

Can you give some more details on how your Code Modules are organized?

Are you referencing Lvproj files in the code module settings?

[DLMC]

---

@Oli_Wachno wrote:

Can you give some more details on how your Code Modules are organized?

Are you referencing Lvproj files in the code module settings?

---

Here is the general layout

                                                        Overall Project

                            LabVIEW Modules                          TestStand Sequences

Support Files       LV sub-VI Folders      OI projects

                           Other sub-VI folders

When I say "Overall Project" that is just the best way I have to describe it.  The LabVIEW Modules folder has several .lvproj projects in it as do the LV sub-VI folders.  Nothing has been put into packed libraries, everything Mass Compiles without errors. Not all the VI folders are being used in the project, there are outdated VIs mixed into the lot, until I find and eliminate them anyway.

All the TestStand sequence called VIs are addressed using relative addressing, as you can see none of the VIs are in or under the TestStand folder.  Not sure how that works though since somewhere a direct address is needed to get to the VI folders from the TestStand folder.

The TestStand sequences call VIs individually and not via any LLB or PPL.  Somewhere in this one of the VIs needs to reference a DLL for a custom USB drive to talk to the UUT.  I have not found that yet.  The driver files are likely just installed in a Windows folder somewhere.

The more I discuss this, the more holes I see in how this is laid out.  How did this ever work with the RTE in NI2010?  Magic?

be well,

DLC

[Oli_Wachno]

---

@DLMC wrote:

---

[...]. Not all the VI folders are being used in the project, there are outdated VIs mixed into the lot, until I find and eliminate them anyway. [...]

https://forums.ni.com/t5/Community-Documents/Feature-Find-Non-Project-Files/ta-p/4347088

maybe this helps

[DLMC]

For posterity, this problem is unsolvable as it exists right now, the project was done incorrectly and needs re-factoring.  Here are my discoveries and what I am missing.

I am not creating an executable from the project, the VIs are being used in a TestStand operation.  So, LV exe creation is right out, I need a PPL to do this from TestStand.

The Operator Interface (OI to NI, GUI to the rest of the world) can be created as an exe to call a TestStand sequence.  But TestStand needs to be installed as an RTE to call VIs in a PPL to make this work, so it doesn't look like this can all be wrapped up together with the OI, TS and PPL all in one package, but the test computer needs to be configured, maybe something else can be used to package these three distinct parts together. 

So, to sum up, this is what I have discovered:

The TestStand development IDE cannot run raw VIs in your project.  It won't find dependencies.

The TestStand development RTE CAN run VIs that are properly packaged in a PPL.  So your TestStand sequences must call VIs in your PPL.

Creating a PPL will cause your raw VIs to link to other VIs in the PPL, so you won't be able to directly work on raw VIs or call them from the TestStand developer IDE.  When a PPL is set up you can only edit the VIs in the PPL IN the PPL.

If you want to tune and tweak a TestStand/LabVIEW with raw VIs you need to have a parallel LabVIEW project and run with them in developer mode.  When you are happy, copy the changed VIs to the folder with your PPL LabVIEW project and create a new PPL to run in TestStand's RTE.

Things I have do not yet understand:

How to organize support files (not VIs, ini's, Excel files, text files, etc.) so VIs in a PPL can get to them.  support files go into a Data directory in the main execution directory of a project, is this true also with a PPL?  How does a VI find a dependent file in a PPL?

How to create an install package with an OI .exe that calls a TestStand sequence file that calls VIs from a PPL.  I can figure any two of these, but not all three.

I will update this as I discover how to get these three things to work together in an "easily deployed package" if such a thing exists.

be well,

DLC