Does it make sense to write a DQMH instr. driver for this case?

[1984]

Hi,

So far I created 5-6 instrument driver using the DQMH framework so I decided to use DQMH for all my drivers to create consistency. Now the dilemma I'm facing is that if its worth doing it in DQMH for an instrument communicating thru VISA. The device I have to work with has ~40 commands, but at the end all commands are text in the <command>+" "+<parameter> format. So for me it doesnt make too much of a sense to create 40 requests when there is really only a "Send Command" request which should have a command and a parameter input and then I need to implement 40 VIs wrapping the send command request with different param inputs. So my DQMH driver practically has only 3 requests: open, send command and close everything else is done outside of the DQMH framework. I'm unsure if then the module makes sense at all.

I'm wondering what are the key decision making factors you consider when you decide to go (or to not go) with a DQMH module.

Thx!

[Enrique.Noe]

There is value in having each command separately, otherwise your user has to know the commands and parameter syntax to be able to use your driver, in this case creating a DQMH module has no value.

I think you should create a module and implement the commands individually, your end user just chooses the commands and does not have to see any documentation to generate the proper command.

[1984]

Thanks for responding! Yes, there is definitely a value in having 40 functions for the 40 different commands. I guess the main question is if there is really a value creating 40 different DQMH requests for each one of them when essentially they all use the same VISA write function. This solution would

1. encapsulates all instrument functions to the module which is GOOD
2. creates 40 almost identical requests and all their typedefs, events, different DQMH VIs etc which is BAD

Or should I create 40 different VIs wrapping the "send command" request. The user wouldn't need to know the commands themselves as they would be hardcoded to the wrapper VIs.

1. Keeps the DQMH module simple which is GOOD
2. creates 40 almost identical wrapper VIs which is OK

As I see a GOOD + BAD competes with a GOOD + OK which seems like an easy choice but I'd like to be sure I get inputs from others using DQMH to not miss anything.

Also if I go with the second solution its somewhat questionable if I really need a DQMH module as it does nothing but opens / closes the communication plus sends a command, each one of these has a single-VI solution on the VISA palette.

[Ludwig72]

I think there is nothing wrong with coming up with a suitable program structure. There is no requirement to implement everything in DQMH. You have weighed the pros and cons, so choose the structure that gives you the most advantages.

It is quite legitimate and often even the better way to use wrapper VIs or a wrapper class.

[drjdpowell]

I suggest you make a simple Driver, just a simple Class not based on any Framework.  Then make a DQMH module that uses the Driver to do some application-specific work.  Don't have 40 low-level DQMH requests, have 3-5 high-level requests that are useful.  Then for a different app just reuse the Driver in a different way.

Otherwise, you're just doing a Driver in a overcomplicated way.

[1984]

I'd like to doublecheck if I get you thoughts right. I guess you are suggesting that I shouldn't implement all the commands of the instrument in the DQMH module, but the ones I'll use in the upcoming project. (and maybe extend the functionality when it makes sense).

Did I get it right?

[joerg.hampel]

How do you envision using the driver module/class in your application? What would you like to see on the block diagram in the places your application actually uses the device?

In our HSE world, any physical device will most probably be implemented as a DQMH module.

• If the application needs to do 40 different things with the device, then the DQMH module API should offer those 40 requests - it models the API of the device after all. (*)
• If the application only needs 5 things from the device (but these 5 things involve the combination of 40 messages), then the module should only offer 5 requests.

In the latter case, I think there would be a class implementing those 40 things as separate methods, living on the shift register of the module.

(*) We have implemented modules in the past that have many wrapper VIs for a single request. I would not do that again, simply because it deviates from the standard framework and makes it harder to read and follow for less proficient and new team members.

[drjdpowell]

No, don't implement a subset of low-level driver commands; implement high-level application commands using possibly several low-level commands.

Edit: I think what Joerg is saying is consistent with what I'm saying.

[joerg.hampel]

---

@drjdpowell wrote:

Edit: I think what Joerg is saying is consistent with what I'm saying.

---

...and that doesn't happen every day 😘😉💜

[ChrisFarmerWIS]

I put together a presentation for this topic a couple of years back at VI Week.  You can read about it (and watch it) here: 8 Reasons for encapsulating your next LabVIEW device driver inside a DQMH® Module – Wired-In Softwar...