llb in window explorer

[TeddyBear24]

Hi

I'm pretty new to Teststand and Labview

My client has a Labview and Teststand 2017 source code that I cloned from git and I'm trying to make sense of it. I'm using Teststand dev v2023 and Labview dev v2024 to run the code.

I have tried launching the Teststand main sequence and the llb paths aren't found as they aren't at the root of the project. They're not visible in the git repo either.

ex:

VI Path (Teststand): Client.llb\ClientOperator.vi

but in my window explorer it will be in cloneA\ServerClient\Client.llb\ClientOperator.vi if going from the root of the project.

I understand you need to configure the Configure/Search Directories to avoid using absolute paths.

I've played around with the repo (cloneA) a little and have been able to change the absolute path to .llb before figuring out I needed to use the search directories.

Here's my problem:

I recloned my repo to start over without my changes to the paths, but the .llb aren't there. I have no idea what I did in my previous clone that magically made the llb appear in my folders to have access to the VIs inside. At the moment, the teststand sequence can't go all the way since it can't find the VIs with the given paths.

I'm not sure if I'm being clear. Basically:

Client.llb exists in

cloneA\ServerClient\

that I played around with, but not in

cloneB\ServerClient\

that I just cloned.

I do have a Client_server.lvproj with a Client\ClientOperator.vi in it in both cloneA\ServerClient\ and cloneB\ServerClient\ if that helps.

I'm trying to understand what I should do to get access to that llb in my cloneB

Thanks in advance

[Jacobson]

Is cloneB on a different branch than cloneA?

[TeddyBear24]

CloneA and cloneB are from the same git repo, (git clone https://repo cloneA, git clone https://repo cloneB) both cloned from the "main" branch, saved in the same local folder (that is not tracked with git). They're currently on "branchA" for cloneA and "main" for cloneB but that shouldn't have an impact since they're now two seperate entities.

Edit to add:

cloneA and cloneB and both the roots of the project (so two seperate projects now); they're not incorporated in a bigger project, they are the whole project themselves

[Jacobson]

---

@TeddyBear24 wrote:

They're currently on "branchA" for cloneA and "main" for cloneB but that shouldn't have an impact since they're now two seperate entities.

---

Maybe I'm not understanding the real problem but it sounds like if the llb you're looking for is only in the cloneA folder then the llb was only committed to branchA and was never pulled into the main branch which is why it doesn't exist in cloneB.

[TeddyBear24]

I probably wasn't clear in my explanation

The source code I'm working on was created a few years back and left on a git repo since. I arrived recently and was asked to bring a little mainenance to it (debugging) and since I'm the only one working on it there is no issue with someone else pushing new files to it.

That source code was on a git repository with only one branch (main) which I cloned (cloneA), created a branch (branchA) to try and understand what was going on in it without breaking anything. I didn't push anything so the remote git repo is still with the original content.

When I go back to the main branch of cloneA I can find the .llb files in the file explorer.

Then I went back to the remote git repo and cloned it again (momentarily forgot I had a clean main branch in cloneA) which is cloneB.

The thing is, I can't see the .llb files in the remote git repo when I navigate in the folders and they aren't there either in cloneB.

So I'm quite confused as to how those .llb files/folders happen to be present in one of my clones and not the other. I can launch cloneA in Teststand and the llb are found and the sequence runs (after changing the paths to reference from the root of the project so not with the Search Directories option).

I can't launch cloneB in Teststand as I get a "file not found" error when looking for a Client.llb/file.vi. When I navigate to the location in the file explorer, where there should be the Client.llb, it's not there (when it is present in cloneA in that same location but not in the remote git repo).

I don't know if this is helpful, but the VIs are managed with git lfs. So might be a cloning error? But they're not in the remote repo either so not sure how that goes.

I thought it might be a case where they're "generated" or something when the Teststand sequence or a VI is launched and that's how they end up "appearing" as .llb in my folders afterwards. Especially since I can see a corresponding folder (Client/file.vi) with the VIs that were called in the Teststand sequence when I open a Client_server.lvproj file in that same folder (but I can't put that path in Teststand since it's through a .lvproj)

basically:

1) my teststand sequence calls for Client.llb/file.vi

