Question regarding Triggering multiple Measurements

[Switcher_NXG]

Hello Labview-Community!

I have a question regarding the triggering of multiple inputs with the DAQmx. I am struggling to find the right (best?) solution for my problem. And hopefully get some advices or ideas from more experienced labview users. This is my first labview project...(i did some courses and worked through most of the examples/lessons)

The (simplified) problem: i want to measure the the voltage slopes of 6 Hardware-switches over a long period of time (~2 weeks). These switches are controlled by a external microprozessor. The switching occures with 1 kHz (only one of the switches switch per time). I can get the digital switching signals (also used for the driver of the switches) of all switches as an input for my measurement system.

My first idea was to use the Digital Input of each switching signal as a trigger for 6 analog Input tasks, read the necessary samples and give it to (producer-consumer) my postprocessing (measure slope) and saving (tdms).

But i just recently figured out, that i can just use 1 Analog Input Task per time, hence one Trigger (please correct me if i am missing something).

The next idea is to read all 6 input channels all the time (dont use the digital switching signals at all), detect if a slope is happening, measure it and save it. This solution seems to use a lot of processor power and since the switching happens with 1 kHz i doubt that this is feasible.

I also did a small test programm to "measure" how slow the programm becomes if i start and stop an Analog Input Task with 1 kHz and i quickly run in hardware aquisiton problems (unable to keep up with hardware acquisiton), so this seems not like a feasible solution either.

If you have any comments which may help, or have questions to my explanation feel free to comment. I am gladfull for every help!

My setup:

I/O-Modul: PXIe-6386 (LINK)

Controller: PXIe-8821 (LINK)

Labview NXG 5.0

Best regards!

[Kevin_Price]

Exactly what do you mean about characterizing the "voltage slope of a switch" over a two week period?

Do you mean that you want to continuously acquire and save all (relevant) high-speed transient data throughout the two weeks?

Or do you want to do regular spot-checks of the high-speed transient data every 15 minutes or so (about 100 times a day...)?

Or are you looking for steady-state measurements *after* the transient ends?

Your device and the DAQmx driver are highly capable, but there are some significant constraints as well.  The most significant one is that the AI capture subsystem can only support 1 hardware-timed task at a time.  You cannot simultaneously have multiple AI tasks that each wait for their own unique trigger and each capture only the 1 channel of interest associated with that trigger.

The easiest solution will be if you only need to spot-check every 15 minutes or whatever in order to establish long-term trend info.  Then you *could* round-robin among multiple tasks, 1 at a time, each with their own trigger signal and only capturing 1 AI channel.

Other solutions are liable to get more involved, but your device is very capable and will probably allow it to at least be feasible.  The approach to take depends very much on what kind of data you really need to capture, and to some extent the kind of live processing you need to do on it.

I haven't taken the plunge into NXG at all yet, but I know it's still a work in progress in a number of significant ways.  I can't vouch for how well the things I know to be true in classic LabVIEW will carry over into NXG.  

-Kevin P

[Switcher_NXG]

Hello Kevin, thanks for your reply.

---

@Kevin_Price wrote:

Exactly what do you mean about characterizing the "voltage slope of a switch" over a two week period?

---

yeah, basically measure all slopes/gradients (so 1 value each in Voltage/time) of each switching (so 1000 a second). The programm should indicate if any of these is out of the defined limits. I have to think about the saving, probably it is the best to not save everything. But the program should measure all and be able to do something when one is out of the limits. (Background: This is for a lifetime-testbench for the switches, and if the limits are exceeded the data of the next switches is important for the test).

So to conclude, yeah the best would be to have all the time 6 channels measured all the time, without Stopping and starting each task all the time (since is not feasible 1000 times a second).
I tried to make a pause-trigger possible (not able to do atm, i also cant find much documentation for this), may this be a solution?

Thanks again for your help!

[Henrik_Volkers]

