Hello,
I searched for information on this topic but didn't find much. All comments are appreciated. Sorry for the long post.
I have seen in multiple places that a relative reference is recommended instead of an absolute reference. I'd like to have a discussion on if/why this is the case, and also how the use of search directories plays into this decision. My group has found that using relative references is very troublesome when it comes to deploying/supporting systems, but perhaps there is something we are missing or are fundamentally doing wrong. If it's our setup itself that is not ideal, I would like to understand its pitfalls as making a significant wholesale change would likely be a serious undertaking. We have only been using TestStand/LabVIEW for about 4 years so we are relatively (no pun intended) new to NI. My concern is that there may be additional functionality or features that we may want to implement in the future. I don't want to get so far down the wrong road that we can't turn back or correct.
I can see benefits to using relative references; the main one being that a TestStand project can be deployed to a system in an arbitrary directory and still have all necessary files linked properly (assuming relative folder structure is maintained). For those needing this capability, this is a huge benefit. Search directories add to this by allowing TestStand to essentially self-heal broken links to VI's, etc by providing an expected location of where they may be located if the relative folder structure deviates from what is expected.
My group was initially using relative references and the instrument library folder (instr.lib) within the standard LabVIEW install and had the following issues:
- If you were not the initial designer of a sequence and had to work with something someone else created, many of the instrumentation driver VI's called within the sequence would not be found because they were not installed on the your system. The solution would seem simple - install those driver VI's on the system! In practice though, it was problematic. The main issue was that you needed to first find them, and second make sure you had the same version of the drivers that were installed on the original system (otherwise things would either still not work or may behave differently than the original).
- Alternatively (and worse), TestStand would load a VI from an entirely different instrument it found within the search directories on the development system because it had the same name. If you made a necessary change to the sequence and then saved, it would blow up when it tried to run back on the deployed setup (because it was now saved with the alternate VI called).
- Example: many Agilent provided driver VI's use the same name for similar functionality with different instruments (initialize.vi, reset.vi, etc.). Suddenly a step to initialize a signal generator wouldn't work because the VI was replaced by one for an AC power supply...
Because of the issues mentioned above we decided to move all of our TestStand and other necessary files into a common location (C:\TestStand). Subdirectories to this folder are those for Sequences, DLL's, Common VI's (VI's used in multiple deployments), Setup (process model, schema, etc.), and others. This greatly simplifies source control as we link to the main TestStand directory, which means everyone is developing from the same controlled repository and folder structure. Our deployments also use this same folder structure (although unused/unnecessary folders are not on the deployed systems).
All of our instrumentation driver VI's are also under our C:\TestStand directory instead of the instr.lib folder. Same with our internally developed VI's, DLL's, etc.. Now, when someone updates their directory from the repository it automatically pulls/updates all files for all systems onto their computer (or vice-versa). For support of a deployed system, this greatly simplified the ability for any support engineer to be able to pull a sequence from a system back to their PC and be able to run it (or at least edit it) without first spending hours trying to re-link or download driver VI's.
We also switched our standard practice to use absolute references instead of relative. The above measures provided significant simplification for support engineers to be able to work on a sequence, but we still had some issues if someone forgot to update the driver VI's to the repository. As an added measure of preventing unintentional remapping from TestStand, the absolute references allowed a sequence to be edited and saved without overwriting the (missing VI) link with an improper VI path if it found an alternate. Both of these require the engineer to do their job properly, but together they seem to work well.
Have others experienced these same issues, and if so how did you overcome them? What are the pitfalls to using absolute references (other than limiting deployment to the same directory structure, which is not an issue in our case)?
Regards,
