Internal file organization in a module?

[1984]

Hi,

What I have found a bit hard with DQMH module is how the files are organized into virtual folders. It is clear which part plays which role, but sometimes is a bit challenging to find what you are looking for. This does not just bother me due to my poor eyesight but also somewhat a concern how to identify the custom functions of the module after half a year of not working on it if they dont stand out of the crowd.

I have tried couple things to make it more readable for myself.

1. Tried to use a module specific prefix for my requests: eg created a module for DMM4060 then I prefixed all my non-stock dqmh files with DMM4060.
   • Good: you really can see what is your code and what is stock DQMH
   • Bad: its not easy to find a short but still descriptive prefix for the module. Even DMM4060 is way too long. Besides that the icons show the prefix so I need to correct the text on them manually
2. Tried to simply use a prefix REQ for requests, BRC for broadcasts and CTL for controls.
   • Good: as the first one, plus shows the function of the file
   • Bad: if you use multiple modules then the REQ whatever.vi doesnt help you to know which module the VI belongs to. Same icon problem.
3. Tried to collect all custom files in a virtual folder
4. Tried to move all the stock DQMH requests to a virtual folder

Overall #3 worked the best for me but still not a holy grail cause I can easily forget to move files into your folder. Wondering if anybody has a better strategy working for him. (yeap, I know its not a DQMH problem per say, but I have it daily when I'm working with DQMH so I thought its worth asking)

Thx

[1984]

Not to mention with #3 that renaming and some other built in DQMH functions dont really work because the dialog windows wont list the request outside the designated virtual folder.

[joerg.hampel]

It seems you're talking about requests, mostly. We've never bothered moving those away from the Public API folder. 

The way we - HSE - organise files inside a DQMH module is:

1. Leave everything that was created by DQMH scripting where it is (both on disk and in the .lvlib)
2. Store any files created by ourselves in a separate subfolder (both on disk and in the .lvlib) which we usually call "SubVIs"

Note: The DQMH Consortium and Delacor advocate leaving all files in the flat folder structure, not creating subfolders on disk but only organising files in the virtual folders of a .lvlib.

[Darren]

I strongly suggest using a flat disk structure for all libraries, including DQMH modules. A .lvlib/.lvclass should live in a flat folder with all its member VIs. In my opinion the only time you should create a subfolder on disk is if the library contains a sublibrary... that sublibrary (and all its member VIs) should go into a subfolder of the library's folder.

As for project organization, my suggestion is to create a 'support' virtual folder in your DQMH Module that contains all the "non-framework", business logic VIs you add to the module after its creation. As Joerg said, definitely leave the names and locations of the boiler-plate framework-level DQMH VIs alone.

[ChrisFarmerWIS]

At Wired-in, we pretty much do what HSE does.

However one thing I'm taking out of this is to always create a class OR library for the non-stock DQMH files for each project (as opposed to a collection of separate sub VIs) - that way you're assured that all the files will be listed in the project. 

However, I don't always want to keep this library/class within the DQMH module library, because I may want to use that class outside of DQMH (rare but possible).

[Oberloewe]

Hi,

I want to share my experience...

I had a similar debate with Enrique from PantherLab last week. (https://github.com/PantherLAB/PantherDashboard/issues/28 )

I have been working with DQMH for about half a year now and really like this framework.

In my opinion there is room for improvement of the space-wasting library organization of the DQMH modules.

As soon as you work with several DQMH modules in one project, the file tree of the project becomes confusingly large.

From my experience as a module developer I do not need the auto-generated VIs very often compared with my business logic VIs.

I tried reorganizing things a bit with virtual folders, which worked at first glance.

• I created a virtual folder named "DQMH " and moved all the auto-generated VIs into it. Moreover I also created a virtual subfolder "User  Requests" in the "Requests" virtual folder where I placed all my events.
• I created a second virtual folder which contains all my business logic VIs (the VIs are also in a subfolder on disk). This is not auto-generated DQMH stuff.

This approach works even with the DQMH (6.1) scripting tools (I was able to generate events, rename events, etc).

The downside and finally the dealbreaker was the fact that neither the PantherLab Dashboard nor the Antidoc extensions can work with a change in the "virtual" project structure.

In the end, unfortunately, I reverted to the original DQMH project structure and created a folder (physical and virtual) for all my manually written business logic sub-VIs.

According to Jörg Hampels note (The DQMH Consortium and Delacor advocate leaving all files in the flat folder structure, not creating subfolders on disk but only organising files in the virtual folders of a .lvlib.), if I understand it correctly, it should be possible to change the organization of the .lvlib by using virtual sub folders as long as the physical structure is left unchanged.

---

[1984]

Working more and more with DQMH I get more and more convinced that there is a room for improvement about how the module specific files are be organized.

I couldn't resist and filed an idea: https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/Dedicated-place-for-user-created-requests-...

There could be better ways to achieve better readability, this is just one way to address the problem.

[1984]

My request got declined which is fine but I've found the argument ("no other users complain about that") pretty poor. I worked dozens of different places as a contractor and none of them used DQMH, which suggests that currently the userbase is relatively small. (Before this comment gets misunderstood I really hope that this would change cause personally I think DQMH is the best thing happened with LV in the past probably 10-13 years.)

With a relatively small userbase you get relatively few complaints about things that work but could be better as people more focusing on actual bugs.

The panther dashboard is great and all, but my current project has 17 modules and it takes 7 minutes to process all my modules everytime I launch it (or relaunchin, or restarting my PC, restarting Labview etc). That makes it pratically usable for me.

I still believe that the internal file structure could be a lot better and there is room for being more standardized. This includes naming conventions and more defined organization of the lvlibs.

[Enrique.Noe]

I really understand the issue about the time it takes for Panther Dashboard to scan a project.😭

This is because the scripting functions used internally, uses a lot of references to VIs and need to load these VIs in memory, a trick I have to decrease the Panther Dashboard scanning time is running the modules (the more the better), this makes them already in memory, thus the scan time decreases considerably.

Sincerely, 

Enrique.

[Darren]

---

---

@1984 wrote:

... my current project has 17 modules and it takes 7 minutes to process all my modules everytime I launch it (or relaunchin, or restarting my PC, restarting Labview etc). That makes it pratically usable for me.

---

Can you go into more details on this? What do you mean by "process all my modules"? 

[edit] Oh, I assume you mean the time it takes Panther Dashboard to load all the module info.