(Bigger) DQMH Project, Number of Modules and VI's

[lderuyter]

DQMH Developpers,

I've worked multiple weeks on a bigger DQMH Based project. As the weeks were passing by the Labview project grows and the development environment slowed down.

I've ended on 37 DQMH modules, containing about 3000 vi's.

The project is nicely structured thanks to the DQMH structure but some struggles I have,

-> Opening the labview project takes a bit longer, about 2 mins to load the vi's

-> 'Debug Remote Application' is very slow it takes 10 minutes to be connected with the remote vi's.

-> The DQMH Scripting VI's are slowing down, it takes around 30 sec to 1 minute to load the modules in the project, sometimes it's blocking a bit. Also the scripting itselfs blocks sometimes.

-> Compilling for a windows target takes about 5 minutes which is reasonable, but compiling for a real-time target takes about 30-45 min, also running project on the cRIO within labview takes some time to deploy. (5 to 10 minutes)

In general, I'm feeling that the whole Labview Development Environment is slowing down. During the project is getting bigger till the 3000 vi's now. 

Anyone who can share some experience about big number of DQMH modules?

Regards, 

Lucas

[ConnerP]

I don't have specific suggestions for you, but I can say that this is not a DQMH specific issue, this is a labview issue. It is one of the prices we pay for things like automatic update propogration of typedefs. The Development Environment has to keep track of all these inter-connections. The only solution I know of off hand is to move to a more "Solution" oriented approach where you break the main project up into isolated blocks, each with their own Projects. I have never used it, but the MGI Solution Explorer comes to mind.

[drjdpowell]

I don't use DQMH, but use "modules".  In a large project I will periodically create a new project and pull one module over by itself, to look at its dependencies.  I look for unwanted dependencies.  Sometimes, just because a a couple of typedefs in libraries, I find one module, that shouldn't depend on much, actually loads half the large project!  Then I break the unneeded connections.

[Olivier-JOURDAN]

My biggest project made with DQMH has 40+ modules and 60+ LVClasses for 4000+ VIs. It's only running on Windows.

I would say that the loading and building time I have are usual for that kind of project size. I don't experience slowness during code 

I'd agree that the performance issues you are describing are certainly due to some cross-linking. Try what drdjpowell advice, it would certainly help.

[Taggart]

I certainly had issues before with a large AF project. It was caused by typedefs in libraries creating circular dependencies. Try Dr. Powell's approach and see what you discover. Anti-Doc is also useful for visualizing dependencies between modules. 

I would also consider the PPLs approach. However if you have crosslinking you will have to solve that before you can move to PPLs anyway, so might as well do that first and see if that alone solves your problem. PPLs add a bit of complexity.

[joerg.hampel]

We usually don't have huge projects, but a few are the same size that you and Olivier mention. 

• A windows project with ~20 DQMH modules takes 30 minutes to build
• A Real-Time project with ~20 DQMH modules takes 40 minutes to build

A way to cut down on compile times is to build your modules into PPLs. There's a thread somewhere talking in detail about how to go about building DQMH modules into PPLs.

[Jens_S]

I'm a bit late to the party but are you using LabVIEW Classes in you modules or a general Object Oriented approach? If so LabVIEW is creating a class data mutation history witch can increase you loading times a lot. You can read more about this here -> https://www.ni.com/de-de/support/documentation/supplemental/07/preserving-labview-class-data.html

[lderuyter]

I converted the DQMH modules in the project to PPL, So the project is now contains 36 DQMH PPL's & 1 DQMH Module.

I did some benchmarking before & after.

-> Opening the project : Before 30 sec / After 40 sec (bit slower now)

-> Opening the 'Main.vi': Before 90 sec/ After 2 sec (much faster)

-> Adding new (empty singleton) DQMH module (scripting): Before 180 sec/ After 180 sec (same speed)

-> Opening create new DQMH event dialog: Before 45 sec/ After 6 sec (much faster)

-> Creating new DQMH event (scripting): Before 30 sec/ After 15 sec (faster)

-> Wiring & Placing subVI's is also smoother & faster now

Overall the project is a lot smoother now. Not as fast as a new 'empty' project, but it's good workable.

This video of Matthias Baudot was also useful for me: https://www.studiobods.com/en/gdevcon-1/

@ drjdpowell: I've put each DQMH module in a separate project to compile to a PPL, this way it's easy to keep track of the dependencies of each individual module.

@ Jens_S: No object oriented in this project (except for the DQMH stuff)

The big pain was that I couldn't use the "Replace with packed library" function. Labview crashed by doing that.

Thus I had to replace the modules manually, and replace all the API calls manually 😵

[joerg.hampel]

Thanks for the benchmarks, Lucas. It's always interesting to read about real-life experiences with DQMH and PPLs.