03-10-2017 10:27 AM
Hello All,
I have several test stands that operate off two very similar (base) programs. They each share most of the same subVI's. I have 3 total individual projects that share these subVI's but the way I have it right now is these subVI's are their own entity in each project, so when I want to make a change, I have to do it to all three.This is obviously not ideal.
My first thought is to place all the shared subVI's into a single folder and have the individual projects look at this folder but I was curious how the great labview gurus would handle a problem like this? (combining the base programs would not be a simple task as the hardware is quite different)
any input is welcome,
Thanks in advance
03-10-2017 11:13 AM
What you are talking about is a common re-use library. These are absolutely invaluable however there are some common pitfalls that you need to address before you "Just move stuff to a common folder." I'll give you some advice learned the hard way.
Mostly though, Documentation, Documentation, Documentation!!! Before you code, while you code and after the code review! Reuse code needs tight control.
03-10-2017 01:58 PM
Where exactly do you keep your unit tests? Are they in the same library as your reuse code or do you have them in a separate library right next to it? Also, when you install the package do you include the unit tests or should they just live in your SCC?
03-10-2017 02:54 PM - edited 03-10-2017 02:58 PM
Hey Matt. I usually keep the UTs in a tests folder in the source lvproj of the lvlib. Which reminds me I need to post a report about New••Unit Test from PE naming everything Unit Test with no prompt to rename the file I recommend a document folder too! Test reports go in the lvproj as well as a readme bug tracker. A link to fogbugs would work too to trace defects in the project. A common rel path makes it simple to run UTs programmatically with an easy to understand utilliy. UTs reports documtation do not deploy with the reuse package.
Its Fairly robust for small to mid sized teams. I'd not mind an overview of how NI manages huge teams around new dev and defect investigation. But that is way beyond scope for the OP.