LabVIEW
Consequences of including "add-ons" (eg. JKI SM, DQMH, etc.) inside actual project?
Solved!
@RTSLVU wrote:
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.
Resurrecting this topic (I make no apologies for this since it was my own topic after all).
You make a valid point. Most lab computers are in fact simply running built executables. There are some specific computers with dev environment because it makes sense for numerous reasons.
I originally had the VIPC idea that was also mentioned earlier. The main problem is that for some reason, in the last year or so, some sort of enterprise security software is preventing VIPC files from being opened. The company was a victim of a massive, and very public, cyber attack a few years ago and since then the security has been insane. It would be almost impossible to get approvals for our small team to avoid this inconvenience related to VIPC files. What's strange is that I can use VIPM to install packages directly from it's own repository but I when it comes to a VIPC file I download (via the web) or ones that I create myself using VIPM they will not open. I forget the exact message but a windows error dialog pops up saying the PC doesn't have the right permissions to open foobar.vipc or something along those lines. I really wish that wasn't the case because there are a few packages I would really love to have (gRPC and Extensible Session Framework) but the developers have not made them available directly through the VIPM interface for some reason (unknown to me) and so I'm unable to install them.
Back to my original question. So the consensus is "this is a terrible idea" but I seem to recall specifically watching some video with Fab where she moves the DQMH classes into a library inside her project and builds the library as a PPL which is then used as the DQMH dependencies for that project. That sure sounds like what I'm thinking of and what everyone is advising not to do. I can't remember if there was some special circumstances around what she was doing that would place this into a category of special exceptions to the rule.
I was under the impression that part of the reasons this is not done is because it duplicates code. If an application is made from a number of DQMH modules, each packaged with their own underlying DQMH dependencies, then you have that many more VIs in the final application. To me that is of no concern, storage is cheap, our applications are never so large that this would ever be a problem. The OTHER reason I'm sensing in this discussion is the potential for some sort conflict having the same dependency included for each module. Are we talking a namespace conflict? I would think not if items were included in builds either inside libraries or using the option to add a prefix to the names in the build specs.
If you're inheriting classes across PPL's, you have to have a single instance of the class at the highest level PPL. You cannot have each PPL inherit their own copy of a class and have them work together across the PPL boundary.
You do this with the Actor Framework as well, and it's generally quite hard to get right, and you really need to design for this from the start. I don't use the DQMH module myself but if it has a dependency upstream, then it will need to be packed into a PPL at the "top" level, and you will need to have all modules inherit FROM THE PPL- NOT from vi.lib (or wherever it's stored).
The reason is that, when a PPL is built, if it "brings its own copy" of a class, then that class is namespaced inside the PPL. Even if it's "the same class", the compilation process locks the dependency to MyPPL.BaseClass.lvclass. You have to first build the base class into its own PPL, then in the dev environment switch all the dev stuff to that PPL- not the source code from where the PPL came.
There is also the issue that the relative paths of all dependencies have to match in both the compiled code and in the source code, as the compiled PPL uses the relative paths to find the source of any dependencies. There are a few good videos of it that talk about it in the context of the Actor Framework, but it should be the same for your case. In AF, there's a base "Actor" class that all sub-actors inherit from, which needs to be built into a PPL and included in your project.
