Managing labview VIs

[Jed_Davidow]

I have a teststand framework that contains two folders that serve as VI "libraries", with several hundred Vis each. 

Up until this point, I have not collected the Vis into project or vilib files.

In order to be able to run multiple versions of our code on the same machine and not worry about "cross contamination", I collected the Vis into a vilib and then a project file. I updated all teststand calls to point to the projects.

This has caused the sequence editor to slow to a crawl during editing. For example, inserting a statement step takes 5-10 seconds, navigation has constant latency, and editing statements is delayed and extremely frustrating.

I have found that disabling the search directory containing the VI allows the editor to be responsive.

1) I need to keep the Vis in project files, in order to separate the name spaces, correct? Operators open more than one version all the time on our testers.

2) is there a way to fix this and keep the search directory?

3) do I need to keep the project files, but move to relative paths and not search paths?  If so, is there an easy way to convert the found VI locations to relative paths? Or will I have to adjust each instance? 

[Oli_Wachno]

I am not aware of lvlibs slowing down load times....which LV version are you using?

My preferred way of preventing cross contamination is to use TestStand Environments and saving code modules in project subfolders.

How many custom entries do you have in the search paths? 

[santo_13]

Oh, yeah. When you point to a VI from an LV proj in a TS Step, TS tries to load the entire project of VIs into memory, which causes TS to slow down.

Referring to a VI through a project is suited when the developer/user is susceptible to making edits that result in cross-linking. Unfortunately, this results in a worse developer experience due to TS loading delays.

Easy fix is to leave the lvproj empty in the step configuration when loading the VI so TS doesn't load just every VI and only the dependencies of that VI.

[Oli_Wachno]

Points given for lvprjs, my previous answer was focussed on lvlis, sorry!

Yet you don't use lvprjs to seperate code, since they don't introduce namespaces.

Also lvprjs may introduce application instance issues

[J.C._Andersen]

It sounds like you are calling "source code" in your TestStand sequences instead of code modules which have been thru a build process.

I would build code module in to PPLs and then call the export VIs in the PPLs from TestStand. The PPLs are versioned, so you know exactly which version of the code you are using.

Further more it enforces a workflow where you separate the development of code modules from the development of the test sequences. You can build your PPLs with debugging enabled, so that you can step in to them and set breakpoints for debugging, but you cannot change any thing on the spot. You are forced to find the bug, close TestStand, open LabVIEW, fix the bug, build a new version of the PPL, deploy the new PPL and try it in TestStand.

I know that many people will consider this extra work, but it will increase the quality of your work and give you less headaches in the long run.

[Oli_Wachno]

Yet, there is a bit of a lerning curve using PPLs, so if you haven't worked with them already, this might be a wholre different can of worms... 

[Jed_Davidow]

Would love to do that.  Unfortunately we are deep in product development, and I am constantly debugging on these systems.  Pre-building code and deploying like that is basically untenable at this point.  I hope to get there.