Building JKI VI Tester as a PPL

[cbutcher]

Has anyone tried doing this, or have any tips?

I'd like to try repackaging the JKI VI Tester, partly because it takes some time to load, but particularly because if I create a test case in a project, it blows up the dependency list due to no library which holds all of the VIs in vi.lib.

Currently I'm looking at taking the files from <LV>\resource\JKI\VI Tester and <LV>\vi.lib\addons\_JKI Toolkits\VI Tester - are there other places I should be looking?

To avoid breaking the existing libraries, should I just copy everything to a new directory and build from there? I'm still just starting out with repackaging code using PPLs and so this is only the 3rd thing I'm trying - other things had fewer different folders to track down.

Any tips appreciated. Otherwise, I'll post once I'm done 🙂

[cbutcher]

From a few runs at the copied built files and then the github sources, it looks like perhaps I should instead be trying to package the OpenG functions used by JKI's Unit Tester, and then rebuilding that with the packaged files as a dependency.

Definitely seems like too much trouble at the moment. Might come back to this later, or if anyone has tips or suggestions.

[James_McN]

Love the idea - it has long been on my todo list to go diving into VI Tester source code - it feels like there should be some ways to improve the load performance and this would certainly be an interesting one. Would probably want a build server that can autobuild across LabVIEW versions or an installer which unpacks the source and builds locally.

[bokorpet]

Hi,

cbutcher, is your main motivation to make (the initial loading time of) VI tester faster?

PPF (Project Provider Framework, basically LabVIEW's plugin framework) assumes a specific code structure (GProviders, plugin VIs, etc.) and you have to be careful not to break the dependencies. I also think that using packed libraries can speed-up things (as packed libraries are compiled).

You can check other unit tests frameworks as well that are "thinner", e.g., InstaCoverage does not depend on OpenG functions. 

Peter

[cbutcher]

---

@James_McN wrote:

Love the idea - it has long been on my todo list to go diving into VI Tester source code - it feels like there should be some ways to improve the load performance and this would certainly be an interesting one. Would probably want a build server that can autobuild across LabVIEW versions or an installer which unpacks the source and builds locally.

---

The build server is a probably important point - the existing source code uses the OpenG package building tools and a "build.vi" to create an ogp package, I guess this allows automated build in different versions of LabVIEW.

I'll look closer at this, my brief attempts yesterday allowed me to package some parts as PPLs but caused the build process to fail because the ogp process uses config files specifying sources and destinations, and of course my sources changed (and I'd want to change the destinations too - currently they're almost all LLBs).

A large number of the VIs being dragged around are polymorphic for a collection of data types - I'd guess (without having checked yet) that these can be easily (perhaps trivially) replaced with VIMs, but of course this would shift the minimum version of LabVIEW to 2017. That's ok for me, but presumably not ok for VI Tester in general. I might still look into it though - I think it would probably cut at least 10% of the VIs being loaded with relatively little effort.

Regarding another tester, perhaps InstaCoverage, Caraya or the NI Unit Tester, I like JKI VI Tester, and whilst I find some aspects a little annoying, I think I probably need to balance minor irritation against a pretty great free tool, and say that I still would make it my first choice.