TestStand not finding core Labview vi's

[JohnatanBravo]

Hi all,

I have an issue with Teststand ('23) not finding core Labview ('23) functions located in "C:\Program Files\National Instruments\LabVIEW 2023\vi.lib"

For example, one of the VIs it won't find is "Application Directory.vi" located in "C:\Program Files\National Instruments\LabVIEW 2023\vi.lib\Utility\file.llb"

I have a simple VI attached as an example (uses DAQmx), if I add it to my sequence, it causes no issues:

If I then add the "Application Directory.vi" to the above VI (No errors in the VI itself, as we can see):

And reload the VI within TestStand, straight away I am greeted with this error (.txt log attached):

When reloading I can point TS to the location of "Application Directory.vi" in the Program Files, the error will go away, I can "Save All" but if I close TS and re-open it, Teststand doesn't remember this location...

When I copy my new sequence to my deployment machine, I am getting exactly same error.

I have these directories added to the Search Directories, but it makes no difference:

Needless to say, the debug steps in the error message don't help...

Any ideas? Thanks in advance.

[Oli_Wachno]

Regarding your Search Directories: 

The first entry is redundant since you are already are searching the whole vilib in the second.

It is good practice to have directories like the vilib not top-most.

Usually you put them somewhere after the TestStand and the TestStandPublic folders.

[JohnatanBravo]

Yes, I do realise that 🙂

This was just me debugging. The 2nd entry (as it is on that screenshot) was added first, then when it still wasn't working, I tried to add a more precise directory just in case...

Wasn't aware it's good practice to keep those directories a bit lower, thank you.
I removed the duplication and moved the vilib below TestStandPublic folder, but no change unfortunately.

[JohnatanBravo]

So I still don't know what the real cause of the issue is. But I was able to solve it by building a packed library with all of my VIs that Teststand didn't want to work with. Now that they are in a packed library, somehow the dependencies and references magically started to work.

[Oli_Wachno]

PPLs almost always solve issues like this. I am a big fan of PPLs though IMHO, they shouldn't be required for a seemingly simple use case like this.

There are frequent posts in this forum about issues finding code in runtime-environments.

My conclusion is, that usually projects (and their underlying structure) are rather not set up with deployment in mind. And once deployment dawns, the sceletons come dancing out of the closet.

To be fair: the LabVIEW library structure heritage (vilib etc.) also contributes to those issues.

Now we're back at PPLs: they just suck up everthing they need, that's why they work. Case closed... until you get into the nitty-gritty details 😉

So much for the philosophical part.

How about your issue; is this a solution you are willing to live with?

[JohnatanBravo]

Yes I know some things about those skeletons... 😂

I don't mind this solution honestly, I was working on adding database connectivity via a couple of VIs which I'm using in some pure Labview projects, never had an issue with those before, but Teststand just didn't like some of the core NI Labview functions... 🤷
It makes no difference to me that I had to pack those VIs, it's just an extra step if I need to make updates 🙂

Thanks!