2)

$ ls cloneA/serverClient

Client_server.lvproj

Client.llb

3) when I open Client_server.lvproj in Labview I get a file tree with

Client/file.vi that I can open in labview

4) when I double click (in the file explorer) on Client.llb it opens a tab to file.vi

5)

$ ls cloneB/serverClient

Client_server.lvproj

(so no Client.llb)

6) when I open that Client_server.lvproj in Labview I get a file tree with

Client/file.vi that I can open in labview (same as 3)

The Teststand sequence in cloneB will say it can't find Client.llb/file.vi while I managed to change the teststand call to ServerClient/Client.llb/file.vi in cloneA

I hope that's more understandable

[JÞB]

Are you really using *.llb files?  Those have been obsolete for so many years that I only vaguely recall that there is LabVIEW.ini option to "Allow browsing into llb files."  I believe that the default value originally was FALSE because it requires some additional LabVIEW overhead that was not always needed when the option first became available.  I suspect that, since the llb format became obsolete,  no-one ever even suggested that the default should be changed to TRUE.

Look under Tools>>Options Environment for the setting. 

[rolfk]

Inside LabVIEW, it will switch from the platform file dialog to its internal file dialog whenever you select an LLB to browse into. That file dialog knows how to treat LLBs as a directory.

Under Tools->LLB Manager... is also a LabVIEW tool that can show the content of an LLB in a list box and allows to convert an LLB into a directory and vice versa.

The other option to allow the Windows File Explorer to browse into an LLB requires registration of a shell extension DLL in Windows. I used to have such a DLL for Windows 95/98/2000 and also had published it, but NI after having shown that it can be done, quickly added their own version to the LabVIEW installation around LabVIEW 7.0 or 7.1. It could be indeed enabled with a check box in the LabVIEW options, which simply registered its own special DLL in Windows. But they eventually stopped offering that option around LabVIEW 8.21 or 8.5 times or so, definitely before LabVIEW 2009, so there for sure is no 64-bit version of that DLL and that would be required for it to work in pretty much any still supported Windows version. My own solution is somewhere in an old archive, but after NI had released their own solution I lost any incentive to work on that.

[TeddyBear24 · Accepted solution]

---

@JÞB wrote:

Are you really using *.llb files?  Those have been obsolete for so many years that I only vaguely recall that there is LabVIEW.ini option to "Allow browsing into llb files."  I believe that the default value originally was FALSE because it requires some additional LabVIEW overhead that was not always needed when the option first became available.  I suspect that, since the llb format became obsolete,  no-one ever even suggested that the default should be changed to TRUE.

Look under Tools>>Options Environment for the setting. 

---

The project is definitely using llb modules. At least the developper that made the code still did in 2019 using a 2017 version of Teststand and Labview, there's about 5 or 6 in that project. Not sure when they became obsolete, Teststand llb documentation doesn't seem to mention that particularity.

So, I wasn't able to find that "allow browsing in llb files" option but I did find there is a "Build Specifications" option in the Labview project explorer.

By double clicking on the little folder beneath it you get to a Properties window.

In that window you can define which files from the project you want to automatically create that llb in the Always include window.

Then by clicking Build you end up with a Client.llb that magically pops in your folder alongside the .lvproj.

I'm guessing there's a sort of setup script somewhere in the project that does the "build clicking" automatically for all build Specifications instead of having to manually do them one by one which is probably what happened to me originally with cloneA.

To answer my question, the git repo doesn't have the llb already set up, they are built afterwards through a script (i'll edit once I find what it's called, where it is and where it's called) by using the Build Specifications in each smaller Labview projects (.lvproj).

Thank you all for your suggestions.