I would use one trigger and capture all 6 channels during the 12 ms (or 6ms?) cycle. total capture time maybe 500µs smaller to rearm the trigger ( if you need to capture all slopes)

No need to stop and start the task!  Just rearm the trigger.

depending on the SR used, this is a lot of data but prior to slope detection , you can cut out the time windows of interest before searching the slope. or even tell the driver to only fetch the data of interest and dump the rest (don't know how that would look in NXG ...)

Producer consumer architecture , if you need to capture all slopes during the 2 weeks,

think of multiple consumer loops for cutting, analysing, storing ... these things can go in parallel

and one loop for the UI .. avoid UI parts in time critical loops...

never tried but maybe you can configure the timers to create 6 (or 12) sample clock bursts  triggered by one input.

[Kevin_Price]

Is it feasible for your LabVIEW app and MIO device to be in control of the 1000 Hz switch control signals instead of a separate micro?   Then you could establish deterministic timing relationships between your actuations and your measurements and it seems to me that'd be a big help.   It'd be nice to know which channel was the relevant one for a given time interval rather than have to inspect and evaluate.

-Kevin P

[Switcher_NXG]

Hey, me again, thanks for your comments!

---

@Henrik_Volkers wrote:

I would use one trigger and capture all 6 channels during the 12 ms (or 6ms?) cycle. total capture time maybe 500µs smaller to rearm the trigger ( if you need to capture all slopes)

No need to stop and start the task!  Just rearm the trigger.

depending on the SR used, this is a lot of data but prior to slope detection

---

What do you mean be rearm the trigger, i could not find any infos for this. Is it something like this:

Start Stop Trigger, Labview ?

I was also not able to find the Meaning of SR.

---

Producer consumer architecture , if you need to capture all slopes during the 2 weeks,

think of multiple consumer loops for cutting, analysing, storing ... these things can go in parallel

and one loop for the UI .. avoid UI parts in time critical loops...

---

Thanks, that seems reasonable, will make sure this will be the case.

---

never tried but maybe you can configure the timers to create 6 (or 12) sample clock bursts  triggered by one input.

---

I am not exactly sure if i understand this suggestion right. The proposal is to work with this daqm-Timing Burst

and let the read function read all the time but just give the important files to my controller with this timing burst function? Is this similar to use the pause trigger?

---

@Kevin_Price wrote:

Is it feasible for your LabVIEW app and MIO device to be in control of the 1000 Hz switch control signals instead of a separate micro?   Then you could establish deterministic timing relationships between your actuations and your measurements and it seems to me that'd be a big help. 

---

Well technically this may be possible. But we would like to have that the measurement and the control system are separated. The timing is crucial for the switching (also some other more complex switching patterns will be created), also the control is in charge to read/control safety tasks for the whole testbench, and we have some safety concerns to let this happen on a windows device.

General question: do you recommend to switch now to an older Labview version? I was adviced to start with the newest labview (NXG) and did not thaught that much about it. But it seems that most(all?) further documentation/examples/forums are for the "classic" labview?

[Kevin_Price]

NXG is still "finding its wings."   I haven't personally checked it out, but from what I read here from other highly experienced LabVIEW programmers, it has both come a long way *AND* still has quite a few shortcomings.   Others may be able to give more details.

For the sake of support and to have access to a large body of in-depth knowledge and experience, I would very definitely recommend you do your project in LabVIEW "Classic".  Note: it'll be worthwhile learning NXG -- that's where we're all going eventually.  Just don't *RELY* on it yet.

(Unimportantly, I also strongly dislike much of the new "look" of the NXG.  I feel like a handyman being given a set of Fisher-Price plastic primary color tools.  When I look at the code, I feel insulted.)

-Kevin P

[Kevin_Price]

Can you describe your whole setup and measurement requirements in more detail?  Maybe it'll help to focus on just 1 switch at first.

1. Is this switch cycled at 1 kHz, where you both close and open it every msec?   What's the duty cycle?  (How much time closed and how much open?)

2. Do you need to collect data for every single switching event?  Both closing and opening?

3. For each switching event you capture, do you ever need any data from *just prior* to the switching control signal?  (I.E., do you need any "pretrigger" data?).

4. How many samples do you need to collect per switching event?   

5. Will you need to store all those samples as raw data?  Or do you only need to store the result of the analysis you do on those samples?

Very generally, it's pretty important to figure out early on how much you need to rely on precision-timed hardware signals to drive your acquisition.   Answers to #2 & #3 will go a long way toward figuring that out.

Have you worked out the implications of those answers?  For example, here's some rough order of magnitude estimates of what you might be facing if you store all the raw data: 

   For slope calcs, I would suppose 5-10 samples per switching event.  So that puts you in the neighborhood of a 10 kHz sample rate.  In 2 weeks, that adds up to 12 Giga-samples.  Waveforms use 8 byte DBLs for their samples, so that'd put you up to 100 GB.  And that's assuming you've already narrowed down to save only 1 channel of data per switching event.

Those are the kinds of implications that need to help drive early decisions about how much to capture and store.    Where's the point of diminishing returns?  Which side of that line are you on, and by how much?

-Kevin P

[Switcher_NXG]

Hello, thank you again for taking your time!

---

@Kevin_Price wrote:

Can you describe your whole setup and measurement requirements in more detail?  Maybe it'll help to focus on just 1 switch at first.

---

i will gladly do this. Attached (testbench.png) you can find the simplified circuit of the testbench. Basically its just one DC-Source and 6 switches, one at a time taking the current->making losses->getting warm->getting old->Dies.

The patterns are rather complicated (more then T1->T2->T3....) and are a degree of freedom to generate different patterns which burdes the switches differently. However since we programm them in our control MC they are known (the best would be that these are NOT known apriori to our measurement system, however we can easily get the driver signals of the switches (trigger)).

With the introduced inductances (Ls) there is also an Voltage introduced (Vce). So when one Switches goes OFF (and another one ON), the current commutates (Voltage over inductance) and the switch has to start blocking this voltage, this is how the voltage may look alike, in red is the signal from our control:

The slope (yellow) is for us a value to kind of detect the degradation of the switch.

---

1. Is this switch cycled at 1 kHz, where you both close and open it every msec?   What's the duty cycle?  (How much time closed and how much open?)

---

The duty cycles varies, so for example for 5 seconds its something about 90% and the next 5 seconds its 10% (this "simulates" a variance of the load for the switches). The same goes for the switching frequency. For example in the first 5 seconds T1 and T2 switches with 1kHz while T1 has 90% duty and T2 10%, then this happens for T3 and T4 and so on.

---

2. Do you need to collect data for every single switching event?  Both closing and opening?

---

Yeah, at the moment we would like to take data of every single switch event (if this is possible thou). The data can be very simple, something like a 0 or 1 (slope is in given limits, or slope is not in given limits). This is only needed for the closing.

---

3. For each switching event you capture, do you ever need any data from *just prior* to the switching control signal?  (I.E., do you need any "pretrigger" data?).

---

Actually yes, but i didnt want to get started with this. We wanted to measure the forward voltage aswell (on another channel, and clamped with another probe), since the blocking voltage is about 100 times the forward voltage). If this really makes a big problem we can get also a "pretrigger-trigger" from our control, which is just a trigger some time before the real trigger for the switches.

