05-13-2024 04:46 PM
Hello,
What is the best way to reuse DQMH modules for future projects? I currently work at an ITAR facility so the code shouldn’t be uploaded anywhere.
I’ve read about PPLs and am aware of the VIPM reuse library.
Is there an issue with me just placing all my modules in a certain folder and just using the VIs from that folder and having them tied to the dependency of each new project? I just tried this with an API tester and it seems to work with no problem.
Solved! Go to Solution.
05-13-2024 09:16 PM - edited 05-13-2024 09:52 PM
You could consider creating a repository for every reusable module, and then using Git Submodules.
Git submodule basics:
05-14-2024 12:27 AM
Or if you were using SVN, then maybe SVN externals (similar but not exactly the same thing as git submodules):
What are the differences between Subversion and Git? - GitHub Enterprise Server 3.12 Docs
10-17-2024 02:37 PM
Hello,
I finally am at the level where I want to create an executable. I ended up using Tortoise SVN externals to reference my DQMH modules. In the development mode this works without a problem. However, when I run the application it looks for the DQMH module in the data location of the executable and gives error 1003.
Is it possible for me to change it to reference the repo for dependencies of the application? I’ve tried googling this, but no luck finding a solution.
10-18-2024 12:08 AM
How have you built your exe?
Are you trying to call your modules dynamically, or are they all statically linked in your application?
10-18-2024 12:11 AM
I have, but like I mentioned I got a bunch of errors with config file trying to reference the data folder in my executable for my sub DQMH modules.
I tried making them all into PPLs and still have the same issue. I didn’t try adding the vipath to the config file using my original method, but I did with the PPL method and I had no luck.
10-18-2024 12:34 AM
It's really hard to understand what your challenge is without seeing it.
Can you provide a bunch of screen shots?
ie. An Antidoc diagram to show us all of the modules and how they're related, build spec, project etc?
10-18-2024 01:57 AM
The use of submodules in your source control software should not affect your LabVIEW project. It's actually just another way to save the source code.
Finally, your SVN repo should be set up in such a way that the files are synchronized to your local LabVIEW directory. LabVIEW only sees your local file system.
The DQMH modules must be compiled into the executable.
10-22-2024 02:30 AM - edited 10-22-2024 02:37 AM
Sorry for the delay I’ve been trying to find out why I have this issue and even rewrote my code one sub DQMH module at a time. I have found my problem DQMH module. I’m using the DLL “sa_api.dll” and for some reason when I add this module my application breaks on my virtual machine, but runs fine on my development station. I linked the LabVIEW library used for this DQMH module below.
https://signalhound.com/software/signal-hound-instrument-drivers-for-labview/
The dll is included in the application I see it in the data folder.
It seems to work okay if check “exclude shared libraries” then the application asked on virtual machine to select the DLL and when I do it works okay.
10-22-2024 04:15 AM - edited 10-22-2024 04:24 AM
I guess, the reason for the issue is not the application or DQMH. How do you call this dll in LabVIEW? My advice is to pass a path to your dll inside a conditional disable structure to decide if you are using the dev environment or the executable.