TestStand 2021 project runs in developer mode, all VIs fail to load using run-time engine

[DLMC]

Specifics

Windows 11 enterprise

Labview 2022

TestStand 2021

Customized Sequential model used.

Project has been mass compiled.

Code ported from NI2013 originals.

I have a project that I ported from NI2013 to LV2022/TS2021 (what the operation uses)

The project runs fine in developer mode, using Execute->Test UUTs.

When I switch the TestStand LabVIEW adapter to the run-time engine, every vi reports it is unable to be loaded.  When I open the VI in LabVIEW it works fine.

Looking at the TestStand logs I see SeqEdit_BrokenVILogs with entries like this:

mode: "VI_BROKEN";
callSite: "CheckVIRefsForMissingDependencies";
timestamp: "2025-06-24T10:50:18.970033";
vi: { name: "FTPFileTransfer.vi"; path: "D:\Projects\Test\LabVIEW Modules\FW\FTPFileTransfer.vi";}
missingRefees: [ { refType: "VICC"; refIdent: { name: "NI_FTP.lvlib:FTP Session.ctl"; path: "<vilib>:\FTP\ftp0.llb\FTP Session.ctl";}; },
{ refType: "VICC"; refIdent: { name: "NI_FTP.lvlib:FTP Type.ctl"; path: "<vilib>:\FTP\ftp0.llb\FTP Type.ctl";}; },
{ refType: "VIVI"; refIdent: { name: "NI_FTP.lvlib:FTP [CWD].vi"; path: "<vilib>:\FTP\ftp1.llb\FTP [CWD].vi";}; },
{ refType: "VIVI"; refIdent: { name: "NI_FTP.lvlib:FTP [TYPE].vi"; path: "<vilib>:\FTP\ftp1.llb\FTP [TYPE].vi";}; },
{ refType: "VIVI"; refIdent: { name: "NI_FTP.lvlib:FTP [PASV].vi"; path: "<vilib>:\FTP\ftp1.llb\FTP [PASV].vi";}; },
{ refType: "VIVI"; refIdent: { name: "NI_FTP.lvlib:FTP [RETR].vi"; path: "<vilib>:\FTP\ftp1.llb\FTP [RETR].vi";}; }];
callchain: [ { name: "GetFilesFromFTPSite.vi"; path: "D:\Projects\Test\LabVIEW Modules\FW\GetFilesFromFTPSite.vi";}];
callers: [ { name: "GetFilesFromFTPSite.vi"; path: "D:\Projects\Test\LabVIEW Modules\FW\GetFilesFromFTPSite.vi";}];
dependencyIdent: { name: "NI_FTP.lvlib:FTP Session.ctl"; path: "<vilib>:\FTP\ftp0.llb\FTP Session.ctl";};

It looks like something basic is broken with respect to core LV library calls.  But why?  I have only one LabVIEW install, LV2022 and one TestStand install, TS2021.  All the VIs originated as NI2013, like I said though, the project has been mass compiled and runs fine in developer mode.  What is different with the run-time engine?  The mass compile should have made all the VIs LV2022 so they should match the run-time engine.

This is what my Adapter Configuration is

Clearly I have done something wrong.  What?

All input welcome, I have done a lot of the learning paths, but I don't know where to start with this one.

be well,

DLC

[Oli_Wachno]

With the adapter set to runtime, some ctls are not found...

What do your SearchPaths in TestStand look like?

For the sake of curiosity: what happens if you activate "automatically build packaged library...." on the configuration settings? Apart from taking it much longer to start 😉

[DLMC]

---

@Oli_Wachno wrote:

With the adapter set to runtime, some ctls are not found...

What do your SearchPaths in TestStand look like?

For the sake of curiosity: what happens if you activate "automatically build packaged library...." on the configuration settings? Apart from taking it much longer to start 😉

---

My search paths are chaos.  I have two projects I am working on, they share some similar calls but are distinct in nature and of course, their file locations. The major problem is the Station Globals, Two different projects use that ....../cfg folder and they interfere with each other.  I can't help but wonder, how on Earth can you keep two different projects separated when they both use Station Globals?  Who ever thought that was a good idea?

Another question I have, does a LabVIEW professional Developer license include a run-time engine?  Or do I have to license that separately?  Maybe I don't even have one.  I think it is safe to say that the NI license system is kind of confusing.

be well,

DLC

[DLMC]

---

@Oli_Wachno wrote:

For the sake of curiosity: what happens if you activate "automatically build packaged library...." on the configuration settings? Apart from taking it much longer to start 😉

---

This had no affect on what happens. Same error, on the first VI encountered.  Interesting thought though, I will keep this in mind as I work through this issue.

