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

[John_Autotech]

Hello experts,
I have been at this for almost a year, part time. I've rewritten it several times from the ground up as I learned. Small samples are
It seems like this should be a standard large project for LabView, but I am having trouble tying it all together. I have been able to take the device examples from one of the manufacturers and collect data for a few days, which is great. Now, how can more be added? I'm hoping there is a thread or example stash with all the answers.

The scenario is an electrical test setup for LED drivers, with four or more pieces of test equipment (up to 21) that need to scan (take samples) at the same rate and time. The minimum is an AC source, two power meters, and a DC electronic load. All need to save data to a file. The data will be voltage, current, power, and power factor. There need to be 3 to 12 tests that will need to be configured for: AC voltage and frequency changes, timing on each test from 30 seconds to 15 days, and the fewest number of files that contain all the data. I don't have NI hardware, so that limits the express VI's too. Later stages may need a Oscope or power analyzer to catch transients on RMS load, a DC power source, and thermocouples.

The project can be broken down into more manageable chunks. Is there an example that covers basic LED driver testing? Would the Core 3 training cover it all?

*) The configuration could be different based on the sample, so I started with a case structure for that. Inside that are the controls and initialization for each device.
*) What seems like should be next is a producer-consumer loop, with the measurements in the producer loop, and screen and file updates in the consumer loop. I've heard clusters may be unstable for what I need.
*) At the exit of the consumer loop is the device close and error recovery.

1) Looking for information, I can find example of how to set up one device, but not how to tie each stage to several devices at once. Is it better to have all the inputs loose just inside the config case? Or should they all be in a yet another while loop to be sure they sample at the same rate and time? Device selection and scan rate need to be common to all user visible panels. The rest need to be individual for each device controls. Is just inside the config case right for these to?

2) With more devices, each control and input is on the front panel, making it crowded. Ideally, each manual control should have matching a front panel control. Adding tab control helps to organize, but are sub-panels the best way to clean up the users view? Is there a better way?

3) What is the best point to get data for an input queue? What is the best format for the data to be in the producer and consumer loops? Should all the data be converted to dynamic and merged, or is it better to build a 1d array from each device, then build a bigger array with all the data from all the devices? All into a 1d array, or a bundle for each device? Or should each device have its own queue, to better support parallel processing?

4) When the data gets to the producer loop, should it be combined into (or stay) in the same merged/array for similar devices, or everything split to the different devices? This seems to be where an action engine would be used. The consumer loop would take the data and

5)On the output to a file, all the data can be connected from the display to be converted to dynamic and merged into a Write To Measurement.VI tdms file. Should this VI be inside the consumer loop or just inside the config case structure?

I could post what I have now, but I am not filled with confidence on what i have.

Thanks in advance,

John

[AYanez]

Hi John. I think Subpanels are the most suitable to organize User Interface. You could have one VI per Device. I suggest one event structure as the producer and UI handler and another loop to the device listen the orders. An advantage of using Event Structures are that you can trigger events without user intercation with the help of "User Events", this could be the mechanism to trigger continuously acquisition with only one button. The best way to collect the data must be based on the requirements and speed of your devices.

I hope it helps.

[John_Autotech]

Hi AYanez. Thanks for the answer on 2). I hadn't thought of the event structure as a trigger for the whole test. Great idea!

Thanks,

John

[Gregory]

Hi John,

I cannot visualize your project, but it sounds like quite an undertaking! I would definitely stay away from dynamic data and Express VIs, they will only make it harder to debug and more of a pain when you reach the limit of their functionality and have to restructure your code anyway. I don't know who told you clusters are unstable, but that is not true. They have been in LabVIEW for as long as I know, and anything I code besides a little single VI sandbox uses them.

You mention you have a lot of equipment, is a lot of it the same type of device? If so, definitely look into the Delacor Queued Message Handler (DQMH) which allows you to make cloneable modules. That means you create the code to run a single device, then launch clones with a unique identifier, no duplication of code necessary. By nature these are known as "asynchronous" modules, meaning the execution time of module 1 is not related to the execution time of module 2. But you can use some techniques for "synchronous" messaging, which is well described in the DQMH literature, and will allow you to sweep one instrument while measuring on another. Keep in mind you are not using real-time hardware, so unless you have some kind of hardware triggers hooked up, the synchronization will have some kind of limit.

You mentioned having a loop to handle file writing and user interface updates. Actually, I'd recommend splitting this into two loops, as it is very handy to have a UI decoupled from the rest of your application. Definitely go through Core 3 online if you have the chance, as this will lead you through a sample problem that does just this.

It's ok to post your code now and get some critique even if it is not very polished, because there is no point in posting perfect code for critique 🙂

[John_Autotech]

Hi Gregory,

I'm in a transition from a design based on the devices to a design with producer-consumer, so all the controls are not organized in the new project yet. VI's for both old (old3) and new (PC_1) files are attached. If you can see past that to look at the base organization, you might see where I'm going. The Old3 used a different AC source, and since I was changing that, I looked more at the structure, and the new AC has not been completely wired in yet.

The only dynamic data in the latest (PC_1 for Producer Consumer try 1) file is what feeds into the write to file Express VI. The Old3 file has the devices organized, but not much beyond that.

