DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH module as the UI/front-end or separate non-DQMH "Main.vi"?

So I know the DQMH template project is arranged such that a non-module Main.vi is the actual UI/front-end, and it launches the DQMH modules and interacts with them similar to how the API testers do. Because of this, I assumed that the DQMH developers designed it with that paradigm in mind, thus my first few forays into DQMH followed the same path.

 

Later, I discovered the MGI panels flavor of DQMH. For this, the idea seems to be that the DQMH module itself is intended to be the front end, hence the easy ability to utilize the modules as subpanels.

 

I have found the MGI panel modules to be both helpful in a practical sense and also makes it easy to really take UX to a level that is somewhat rare in the LabVIEW world (let's be honest here, a LabVIEW app that is merely not offensive looking in 2022 is considered something of an accomplishment).

 

That said, I do find it sometimes annoying to have to do UI related things inside the DQMH module, and am thinking that maybe it would be better to revert back to a non-DQMH main.vi. As just one example of an "annoyance", many times I have a module that can both be called via it's API vi's and also operated via the front panel. I end up with duplicate EHL cases (one for the API that passes the wait notifier and wait for reply bool, and one for the actual button on the front panel... Both call the same MHL case). 

 

I guess I'm curious how others typically do it. Interactive front panel on the DQMH module or separate non-module vi?

0 Kudos
Message 1 of 8
(1,739 Views)

I make DQMH modules for my UIs. The project template uses a simple state machine for the top-level app to illustrate that if you want, you can easily use DQMH modules in a non-DQMH app.

Message 2 of 8
(1,733 Views)

We have approached this in a number of ways depending on the project.  I think there is no one best way for this.  It just depends on your requirements and how you team finds it easiest to solve these problems.

 

Some ideas:

1) We had an RT application where we the top layer module was effectively a message broker.  Instrument modules would sit below the message broker, and they would broadcast their data up to the message broker.  The message broker would then distribute the data to a number of different UI modules via Requests.  Any button pushes on the UI modules would generate a broadcast back up to the message broker module so that the message broker module could handle those event appropriately.  This approach was good in that you can test your UI modules independent of the rest of the application, but you need to constrain the amount of data moving around at any given time.

 

2) DQMH modules can be used as an Xcontrol alternative, or a complex control type.  For instance, if you have a special chart that has a lot of customised features (cursor management, plot appearance and colour, right click menus etc), then a DQMH module simply to manage the special chart is a good way to do this.  The benefits are that the UI can simply be the special chart, and can be displayed in another UI panel via a subpanel, the code specific to the special chart is all located in the DQMH module, abstracting this often complex and fiddly code away from the main application, and makes it much easier to test as its an isolated module.

 

3) For our instrument or device modules, we usually use the front panel of Main.vi to simply show what's going on with that device "under the hood" so that it can be used as a diagnostics panel for debugging purposes.

 

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Message 3 of 8
(1,716 Views)

We use DQMH modules for almost any UI needs we have. I have a strong opinion that the overhead of creating additional EHL cases is dwarfed by the overhead of inventing a separate architecture for those non-DQMH VIs/modules.

 

We have our own HSE Windows Application Template, a framework for applications with graphical user interfaces. It's a collection of generic modules and libraries which load the actual, project-specific DQMH modules dynamically from a configuration file. Feel free to take a look at it, it's open-source.




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)


Message 4 of 8
(1,695 Views)

I'm planning to use the JKI state machine template for the UI / main.vi  including a helper loop to handle the "live" data displays.  

0 Kudos
Message 5 of 8
(1,600 Views)

@breiter56 wrote:

I'm planning to use the JKI state machine template for the UI / main.vi  including a helper loop to handle the "live" data displays.  


I'd be interested to learn more about your ideas behind introducing a different framework for the UI / main.vi. What are your reasons for not going with just another DQMH module for the UI?




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 6 of 8
(1,579 Views)

The primary reason is to take advantage of the JKI state machine explorer to facilitate developing the business logic and the "flow" of user interaction.  Visibility (expand and collapse outline) navigation tools (Find Callers and Explore States) and macros look very helpful. 

The two frameworks seem to "play nice together" - It was quite easy to use the JKI scripting tools to add dynamic events. It even made a state for registering dynamic events. Using either framework required very similar LabVIEW knowledge.  

Another minor detail, the JKI state machine gives more room inside the case frames by default, to build code before hiding it in a sub-vi. 

 

All that said, my next step in learning and development is to integrate some helper loops before I'm fully committed. 

 

- Jared

 

 

Message 7 of 8
(1,570 Views)

This sounds like a great GDevcon or GLA Summit topic one day!  Making DQMH and JKI work together!

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Message 8 of 8
(1,562 Views)