Wired-in Software

News

8 Reasons for encapsulating your next LabVIEW device driver inside a DQMH® Module

Abstract:

Do you hate it when a LabVIEW software application throws an awful error if a device is not connected, and it just stops or crashes as a result? Do you have multiple instances of the same device that you need to manage? Do you find that your applications get so cluttered with code specific to managing devices? Do you like to see what a device is up to “under the hood” whilst you run an automated sequence? If you’re facing any of these challenges, then we’re confident this presentation will help you! Using a DQMH module to encapsulate your next device driver will eliminate these issues. Watch the video below to learn how.

Why DQMH®?

At Wired-in we’ve been using DQMH®, a framework for the LabVIEW Development environment for almost 4 years now. We rely on it for almost all of our applications.

DQMH® gives us some real advantages. We use the framework to produce a higher quality product, our applications are more flexible, we can develop faster, and DQMH® promotes parallel development.

So what are the 8 Reasons for using it to encapsulate a Device driver?

 

1. Reason 1 – A DQMH® Module is an application in its own right

When you create a new DQMH® module, out of the box, you have created an application.

You can leverage good programming practices by using a DQMH® module to wrap up your device, and use the API Tester as the top-level VI of your application.

This is great for sharing with colleagues or customers to be used for testing or diagnostics.

2. Reason 2 – DQMH® is a great fit for creating a Hardware Abstraction Layer (HAL)

A HAL allows us to remove the device details from our application, resulting in a cleaner application. The DQMH module is a great mechanism for doing this.

Using a DQMH® module to wrap around a Class hierarchy of devices, you are hiding the user of your module from all of the business of class management.

It’s also a great starting point for applying OOP techniques in LabVIEW.

To get started, follow this excellent tutorial by Chris Roebuck.

3. Reason 3 – Got more than one instance of a device? No problem – use a cloneable DQMH® module!

This feature was one of the reasons I wanted to know more about DQMH® in the first place.

When creating new modules for a device module, create a cloneable module for your device (instead of a singleton) to enable multiple instances.

You create the module as if only one device exists, but simply launch multiple instances at run-time.

Ensure your sub-Vis are set to Shared Clone Reentrant.

4. Reason 4 – Keep your device management hidden away

When you create a DQMH® module, you can take care of the device management within the module itself, including:
– Regular polling of device to ensure it is still connected and functional
– Handle errors internally:
– Retry a reading if we get a timeout or corrupted data
   – If we get disconnected, try to reconnect and re-establish comms
– Log activity

The net benefit, is that it leaves you with a cleaner application, and a simpler interface to the device.

5. Reason 5 – Build intelligence and safety into your DQMH® module

Continuing on from Reason 4, we can also built intelligence and safety using DQMH®.  For example…

To Manage system safety, ie.
Motion control – Disallow motion of certain axes if “In Position” digital inputs are not set

Build-in intelligence , ie.
– Syringe Pumps – Manage a dispense where the requested dispense is greater than the syringe size.
– Analyse performance of device and self-tune – a good fit for Industrial 4.0

6. Reason 6 – Using DQMH®, you can prevent your application from being unusable if your device isn’t connected

Avoid a catastrophic error, by using a DQMH® module to allow graceful management of the issue.

Present the device’s status with a simple Boolean indicator. Red = No good. Green = Connected and ready.

Allow the user to learn more about what went wrong, whilst our application is still running.

Enhances the user experience!

 7. Reason 7 – View what your DQMH® module is doing in parallel to running your application

Monitor your device activity in parallel to running your application with a DQMH® module, using either the module front panel and/or the API Tester.

Use the DQMH® front panel to display things like:
– Device communication details
 – Log activity
 – Detailed status information

Use the API Tester to “sniff” the device driver activity. Use the Status Updated broadcast event regularly.

8. Reason 8 – Use templates as a common approach for your team

Create a Template based on your device driver approach and share it with your team.

Now everyone can write device drivers that follow your team’s preferred guidelines.

Promotes consistency across projects, and a is an effective code reuse strategy.

9. Reason 9 (Bonus) – Include simulation of your device inside the DQMH® module

Simulate your devices within your DQMH module. It is  great for offline testing.

Helps if you are maintaining software remotely, and doubles as a “sales” enabler.

 

What’s #VIWeek?

On 20 May 2020, and 21 May 2020, Wired-in Software were honoured to present at the very first #VIWeek.

#VIWeek was the LabVIEW community’s answer to NIWeek (the awesome annual conference held by National Instruments in Austin, Texas) having to cancel due to the COVID-19 pandemic.

The LabVIEW community rose to the occasion, and put on a pretty impressive week of webinars, all hosted from people’s lounge rooms.

We wanted to make sure there was something for the Australian timezone, so we jumped at the opportunity to present.

You can learn more about (and watch) the other impressive presentations here: https://labviewwiki.org/wiki/VIWeek

 

About Wired-in Software

Wired-in Software are located in Melbourne (Australia), an NI Alliance Partner, and a DQMH® Trusted Advisor that specialises in LabVIEW-based automated test and measurement applications, including systems that can do machine vision, monitoring and control, and embedded products.  We are focused on helping our customers transition to be Industry 4.0 ready, by building intelligence into our applications.  For more information, feel free to contact us for a no-obligation chat, or continue to peruse our website to learn more.