What is DQMH?

Delacor Queue Message Handler, is a LabVIEW Framework developed by Delacor with Fabiola de  la Cueva as a chief Architect, now DQMH has evolved and is being maintained by  DQMH Consortium.

In this blog I will talk about:

5 points on how DQMH can help you succeed on your LabVIEW projects.

1.- Scripting Tools

LabVIEW is a graphical programming language, it includes scripting tools, but, what is Scripting?, Scripting is code to create / modify code, what?, as weird as it may sound, scripting in LabVIEW is used to create custom user defined code, if you are interested on Scripting you can take a look the following links:

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/scripting_tutorial_intro/

https://dqmh.org/2016/12/15/5-steps-to-become-a-vi-scripting-ninja/

DQMH has tools to create modules and events to modules, all by using Scripting, there are 2 module types (Singleton and Cloneable), each module you create will have a purpose on your application, DQMH has the tools to create events for each module and there are 4 event types:

1. Request
2. Request and wait for Reply
3. Broadcast
4. Round Trip 

DQMH has tools to rename and delete events, if you create an event and then you need to change its name or even delete DQMH locate the specific piece of code an do all the work required using the magic of Scripting.

In addition DQMH has tools to do the following tasks:

1. Convert Events
2. Create Module Templates
3. Create Unit Tests for specific events
4. Module Validation
5. RT Tester creation

This is a quick DQMH demo, in this video I created a DQMH Module, added an event, etc. Hope you like it.

2.- Modularity

When you design your application using DQMH you should think with modularity in mind, break the problem into small problems is the best approach, we will be talking of an hypothetical example and we will analyze how DQMH can solve it with modularity in mind.

Example project description:

Let’s assume you need an application for quality control using Artificial vision, this is the hardware requirements:

1. Motors (3 at the beginning but maybe there will be more needed)
2. Cameras (2 we will be analyzing the product by 2 different optical paths)
3. PLC (Pneumatics and sensors controls).

This applications will be acquiring images of a product by 2 different angles to analyze more details, this images will be processed and analyzed to determine the product quality, this machine has 3 motors in charge of the product displacement and to fix its position to better image acquisition, this machine is also connected to a PLC in change of the pneumatics and some limit switch sensors, in general the machine inspects some products and keeps a record on a Database to keep track of the products quality over time.

When we start programming, sometimes we start with what I call “linear thinking”, we create a list of several steps to achieve some objective, with this “linear thinking” in mind I’m going to describe how it will look like:

• Read config
• Open motor COM Port 1
• Set Motor 1 parameters
• Open motor COM Port 2
• Set Motor 2 parameters
• Open COM port 3
• Set Motor 3 parameters
• Open Camera 1
• Set Camera 1 parameters
• Open Camera 2
• Set Camera 2 parameters
• …..

As you can tell, if we describe this application as a sequence of tasks, it will take us too much time to describe it, and the list will be gigantic, to think in this way will limit us and the code probably should look monolithic.

I enjoy to use analogies when I’m on teaching mode, analogies sometimes help me to explain complicated things on an easier way, so here is one of many I use, I like to visualize this problem as somewhat we see on some companies where there is a boss that micro manages all the staff, all the tasks when completed must be approved by the boss before letting the staff to start the following task, so if all the staff does their work there is one problem, there is only one boss, and the staff will found on a hard situation, there will be a huge bottle neck, so micro managing doesn’t help to have an efficient workflow, bosses should trust their employees and delegate responsibilities, I want to use this analogy but to describe code tasks, we should learn to delegate tasks or create code to solve an specific set of related tasks, this will allow us to do things in parallel to save time and optimize resources, the following image maybe helps to understand what I’m talking about.

Delegating responsibilities in software, help us to focus on one small problem at the time, we can draw a diagram describing a solution to a problem but not in a sequential way but on a delegating manner, we split all related task and describe them with their relationships with another tasks, in this image we can imagine all the boxes like the “staff” on a company, each box is one computational item with the capability to manage by itself on an specific context.

Well, this is great but, what about DQMH?.

