Trouble using module template that references re-use libraries

[Gregory]

I tried to make a DQMH template for the first time today. I created a new project which follows the same structure as most of my LabVIEW projects:

DQMH Templates.lvproj

     Re-Use

          Re-Use.lvlib

     Modules

          Template 1

The code in Template 1 uses some VIs from Re-Use.lvlib. Then I try to create a new module in my project, which has a similar structure:

My Project.lvproj

     Re-Use

          Re-Use.lvlib

     Modules

          Module 1

The module which I created with my template (Module 1) creates many conflicts, looking for the Re-Use functions in the DQMH Templates folder. Can someone teach me the correct way to do this?

Thank you,

Gregory

[greenfish3]

Hi Greg,

I think I've had similar issues when I was trying to use a module template in a project which contained the original module (from which the template came). I think the work around I used was to add the module to a new empty project and work out the dependencies. Once there were no "foreign" dependices I saved the libraries and then re-added them back into the original project. I think that cleared it up. 

Not sure if that makes sense. It might help. I'd love to hear how others handle this.

[Dhakkan]

---

@Gregory wrote:

I tried to make a DQMH template for the first time today. I created a new project which follows the same structure as most of my LabVIEW projects:

The code in Template 1 uses some VIs from Re-Use.lvlib.

---

If your Re-Use.lvlib is stable enough, perhaps you could package it up and make it a prerequisite install into a standard LabVIEW folder (user.lib, for example)? That way, you and your colleagues will always have that library available in the same location.

[Gregory]

---

@Dhakkan wrote:

---

@Gregory wrote:

I tried to make a DQMH template for the first time today. I created a new project which follows the same structure as most of my LabVIEW projects:

The code in Template 1 uses some VIs from Re-Use.lvlib.

---

If your Re-Use.lvlib is stable enough, perhaps you could package it up and make it a prerequisite install into a standard LabVIEW folder (user.lib, for example)? That way, you and your colleagues will always have that library available in the same location.

---

Yes I suspect that would clear it up. But I decided a long time ago to keep any Re-Use code / instrument drivers with the project, so that I can move my code to any PC without having to install any packages. 

[Gregory]

Good news, it seems the issue was related to where I was creating the modulate template. Originally I selected "Current Path" (because less copies sounded good). Now, I tried in the LabVIEW Data folder and it's working as I had hoped. When I add a new module with this template I get a warning that some dependencies were loaded from a different location, but they are referencing the Re-Use VIs in my current project, and no extra dependencies are added.

[joerg.hampel]

We used to make a point of having all dependencies inside the project repository. It turns out that this becomes really brittle and error-prone when creating reuse code that lives outside - like DQMH module templates.

Over the first half of this year, we moved our basic reuse libraries to vi.lib. This way, all module templates etc. will only reference code in vi.lib, and no relinking is needed when using those templates for any project.

Greg, if your system works for you, that's great. Good for you! Just be aware that the templates that are stored in LabVIEW Data now actually reference your project-specific code from the project you used to create the template.

Yes, LabVIEW is clever enough to relink on the fly when you have identical dependencies already loaded in the project. I think you'll still have to be very careful to avoid confusion or cross-projects-linking. 

[Gregory]

Hi Joerg, thank you for your insights. Yes, I've always strived to have all dependencies inside the project. Of course, adopting DQMH for many projects has created that one exception. 

Now that VIPM allows anyone to create a package configuration, it removes the hurdle of telling people they must install x, y, and z before they can open the source code. 

Maybe it's counterintuitive, but I have avoided centralized Re-Use code because I was afraid I might find and fix a bug in my Re-Use code. Then that fix would propagate to another project that I open 6 months later, and some behavior would be changed that would be tricky to figure out.