DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Naming of MHL case subVIs

Solved!
Go to solution

Hello!

 

I'm using DQMH 5.x for quite a while now and so far I'm pretty happy with it besides one thing. If you follow the "Simple Dos and Don'ts" you should create a subVI for each MHL case which I totally agree with.

Let's say we have a request called "Start Test". The scripting tools do most of the work creating the necessary files, EHL and MHL case and so on. If you now want to add the subVI for the MHL case and name it "Start Test.vi" (because this would be the most reasonable name for it) you can't do this because the VI for the request itself is already using this name.

 

What I do now is trying to find a suitable name for the subVI that is not totally off and still provides enough information so you can assume what the VI does. Wouldn't it be convenient if the automatically generated VIs would have some kind of suffix/ prefix like "Start Test - Request.vi" so we can use the event name for our own VIs and don't have to mess around with the file names?

I would love to know how you do this in your projects?

 

Best regards
Jens

0 Kudos
Message 1 of 9
(2,250 Views)

We would usually call them "Start Test--helper.vi" if nothing else comes to mind in terms of better naming...




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 2 of 9
(2,248 Views)
Solution
Accepted by topic author Jens_S

I've also used MHL - Start Test.vi. And all those subVIs go in an MHL virtual folder in the project so I can find them easily.

Message 3 of 9
(2,237 Views)

@Darren wrote:

I've also used MHL - Start Test.vi. And all those subVIs go in an MHL virtual folder in the project so I can find them easily.


Thanks, Darren - much better. We already put any VI that we create manually into a separate (virtual) folder, so that aligns pretty well with our current WoW.

 

Thinking about it now, I feel like this is more of a corner case for us: To have exactly one VI that does everything inside one MHL case.

 

 

 




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 4 of 9
(2,220 Views)

@joerg.hampel wrote:

 

Thinking about it now, I feel like this is more of a corner case for us: To have exactly one VI that does everything inside one MHL case.


I agree, it doesn't come up too often. I can only think of one module off-hand where I took this approach.

Message 5 of 9
(2,204 Views)

Thanks for your comments.

 

I like the idea with the naming even though I might stay with putting all the "custom" VIs in a separate virtual folder and arrange them in sub folders by function or something like this. Most times the subVI for the MHL case is just a "container" for all the other VIs that are often used in several different cases so putting them in a case specific virtual folder wouldn't be too useful.

0 Kudos
Message 6 of 9
(2,180 Views)

Hi Jens,

 

i always replace the cluster in the MHL by a class private for that module. This class provides a separate name space and allows to name the vi with public access scope to have to same name as the MHL case and the event. The class gets its own subfolder inside of the DQMH Folder structure where i put all vis belonging this class into.

 

best regards
Thomas

0 Kudos
Message 7 of 9
(2,126 Views)

@T.L. wrote:

Hi Jens,

 

i always replace the cluster in the MHL by a class private for that module. This class provides a separate name space and allows to name the vi with public access scope to have to same name as the MHL case and the event. The class gets its own subfolder inside of the DQMH Folder structure where i put all vis belonging this class into.

 

best regards
Thomas


You could also make the class part of the local data cluster and separate what is "GUI" or DQMH related to what is class-related. For example, updating the status on the front panel may be more GUI related and have nothing to do with the Device object in that module. I like to make that distinction. That also means I can share my classes with others who are not using DQMH. We also have used DQMH just as a tester for a class before we give the class to the customer.

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 8 of 9
(2,066 Views)

Hi Fab,

 

this is my typical approach:

 

I have a class for operating with my device. 

This Class is used by my worker DQMH modules internal private class. 

Finally I separate my UI by using MGI's DQMH Panel Manager (https://www.mooregoodideas.com/products/panel-manager/index.html) from my DQMH module operating with the device. This UI uses only public API and Broadcasts of worker module and some code needed for representation and controls handling. 

 

best regards

Thomas

0 Kudos
Message 9 of 9
(2,061 Views)