what does "Automatically Build Packed Project Libraries at the start of execution" do?

[DLMC]

Windows 11 Enterprise

Labview 2022
TestStand 2021

While trying to get a project working in the RTE, on a lark I selected Always run VI in Packet Project Library and Automatically Build Packed Project Libraries at the Start of Execution options.

This did not change anything, so I went back to developer engine and unchecked those boxes.

After that (I think) I stopped seeing a bazillion "loading VI" popup messages when I ran the project in the developer mode.  The project also has a noticeable pause before it starts running now.  

So now I am wondering, did I accidentally create a PPL at that time that is negating everything I am doing in the current environment by being where VIs are gotten now?  Where would TestStand have saved that PPL and if it exists, how can I get rid of it?  Am I stuffed and have to create a new project to get away from that mistake?

Am I reading too much into this?  I noted another thread where a posting said that if you run from a PPL there will be a longer start up time while the PPL is loaded.  This is what makes me think I have an undesired PPL "out there" somewhere that I need to deal with.

Can someone shed some light on this for me?

be well,

DLC

[Oli_Wachno]

Ok, so let's have some basics....

A PPL or LVLIBP (both terms are common) is a bunch of precompiled LabVIEW Code with all dependencies included.

It is build from a LabVIEW library (LVLIB): it contains all VIs within this lib + their respective dependencies outside of the LVLIB. This also holds true for dependencies which are usually found in public locations like the vi.lib.

This makes an PPL / LVLIBP a block of code which can be used independently. Since it is pre-compiled, you will also see faster load times.

Having said that, compilation of LVLIB to LVLIBP does take some time. Not to mention, that depending on the use case, there are some more caveats to consider for advanced use cases.

We are heavily using LVLIBPs with our framework. But we build them before actually integrating them into TestStand.

This way, we never came across major issues and never had to use those (no very well documented settings).

My interpretation of https://www.ni.com/docs/de-DE/bundle/teststand/page/organizing-test-program-files-with-labview-pa.ht... being this is also the preferred way.

Alas, everything below isonly backed up by some limited trial and eror (because this has tickled by fancy 😉

So let's start from deployment first:

The TestStand Deployment utility lets you put your .vi CodeModules into a PPL. You have to make settings using the LabVIEW Options (https://www.ni.com/docs/de-DE/bundle/teststand-api-reference/page/tsref/labview-vi-options-dialog-bo... 

So this is an actual build process!

Yet, you are no deploying yet.... so, let's check this use case.

Looking at the help

doesn't really help.... at least that's how I feel.

When superficially reading the second bullet point, one could think "oh well, this VIs are automatically build into a PPL". Which is infact also what I used to believe up to today.

Yet setting this options and running the Mobile Device Test.seq obviously did not build a PPL.

The first bullet point is IMHO only applicable, when defining a LabVIEW project for the code calls (which infact has an implication regarding the application instance the VIs will be running in). Yet, this makes sense in the context of the PPL Build Script being defined within the project.

After all, this doesn't solve your original issue at all... 

[DLMC]

That is a fantastic discussion of how to build an installed image.  But there was a little "hand waving" there.  I tried to create a PPL and found that I could not put a VI in a PPL, it wanted a packed library and a top level VI from said packed library.  When I tried to create a packed library it looked like it was re-linking every raw VI to the sub-VIs in the library, so I stopped doing that because it looked like if I turned the project files into a packed library I could not use the "raw" VIs because they were changed.  If that was the case do I have to create a shadow project for the raw VIs and have two sets of files to keep in the source code repo?  I am uncertain how to proceed with creating a PPL.  The rest of the developers here have had very little success with creating useful PPLs and prefer to use LLBs.

You had mentioned "The first bullet point is IMHO only applicable, when defining a LabVIEW project for the code calls (which infact has an implication regarding the application instance the VIs will be running in)."

I don't get this at all.  So far as I have been able to discern, a Labview project's only value is in organizing the VIs and their dependencies so you can build a pure LV exe from it.  You can't make a PPL with it to use with TestStand, you can't make a packed library from it and it isn't useful at all with respect to a TestStand project.

This whole topic seems opaque, even after reading the "how tos".

be well,

DLC

[Oli_Wachno]

@DLMC wrote:

[...]

I tried to create a PPL and found that I could not put a VI in a PPL, it wanted a packed library and a top level VI from said packed library.  When I tried to create a packed library it looked like it was re-linking every raw VI to the sub-VIs in the library, so I stopped doing that because it looked like if I turned the project files into a packed library I could not use the "raw" VIs because they were changed.  If that was the case do I have to create a shadow project for the raw VIs and have two sets of files to keep in the source code repo?  I am uncertain how to proceed with creating a PPL.  The rest of the developers here have had very little success with creating useful PPLs and prefer to use LLBs.

[...]

You mean like in drag and drop? Obviously doesn't work this way! A PPL is built code, therefore you need to have a buld script.

https://youtu.be/BvUy8BR3tDo?si=uPnTH2MYZRQ1dtgi

Regarding using lvproj and TestStand:

https://www.ni.com/en/support/documentation/supplemental/13/how-teststand-interacts-with-labview-app...

[Oli_Wachno]

BTW... just checked Nigel

[DLMC]

---

A PPL or LVLIBP (both terms are common) is a bunch of precompiled LabVIEW Code with all dependencies included.

It is build from a LabVIEW library (LVLIB): it contains all VIs within this lib + their respective dependencies outside of the LVLIB. This also holds true for dependencies which are usually found in public locations like the vi.lib.

This makes an PPL / LVLIBP a block of code which can be used independently. Since it is pre-compiled, you will also see faster load times.

Having said that, compilation of LVLIB to LVLIBP does take some time. Not to mention, that depending on the use case, there are some more caveats to consider for advanced use cases.

---

This is of course ideal now that I know that the RTE knows nothing that isn't told to it.  Why is the RTE even in the IDE if you can't use it?  I suppose if you have a perfectly constructed PPL then you could use it.  I will do a trivial example to see how that works.

---

We are heavily using LVLIBPs with our framework. But we build them before actually integrating them into TestStand.

This way, we never came across major issues and never had to use those (no very well documented settings).

---

Wow, that would require you make no mistakes and your VIs do exactly what you wanted and you don't have to tweak anything to work and...  It seems like a huge leap of faith.  But  if your VIs do all the work and you only use TestStand for report generation and database access, then 90% of what is in TestStand isn't useful to you.  That makes TestStand a typical "Leatherman" tool, it can do anything, but does nothing well.

But if you are very experienced with TS and your tests follow an expected pattern, I can see where you would eventually land here.  I am clearly not at this place.

After all, this doesn't solve your original issue at all.

Well, no.  But you did help explain how the pieces go together, and like me, found that this checkbox doesn't do anything at all.  So, it kinda answers the question.  🙂

be well,

DLC

---