DQMH allows us to create modules, we can then delegate some specific responsibility to each module, and the module will be in charge by itself to auto manage its state and data, then, when we use this module we can ask the module to do some work, without knowing details how the work is being done. Talking about using a module, DQMH framework there will be 2 roles, DQMH Module Developer and DQMH Module User, when we are developing a module we design the module specifics, what the module does, what kind of data the module needs, etc., but when we are the module users, we don’t really care the details, we just want the module to do the work, is something like an automobile, if you are using a vehicle, you don’t care what kind of oil is being used by the motor, you don’t care the measurements of the bolts and nuts on your back seats, you just want to drive, it is the same on DQMH.

Back to the problem, this design will have the following DQMH modules with specific tasks:

You may be probably wondering, Why do we have two DQMH module types? (Singleton and Cloneable), this is the next point.

 3.- Concurrency

Sometimes we will have identical proceses, following the same hypothetical project example, we have 3 motors or 2 cameras, but, what happens if these hardware elements are identical or with minor differences?, if we don’t have modularity in mind, we will ending up copy and pasting the exactly same code 2, 3 or N times, you probably say, a subVI will solve the problem, but, let me ask you something, what if when we are launching our application we don’t know the number of cameras or motors we will be using?, we can use the same subVI on several places, but, what if I want each instance of that subVI manage its state and data?, this is where things start to get complicated.

Fortunately for us, DQMH has the solution to this problem with cloneable modules, this specific module type uses something really interesting, reentrancy, which means, you only have one module with one single code base, but when you execute this code you can run any number of instances of the same code base, this is fantastic, this allows us to create drivers and anything that we can describe it as “we probably need more than one”, when talking about cloneable modules, we can launch a lot of instances and we can talk to each instance using the “Module ID”, DQMH Framework manages this Module ID, the DQMH Module User will only have to choose which Module ID wants to be talking to, or it can be the “Module ID=All” to talk to all the clones on memory.

Here is a small video showing a DQMH Module, 5 instances of the same module are launched, and then the Module ID=5 is stopped, then we are requesting all modules to stop.

4.- API Tester

All DQMH Modules comes with a VI called API Tester, this vi have an specific purpose, test the DQMH module, that’s it, while you are coding your DQMH module, the framework will encourage to update this VI when you are adding Events to the module, this VI will serve to test the module isolated for other modules, I think this is probably one of the greatest characteristics of DQMH, you can test your modules individually, so, if you are dealing with a large application with tons of modules, you can test each module by its own, for example using the project described before, you can test the motor module, start one motor, set its parameters, move it, etc., then, you can test the Motor Manager, this is a high level module so, probably in this context, it will launch 3 instances of Motor module, we will be setting parameters for 3 motors, move the motors on a more coordinated way, start movement, stop movement, etc. using this example, Motors Manager will be the user of Motor module.

Fabiola de la Cueva during my time working at Delacor told me the following sentence: “The API Tester is a living documentation of your DQMH Module”, “You only need to take a look at the API Tester Code to learn how to use the DQMH module”, this is so true, if you take a look at the block diagram of your API Tester you will realize there is the recipe on how to use the module, as the DQMH User you only need to understand the API Tester, this will tell you how to start the module, how to execute the event requests, how to listen to the module broadcast, everything is on the API Tester.

5.- Team collaboration, inherited code, uniformity 

DQMH allows us to create modular applications, we can delegate to several developers a large application and then in a coordinated way we can start building the complete application, for example, we can delegate the camera and motor modules creation to a couple of developers, each one will be focused on developing a module to manage the hardware, then after they finished this modules they can start working on Motors manager and Image processing, let’s think an application as a Lego building blocks where each block has a development time and then this module will be used by another module with high level of hierarchy, of course, we can start developing all the modules at the same time but this will cause us to loose some context, you have to be very careful planning your application, when I found myself in this situation I like to know the more details and then, start building modules, having a generic context of the complete application will help me to create better modules, another tip, always communicate with your team, you need to know what they are doing if that is important in your context, and you need to inform what are you doing if that will be used by other developers, communication is essential, trust me.

DQMH by nature enforces modularity, and the underlying scripting code will create a uniform and readable code, this is helpful because when you are reading some DQMH code, you know you have the API Tester to Test the module, the API Tester is a living documentation of your module, if you can test your module, see what it does, then using that module is easy, you just mimic what the API Tester does with the module.

What are your Thoughts?, will you consider using DQMH in your LabVIEW Applications?, I will love to help you, you can send an email to info@pantherlab.com.mx or you can schedule a meeting by clicking the next button, thanks for reading.