Consequences of including "add-ons" (eg. JKI SM, DQMH, etc.) inside actual project?

[DoctorAutomatic]

Unlike many here, the small team I'm on doesn't really jointly work on projects, we have no team style guide or official framework. And it's fine, really,.

However, I like to use DQMH and JKI SM a lot and it's annoying when I want to open a project on a lab computer without those add-ons. What would be the implications/consequences of simply copying all those add-on related VIs into a folder within my project directory/hierarchy? I personally don't anticipate future updates being THAT different and it really doesn't matter as most things we make are rather static once deployed.

[JÞB]

The consequences vary widely depending on the add-on type.

Toolkits usually install to vilib.  So simply copying them to somewhere else is going to break polymorphic vis and cause project conflicts. Function Palettes will also be missing.  Examples; OpenG TK, MGI TK, JKI SM, Hidden Gems TK, VI Annalyzer, VIPM.

Frameworks install support in special locations and extend the IDE functionality by hooking into LabVIEW itself providing extra menu options on the toolbar or from right-clicking certain contexts. Those cannot work from inside your project! Examples; DQMH, Actor Framework, TSVN TK, UTF, NIPM

Modules depend on additional licensed software products and will not work without the associated driver present period! Copying the VIs won't help at all.  Examples; DAQmx, FPGA, NI Vision.

Conclusion: "simply copying all those add-on related VIs into a folder within my project" is a really bad idea.  The better choice is to get your development team into a closed room and hash out a standard development environment.   PLEASE! I really can't caution you enough!  Just don't do that. 

NOTE: some of the examples listed are so darn popular that LabVIEW has chosen to automatically install them. AF, VIA, UTF, VIPM, Hidden Gems the JSON support...

[Darren]

Consider creating a .vipc file that lives alongside your project and contains all the packages used by your source code. Then you just need to make sure the .vipc file is applied on any system you're working on before you open the project.

P.S. - Jay is 100% right about the dangers of copying the installed files to your project. Among many other possible problems, cross-linking is bound to occur whenever that code is opened on a system that happens to have the files installed to the LabVIEW folder.

[BertMcMahan]

Yeah, putting those addons in your project will 100% give you headaches.

I'd spring for VIPM Pro. Standard/free VIPM will let you make a package installer to install your own code, and it's great once you get the hang of it. VIPM Pro will (as I understand it) scan your project for required packages, then make a combo package (the vipc file Darren mentioned) containing everything you need. You can then keep that combo package with your project file and run it on any computer that needs those packages. VIPM Pro is only $600 so it's not bad for a business expense. Consider how many hours per year you take manually tracking down and installing packages, and I bet it pays for itself within few months tops. (FYI it's a perpetual license but it does only get you a year of updates)

[Gregory]

It will vary from toolkit to toolkit. The JKI state machine only has 2 or 3 VIs it adds on, so it would be relatively easy to move the locations of those. I believe everything from DQMH is part of the project, but you won't get the scripting tools if you have not installed VIPM package on the PC you're using.

You can also look into Dragon, which is designed to install VI packages next to the project, rather than in vi.lib.

https://www.vipm.io/package/dragon/

[Darren]

---

@Gregory wrote:

I believe everything from DQMH is part of the project

---

The message queue and module admin libraries are installed to vi.lib.

Good call about Project Dragon, I hadn't thought of that alternative. My best suggestion is still .vipc files though, they make all of this so easy.

[Gregory]

---

@Darren wrote:

---

@Gregory wrote:

I believe everything from DQMH is part of the project

---

The message queue and module admin libraries are installed to vi.lib.

---

Ah good correction, I see that now as I explore a project.

There was also the G Package Manager with installs on a per project basis. But, the website (gpackage.io) is not working for me right now. I haven't used GPM or Dragon, just seen demos of them and I really like the idea of per project toolkits, because that's what I do for my own re-use code.

[RTSLVU]

Hmmm... I have thought about this as I have to support LabVIEW on several computers in our lab.

Is your company actually buying licenses for every single computer in your lab? 

Why aren't you deploying executables on the lab computers? No license is required to run compiled LabVIEW applications.

I have the LabVIEW development environment installed on a laptop, so when I need to troubleshoot or develop an application. I just take my laptop into the lab and connect it to the instruments. When I am done I build the application and install it on the lab computer. 

[JÞB]

---

@Gregory wrote:

---

@Darren wrote:

---

@Gregory wrote:

I believe everything from DQMH is part of the project

---

The message queue and module admin libraries are installed to vi.lib.

---

Ah good correction, I see that now as I explore a project.

There was also the G Package Manager with installs on a per project basis. But, the website (gpackage.io) is not working for me right now. I haven't used GPM or Dragon, just seen demos of them and I really like the idea of per project toolkits, because that's what I do for my own re-use code.

---

Two words. Virtual Machine. 

[paul.r.r]

Don't use GPM - as far as I know that project is dead.

Using VMs doesn't fully solve the problem - you may still want multiple versions of a package installed on one VM. I use VMs for everything I do, and try to have one VM per customer 'project' at a high level, but I still often end up with multiple LabVIEW projects on a single VM - having one for each individual project would be a nightmare to maintain. 

We've moved to using git submodules, but that doesn't really solve the issue for packages that are only distributed as VIPM packages.