---

4. How many samples do you need to collect per switching event?   

---

My first approach would be to use 10MS/s, i expect the slope to be something around 50us, so this would be 500 samples (the maximum would be 100us).

---

5. Will you need to store all those samples as raw data?  Or do you only need to store the result of the analysis you do on those samples?

---

No i definitely dont want to save all the data. For most part a simple 0 (bad) or 1 (good) will be enough. However the programm should recognise if the limits are broken, and then should be able to save the way the data is saved, at the moment i asume that after some hours the test then will end.
So i am aware of the data problem we might run into and i think we have many ways to finetune this (save raw data->save calculated slopes->save numbers for different limits). But this is more a problem of the post processing, at the moment i am unsure how to "start" the measurement of the 6 channels and get the data to postprocess in time.

I am currently working on the Statemodel of the DAQmx Task Reference  and make a simple programm with this work in Labview 20.0.

---

---

---

[Henrik_Volkers]

---

@Switcher_NXG wrote:

Hello, thank you again for taking your time!

---

@Kevin_Price wrote:

Can you describe your whole setup and measurement requirements in more detail?  Maybe it'll help to focus on just 1 switch at first.

---

i will gladly do this. Attached (testbench.png) you can find the simplified circuit of the testbench. Basically its just one DC-Source and 6 switches, one at a time taking the current->making losses->getting warm->getting old->Dies.

