Last fall, I had the honor of presenting at GDevCon#1, the first independent graphical programming conference. GDevCon#1 took place in Cambridge, UK (September 4th-5th, 2018). GDevCon was an excellent conference, so make sure you go to their website and buy your tickets for GDevCon#2. Last time the first round of tickets sold out in one day and they had to find a bigger venue! One of the multiple great things the organizers did was to get professional recordings of our presentations. Below is the recording of this presentation (thanks to GDevCon team and their sponsors for this perk).
The bit.ly/fabGDevConDQMH takes you back to this post.
The first part of the presentation is very similar to the presentation I gave at NI week 2018. The bit.ly/fabNIWeek2018DQMH takes you to that presentation’s post. However, this time, I focused more on the planning stages for a DQMH project and how to share DQMH modules within a DQMH Project. I included some additional tools our customers, DQMH Trusted Advisors and our team use when planning a new DQMH project. Also, as a result of the NI Week presentation and the one at GDevCon, we decided to include the DQMH version of the Continous and Measurement Logging sample project as part of DQMH 4.1. The following sections explain how we went about creating the CML DQMH sample project.
Planning a new DQMH based project
Rather than repeating what we already discussed at bit.ly/fabNIWeek2018DQMH, let us highlight the differences. First, we realized that calling the request “Start Logging” was misleading and we renamed it as “Initialize File” which is more indicative of what the Logger module is actually doing.
Notice that the DQMH request events use the imperative form for their names, while the DQMH broadcast events use the past tense. This little tip makes it easier to model, discuss and implement your DQMH modules.
Wired-in Software, one of the DQMH Trusted Advisors, shared with us another type of table that helps them visualize DQMH event communication between modules as well as any possible circular dependencies.
As you can see, there are different ways to model and visualize the DQMH events and the communication between DQMH modules. You can try out the sequence diagrams and diagrams discussed at bit.ly/fabNIWeek2018DQMH or the tables discussed above. Maybe you will come up with your own way of modeling your DQMH modules and their relationships, the takeaway here is to take the time to discuss with your team the public API for your DQMH modules before starting to code. Even with all the DQMH scripting tools, it is still easier to delete a row on a table or move the contents to a different cell than modify existing code.
Sharing DQMH Modules
Option 1: Templates
Via Project Templates
You have probably seen the DQMH project template that ships with the toolkit. You can create a new project based on that template via Getting Started Window>>Create Project>>Delacor QMH. We have included with the toolkit a document indicating how we created this project template. You can go to the same NI page we went to and even use our project template as an example to create your own. The instructions are at <LabVIEW>\ProjectTemplates\Source\Delacor\Delacor QMH\README.txt
Some examples of the DQMH Project templates we have created for internal use at Delacor are
- DQMH Configuration Editor
- Editor Framework DQMH (singleton)
- Page DQMH (Cloneable)
- File class
- Configuration template libraries
- DQMH Test Sequencer
- Sequencer (singleton)
- Logger (singleton)
- Configuration Framework
Both projects include more than one DQMH module and each project will need to be customized for new projects. At Delacor, when we get hired to create a project that is very similar to a project we have built before, we don’t just go and save a copy of the previous project and modify it to match the current project. Instead, we save a copy, remove all the things that are unique to the previous project, create a project template, package it into its own VIPM package and start the new project form the project template. We create a repository for that project template, its own bug tracking project and track time for it as if it was a product. This has helped us create a library of templates that we rely on for new projects. As we find improvements or bugs, we file them against the template and future projects benefit from the improvements.
As mentioned earlier, another example of a project template that you can explore is the DQMH CML sample project template that ships with DQMH 4.1.
Via DQMH Module Templates
If you only want to reuse a DQMH module and do not need to create a full project template, you can create your own DMQH module template. Your DQMH module template can include support libraries and classes, as long as they are saved in the same directory as your DQMH module, they will be added as part of the DQMH module template. DQMH 4.2 and later simplifies a lot the steps to create a new DQMH module template.
Some examples of DQMH Module Templates we have created for internal use at Delacor are
- Serial Manager (Cloneable)
- Delacor Test Sequencer Test
- Database Logger
- ROI Overlay module
An example of a DQMH Module Template shared with the community
Option 2: Share as Reusable Code
We mentioned in the DQMH Module Template section above that the source code for the DQMH module template doesn’t need to be in LabVIEW Data, the source code can be in a relative path to the project. A way to address this is to use sub-repositories (or submodules or SVN externals). Your new project is in its own repository and as part of the folders in this new repository, it has a folder that is itself linked to another repository. I don’t show that in this post. If this is something you would like for us to explore in future blog posts, let us know via the comments.
If you are going to reuse a DQMH module as-is in multiple repositories, then you can have that DQMH module be in its own repository and have the project repository load it as a submodule. You can clone or download the example at github.com/DelacorLLC/GDevCon1_CML-DQMH.git and follow along with the demonstration video below where I show you how to add the Acquisition DQMH module as a subrepository of Libraries, which it is in itself a subrepository of CML-DQMH repository.
The video below shows what it looks like to clone a repository that has sub-repositories. Note how the sub-repositories are specified at a specific revision. This means the repositories themselves can be at a different revision than the one the main repository is pointing to. Also, note how the name of the repository can have a different name than the folder you clone it to.
If you would like for us to discuss how to do the same with Mercurial (Hg) or SVN, let us know via the comments and we will cover this in a future blog post.
Via Package DQMH Module via JKI VIPM
The same code above is built using packages, where each DQMH module is saved in its own submodule (or subrepository) and built into packages. The calling code calls the PACKAGED code, not the original code.
You can find an example at github.com/DelacorLLC/GDevCon1_VIPMDemo
Package DQMH Module as PPL
Matthias Baudot from StudioBods, another DQMH Trusted Advisor, created a video that illustrates the steps to package a DQMH module into a PPL. He presented about this and a lot more about PPLs during his presentation at NI Week 2018 called Use PPLs to Build and Deploy Large, Scalable Applications and Get a Head Start on GLLs in LabVIEW NXG. The video below starts at the point (37:05) where he showed this demonstration.
You can find an example at github.com/DelacorLLC/GDevCon1_PPLDemo
Building a DQMH based Project into an EXE
The DQMH CML Sample Project Template ships with DQMH 4.1 and later. You can create a copy of this project by going to Getting Started >> Create Project >> Sample Projects>> CML DQMH. One additional improvement we made, after the presentations at NI Week and at GDevCon, was to make the launcher automatically configured to run transparently when in exe and show its front panel when in dev mode or running with the debug command line argument.