I haven't heard of the Delacore QMH before. I have been looking at the included QMH for structure. The cloning idea sounds like it would help with the larger planned configurations, which will have many duplicated devices. For now the base configuration will just have the 4, with only one duplicated device.

I can slow the scan to once a minute if that gets the best synchronicity of the sweeps. The fastest it will likely need is 1 sweep/sec. If by module1/2 you mean like producer consumer, the consumer will just need to be able to save the data to a file fast enough to prevent a backlog. Slowing the scan rate can help with that too.

Thanks for the info about Core3. I have been holding back about the on-line because it seems like it would not be good to get questions in (that may just be what I've seen at other on-line training). And I am way to curious to sit on questions for too long.

Thanks,
John

[John_Autotech]

Hi all,

My code must be worse than I thought. I've run myself in so many circles, I know I'm just confusing myself.
How about one question on how to deal with the inputs and controls for the devices. The configuration will vary, so subpanels would be good. I'm not really sure how to get started with this. It seems the configuration selector would be an enum into a case structure, and then the subpanels would load inside that case. Or do i already have too many layers? Any examples on how to start this would be great!

Thanks,
John

[AYanez]

Hi John I think that the suggestion of Gregory is very good, the best approach before to use Delacor Queue Message Handler would be to take the Core 3 course. 

You can find a start point for subpanels in the examples of LabVIEW, search for the example: Multiple VIs in a Subpanel

You can start your development based on this example, for executable generation you will need to adapt it to load the VIs with the proper relative paths.

You could code one VI per device, to simplify the code once the test starts you could send a User Event to lock the controls in the VIs where you configure instruments for stimulation (Power supply for example) of this way you can view the settings but not change these.

One thing to have in mind when you code the application is to build it for expansion but in a level when other colleagues can help you, sometimes a CLA could use the actor framework to code the application but if the other members dont know this framework the maintenance and changes to it could will be hard and painful. So try to use familiar elements to build your application.

For data logging you need to get an overview of the sample rates of your instruments, most of NI DAQ can sample to a couple of KHz but a serial device cannot report measurements so fast, but you can always save 2 or more log files and taking advantage of the maximum sample rate of each instrument.

I hope it help you.

[AYanez]

I think the suggestion of Gregory is pretty good the best approach before to use Delacor QMH would be to take the Core 3 training course if you have the possibility.

To get a start point of subpanel usage you can search for the "Multiple VIs in a Subpanel" example, for executable generation you will need to include relative paths for the VIs but you can start the development with this.

You could code one VI per device, for which where you control instruments for stimulus like power supply you could lock the controls with the same user event to trigger acquisition, of this way you can view the configuration  but not changing it while the test is running.

Its important to remember that the sample rates for your instruments can be different, most of NI DAQ can sample at a couple of KHz but a serial device cannot report measurements so fast, but you always can generate 2 or more log files to taking advantage of the maximum sample rate for each device.

I hope it help you.

[John_Autotech]

Thanks AYanez,

All the suggestions from you both have been good. It's more my lack of how to get the very basics of the pattern so I can apply them that has me stumbling. This does get me started! Looking at scheduling Core 3 classes has been interesting.

Installed the Delacor files through VIPM. There are days worth of product videos and the examples look promising. This should be good for the multiples of a single device. I had been thinking to add all the same devices in one case with the number of devices, instead of a for loop with the number of devices. Which way would have more reliable data transfers and better control of the UI? The -1 on the stop is a great idea. I guess it will take more research to configure all the inputs and controls for the sets of each device. Following this paradigm, there should be a set of DQMH's for each device? I will give that a try.

In the standard consumer-producer, 1 VI per device did not exactly work. There seems to be a need for at least 2 VI's per. The first set would be the measurements, inputs, and controls for the device, while the 2nd would take the measurements to save into a file, and then on stop use a device close. The DQMH has these, with the cloned consumer loop broken into several parts too.

Are there structures multiple DQMH's would fit into, like an outer case? Or would the input "Number of DUTs" cover all the different types as well?

Thanks for all the help and pointers so far!
John

[Gregory]

---

@John_Autotech

Installed the Delacor files through VIPM. There are days worth of product videos and the examples look promising. This should be good for the multiples of a single device. I had been thinking to add all the same devices in one case with the number of devices, instead of a for loop with the number of devices. Which way would have more reliable data transfers and better control of the UI? The -1 on the stop is a great idea. I guess it will take more research to configure all the inputs and controls for the sets of each device. Following this paradigm, there should be a set of DQMH's for each device? I will give that a try.

Are there structures multiple DQMH's would fit into, like an outer case? Or would the input "Number of DUTs" cover all the different types as well?

---

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. 

As for "set of DQMH's for each device", I think there is a little bit of terminology to clear up. Delacor calls the queued message handler (QMH), along with all of the broadcast and request events (just a means to send data, similar to a queue) a module. And yes, you would want 1 module for each type of device. If you are using 5 similar power supplies, you could make 1 cloneable module for those. If you are using 1 XY Stage, you could make 1 singleton module for that.

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. 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.