The patterns are rather complicated (more then T1->T2->T3....) and are a degree of freedom to generate different patterns which burdes the switches differently. However since we programm them in our control MC they are known (the best would be that these are NOT known apriori to our measurement system, however we can easily get the driver signals of the switches (trigger)).

With the introduced inductances (Ls) there is also an Voltage introduced (Vce). So when one Switches goes OFF (and another one ON), the current commutates (Voltage over inductance) and the switch has to start blocking this voltage, this is how the voltage may look alike, in red is the signal from our control:

The slope (yellow) is for us a value to kind of detect the degradation of the switch.

---

1. Is this switch cycled at 1 kHz, where you both close and open it every msec?   What's the duty cycle?  (How much time closed and how much open?)

---

The duty cycles varies, so for example for 5 seconds its something about 90% and the next 5 seconds its 10% (this "simulates" a variance of the load for the switches). The same goes for the switching frequency. For example in the first 5 seconds T1 and T2 switches with 1kHz while T1 has 90% duty and T2 10%, then this happens for T3 and T4 and so on.

---

2. Do you need to collect data for every single switching event?  Both closing and opening?

---

Yeah, at the moment we would like to take data of every single switch event (if this is possible thou). The data can be very simple, something like a 0 or 1 (slope is in given limits, or slope is not in given limits). This is only needed for the closing.

---

3. For each switching event you capture, do you ever need any data from *just prior* to the switching control signal?  (I.E., do you need any "pretrigger" data?).

---

Actually yes, but i didnt want to get started with this. We wanted to measure the forward voltage aswell (on another channel, and clamped with another probe), since the blocking voltage is about 100 times the forward voltage). If this really makes a big problem we can get also a "pretrigger-trigger" from our control, which is just a trigger some time before the real trigger for the switches.

---

4. How many samples do you need to collect per switching event?   

---

My first approach would be to use 10MS/s, i expect the slope to be something around 50us, so this would be 500 samples (the maximum would be 100us).

---

5. Will you need to store all those samples as raw data?  Or do you only need to store the result of the analysis you do on those samples?

---

No i definitely dont want to save all the data. For most part a simple 0 (bad) or 1 (good) will be enough. However the programm should recognise if the limits are broken, and then should be able to save the way the data is saved, at the moment i asume that after some hours the test then will end.
So i am aware of the data problem we might run into and i think we have many ways to finetune this (save raw data->save calculated slopes->save numbers for different limits). But this is more a problem of the post processing, at the moment i am unsure how to "start" the measurement of the 6 channels and get the data to postprocess in time.

I am currently working on the Statemodel of the DAQmx Task Reference  and make a simple programm with this work in Labview 20.0.

---

---

---

---

Your MC that do the switching ...  if it can provide ONE (TTL) trigger  line with a pulse on each slope ... that line maybe can provide the pretrigger too?

The rest is finite aquisition ,10MHz,500-1k sample, PFI (DI) trigger,

When it comes to tighter timing ...  read about the VI-analyser , that tool helps you to find the time bottle necks