Question regarding Triggering multiple Measurements

[Kevin_Price]

Ok, bottom line, you're gonna really have your work cut out for you on this one.

With complicated switch sequencing at varying frequencies and duty cycles, I think there are maybe 3 general options.  I only have time to give you a very rough general outline.

1. Sync up a continuous capture of all voltages and all digital switch control signals.  Use a producer/consumer pattern to defer all the post-processing to a parallel loop.  Get really good at algorithms that are efficient in CPU *and* reuse of memory space.  You'll probably need to make use of multiple cores working in parallel.

2. Settle for "periodic inspection" of switch behavior rather than continuous monitoring.  At whatever rate you can *actually* handle, take a burst-like capture of switch behavior for a limited period of time, analyze and store the results, then iterate for the next burst.

   I'd advocate *trying* to transform the requirements in this direction if feasible.  Continuous monitoring at 1-10 MHz for two weeks is *daunting*.

3. Somewhat like #1, but with some significant added complexity in the DAQmx department.  It'd involve change detection, internal timing signals, and inside-out counter configurations.  All of which is aimed at using hardware to identify the switch time locations in the massive stream of data rather than depending on detecting them with software post-processing.

I'd say you should start by trying to collect 1 of the "bursts" mentioned in #2 above.  Even *that* won't be trivial, but it's a far sight more manageable than all the additional code infrastructure needed for continuous monitoring in #1 or #3.

-Kevin P

[Switcher_NXG]

Hello Henrik and Kevin,

thanks for you replies and comments.
The approach to keep it more like a "periodic inspection" seems resonable. I think i will start with this and see how small i can get the "periodic" and see if this will be "quasi continous" atleast for the timeconstants that something in the switching changes (which i have no reliable experience in).

Also the approach to have the trigger signals of all switches added (so one line) seems resonable (since only one is switching at the time). This may work as the trigger for all measurements.

One comment, i have 2xPXIe6386 available, so i will use on for the slope measurements (added driver signals as trigger) and one for the forward voltages measurements (another signal with a kind of "pretrigger-trigger").

I will use this thread if i made any progress.
Keep up the support! Thanks alot!

[Henrik_Volkers]

If your external switching controller can provide an additional 'common' trigger that would be the easy part.

If you have n individual lines for your n channels, you can use a hardware AND (IC or n caps, n+1 diodes maybe 1 to n+1 resistors ... have a hardware guy think of it 😉 ).

Maybe you can route all trigger lines to DIs and use change detection to trigger on all events ..

if you have a strict switching periode, (every 1 ms) you can check if your card and DAQmx allow a trigger delay, that enable a pretrigger by using the past pulse.

Sorry, I mainly work with NI-scope...

But if you look up NI-Help Supported properties by Device, (your Device)  you migth find under DAQmx Trigger Properties Start:More:Delay ..

Since my version here isn't the most recent I can't lookup your device ...