Best way to create a large project to test an LED Driver

[John_Autotech]

---

@Gregory

---

Hi gregoryj,

I'm not exactly sure what you are getting at with "one case with the number of devices". If you mean a case structure with a case for 1 device, case for 2 devices, and so on, then yes, a for loop would be better if the number of devices is variable.
I had meant "one case with the number of types of devices", such as an AC source, power meter, and load. For 2 of the same meter type, the clone and module IDs would be ideal. Even the ranges would be be the same, so one singleton control would work for each type.

As for "set of DQMH's for each device", I think there is a little bit of terminology to clear up.
My apologies, I left out the word "type" again. The question with more detail should have been: For 4 Meters and 3 loads, would that be 2 separate sets of DQMHs, or could one include controls for both types? You answered that 2 are needed, one for each type. Then timing comes up again - can the event structure take a "user control" signal as input for both type of DQMH and the single AC source (or XY stage)?

For "structures multiple DQMHs would fit into", I am a little confused. Usually when I make a QMH, it is like an obedient butler for me, and goes to get data and reports it back if needed.

This sounds like it may be another step in the path to clarity. Am i trying to cram too much functionality into 1 vi? Do you mean the project has 1 DQMH.vi, and each device type would call that one vi as needed? I have been thinking if 3 device types need the support of DQMH, then there should be 3 DQMHs, each tailored to need of the device. Not too OOP, but the first step of the way I do code is to lay out all the functions that will be needed and clean them up in a later stage.

Then there is another module (could be a DQMH module, a simple state machine, or whatever you like) that is the brains of the operation, it will progress through the test, handle errors or unusual data, and so on. At the beginning of the application, or test, the brains module would launch all the other modules, and make sure everything is up and running before allowing a test to start.
The brains is a good place to narrow down. Something needs to trigger it. There needs to be one "Start test" button" for the trigger. That can be outside the tab control or before the start of the subpanel code. The Delacor input "Number of DUTs" in "Thermal Chamber Controller with Multiple DUT's.vi" seems to be the closest in logic. "Test Device Under Test_Clonable_DQMH API.vi" has a static VI Server Reference, which might be a higher level. Is there another outer control farther upstream? Which is the top level (brains) vi to start from in these examples? Is there one that is like Main.vi? My floundering research may turn up these answers, but maybe not.

Thanks again for all the help!
John

[Gregory · Accepted solution]

Hi John, glad you have had a chance to look at the DQMH examples. If you look in their "DQMH Fundamentals - Thermal Chamber" project, under modules, you will see a couple libraries. The one titled "Thermal Chamber Controller_DQMH" is a singleton (there's only 1) and the one titled "Device Under Test_Cloneable_DQMH" is a clone (there are 1 or more). Back at the top level you see a couple of examples. Any one of these is the example of the brains or controls that I mentioned, they each build in complexity, but are not meant to be run together. The most complex one titled "Thermal Chamber Controller with Multiple DUTs" shows you how to control the single thermal chamber as well as several DUTs at the same time, which you should be able to expand to your test bench with "4 meters and 3 loads".

You do want separate modules (aka DQMHs) for each type of device. This may seem like more work, but the DQMH toolkit comes with scripting tools, or if you make your own QMH template it is just copy and pasting to start a new module. The beauty of separating the devices is that they are not application specific. Once you create your module for interfacing with a power meter, you could pull that into your next project. The only application specific part is top-level brains, which suddenly become very simple and easy to read, because the module is made well and all the functionality is abstracted so you don't have to think about it after you've tested out your module 🙂

[John_Autotech]

Hi gregoryj,

This may have been the answer I've been looking for. Thanks for the details! DQMH is one of the most complex projects I've seen, with all the interconnections between VI's. Looks like I will be studying hard for the next while. If more questions come up, they should be quite different.

Thanks,
Johhn

[Gregory]

Hi John,

Sounds good! One word of warning when using any toolkit in your application, make sure to build your executable often! I was once using DQMH on my development computer with LV 2015, but the project was to run in the lab with LV 2013. When I tried to backsave the project to 2013, I got some errors because the toolkit could not be backsaved. I have since made my own template, the GQMH, so that I wouldn't run into this issue again.

[John_Autotech]

Good advice in any system. I've had issues in regular C++ builds, MS updated some obscure dll, and the project died. It took 7 people four days to track it down. 

For this, I planned to have an LED-QMH, to start with. But more of the training will need to come first. Unless you know an example with simpler modularity.

Thanks,

John