be well,

DLC

[DLMC]

Here is more information, and behavior I don't understand.  This is one example, but the <vilib> directory seems to be core to the errors I am seeing (pardon the pun).

As noted here (edited for clarity) one of my VIs uses the vi.lib Clear Errors.vi, and can't find it.

mode: "VI_BROKEN";
callSite: "CheckVIRefsForMissingDependencies";
timestamp: "2025-06-25T12:32:40.218167";
vi: { name: "HEPIM_USB.vi"; path: "C:\Project\LabVIEW Modules\CUSTOM_USB.vi";}
missingRefees: [ { refType: "VIVI"; refIdent: { name: "Clear Errors.vi"; path: "<vilib>:\Utility\error.llb\Clear Errors.vi";}; }
];
dependencyIdent: { name: "Clear Errors.vi"; path: "<vilib>:\Utility\error.llb\Clear Errors.vi";};

I added the D:\Program Files (x86)\National Instruments\LabVIEW2022\vi.lib to the Search Directories list and have checked the Search Subdirectories.  The error doesn't change, the problem persists.

My OI exe build calls the TestStand sequences to run, I'd like to see this work before creating the deployment build, but this is just not working. Clearly I am missing some key item.  If someone remembers a "gotcha" moment, I am keenly interested in knowing it!  

In the mean time I will go back to the phone-book-of-how-to-do-something learning paths to see if I can find it.  I am deathly worried that the originator of this code did something that is incompatible with a run-time deployment.

Any help or ideas will be appreciated.

be well,

DLC

[DLMC]

---

@Oli_Wachno wrote:

With the adapter set to runtime, some ctls are not found...

What do your SearchPaths in TestStand look like?

For the sake of curiosity: what happens if you activate "automatically build packaged library...." on the configuration settings? Apart from taking it much longer to start 😉

---

Something did change.  When I build the OI project (with the development environment) When I run it, its slow to start and I now get this error and the program hangs.  I didn't turn debug on.

 and I can't run the Test UUTs now, it can't find <vilib> VIs.  Somewhere I broke everything.  Time to backtrack.  I guess you can see things are consistent between Test UUTs and the built development OI exe's, neither work now. 😕

be well,

DLC

[Oli_Wachno]

Thanks for the feedback, this is exactly what I wanted to know!

What this option does is to put all of your LabVIEW Code into a (pre-compiled) PPL (compilation = takes longer), PPLs are executed using the Run-Time Engine.

Though I would've expected to see a different error here...

Generally speaking, messy search paths are a constant cause of fun. I am not sure, if ths is the root cause here, yet taking the effort to clean up or at least analyze could save your sanity in the future 😉

is VI.LIB contained in your search path?

[DLMC]

---

@Oli_Wachno wrote:

Thanks for the feedback, this is exactly what I wanted to know!

What this option does is to put all of your LabVIEW Code into a (pre-compiled) PPL (compilation = takes longer), PPLs are executed using the Run-Time Engine.

Though I would've expected to see a different error here...

Generally speaking, messy search paths are a constant cause of fun. I am not sure, if ths is the root cause here, yet taking the effort to clean up or at least analyze could save your sanity in the future 😉

is VI.LIB contained in your search path?

---

Many of those errors were caused by my accidentally checking the "enable debug" in the run time engine.  That violently did not work well.  I have recovered back to my original inoperable state. 🙂

I keep putting the vi.lib path in my search folder and TestStand keeps deleting it.  It also doesn't work, I get the same vi.lib sub-VI cannot be found.  I selected the "Search Sub directories", but still, the same error in run-time engine.

I found and de-selected directories that were related to another project, which solved cross-compile errors.

A coworker suggested to use an LLB instead of PPL because in their experience it seems more stable.  Since I don't know anything about either of them I will be doing some research.

Be well,

DLC

[DLMC]

This has kind of hit a wall, let's start over.  I was going to restart with another thread, but decided to just stay here.

Where I started.

Windows 7 Enterprise

TS 4.2, LV 2010

OI exe built that calls TestStand sequences which runs VIs in run-time engine WITHOUT using PPL or LLB libraries, just calls the raw VIs.

This worked.  I inherited this code base and am trying to migrate to 

Windows 11 Enterprise

TS 2021, LV 2022

I have migrated the sequence files and VIs and have corrected issues with missing core VIs and deprecated code.

I can build the OI exe and run from the developer mode, but VIs all seem to fail because they can't get to core vi.lib VIs.  Sometimes VIs cannot locate sub-VIs that are in the same folder.

I have gone through TestStand learning paths and read a bunch of NI docs, but am not sure why this happens.

What sort of things do I need to look for that causes these problems?

be well,

DLC