Hello,
I am trying to implement and run a 3-level flying capacitor converter on a PLECS RT Box.
From my understanding, for accurate real-time simulation on the RT Box, it is preferable to use the PWM Capture block together with a power module that supports the Sub-cycle average configuration. The PWM Capture block outputs the averaged duty information over one model step, so I believe it should be connected to a compatible sub-cycle averaged power module rather than to a purely switched model.
However, when I checked the available Power Modules, I could not find the exact 3-level flying capacitor module that matches the converter I want to implement.
I also tried to build the circuit using half-bridge modules, but I ran into several issues, such as undefined Vdc-related errors and connection/modeling problems during code generation.
So I would like to ask:
What would be the recommended way to implement a 3-level flying capacitor converter for RT Box real-time simulation?
Is there a suitable sub-cycle average power module for this topology, or should I construct it using existing modules in a specific way?
If anyone has experience with flying capacitor converters, PWM Capture, or sub-cycle average models on RT Box, I would really appreciate any suggestions, examples, or possible workarounds.
I would really like to solve this issue, so any idea or discussion would be very helpful.
Thank you.
The screenshot you shared corresponds to the Flying Capacitor Half Bridge power module in the PLECS library. You will need to set the Number of capacitors setting to 2.
One aspect that can be tricky regarding the power module is the ordering of the gate signals in the vectorized implementation. See showing how the switches are oriented top-to-bottom for a 5-level flying capacitor converter:
multiplexed_flying_cap.plecs (35.9 KB)
The other point to note is the restriction of the power modules regarding the terminal connection requirements. From the documentation:
The DC side of the inverter bridge has current source behavior and must be connected to positively biased capacitors or voltage sources.
This means that you need to remove R2, R6, and R9 for the power module to work. If you need to model the ESRs (R2 and R9) and the RC time-constants are reasonable given the RT Box model step size, you can add a small capacitor Cf in parallel (RC || Cf) with the value of Cf determined to have a similar impedance profile as the RC branch.
Hello Bryan!
Thank you for providing the simulation file. I believe I now have a better understanding of the setup.
Based on my understanding, the capacitor count setting in the FCHB module seems to refer to the number of flying capacitors. In my topology, excluding the voltage-divider capacitors, there is only one flying capacitor. Therefore, I believe setting this value to 1 should be correct.
Also, the switching appears to be operating as intended. Thank you very much for your help.
However, after comparing the waveforms with the results from the Standalone mode, I became a bit confused and would like to ask a follow-up question.
I understand that the PWM Capture waveform may appear slightly distorted because it applies the average value over each step. However, the Vm6 and Vm8 waveforms look quite different from the Standalone waveforms. How should I interpret this difference?
I had also added a resonant stage and a transformer after the switching stage, which I already checked in my PLECS standalone mode. Although the PWM signals were generated correctly, the transformer input voltage waveform did not appear at all. For now, I have removed that part and am verifying the circuit step by step.
I would greatly appreciate any ideas or suggestions you may have.
Thank you again for your response and support!
Threelevelwaveform_checking_FCHB_RTbox_V02.plecs (56.0 KB)
Therefore, I believe setting this value to 1 should be correct.
You’re right - thanks for the correction.
How should I interpret this difference?
The sub-cycle average model couples the AC and DC sides with a one-step delay. The phase-currents and DC voltages reflected across the bridge are always one time step old. How much that matters depends entirely on how much the coupled currents at the phase terminal /voltages at the DC terminal can move in a single step.
For a resistive load the current is just the voltage divided by R with no dynamics of its own, so at a switching edge the output current changes the instant the voltage changes. The delayed coupling can’t see that jump until the next step, so for one full step the bridge is exchanging a value that is wrong.
With an inductive load the phase current can’t change instantaneously. The voltage step only changes the volt-seconds applied to the inductor, so the current changes proportionally to the applied volt seconds and inductance. The one-step-old value the bridge couples is never far from the true one.
So the real variables are the time constant’s of the input/output imepdance relative to the RT Box step. When the time constants are comfortably larger than the step, the coupled current changes slowly enough that the one-step delay is negligible. As the time constant shrinks toward the step size (or vanishes entirely, as with a pure resistor) the delay error grows, because the current is now changing significantly within the time delay interval across the bridge.
Attached is a simple model with a simulation script where you can see how setting the output inductance / resistance changes the load response.
This is worth checking against the resonant load in your setup: the values in your initialization commands put the time constant well below what a 2 µs step size can properly resolve.
Threelevelwaveform_checking_FCHB_RTbox_V02_bl.plecs (71.2 KB)
Hi Bryan!
Thank you for your model, which is really helpful to understand my working about RT Box and FCHB module as well. I really appreciate that.
And I faced problem with implementing high switching frequency around 500kHz, what I’m trying to do is that the topology itself is not typical one. so what i’m getting so far is I can’t use the nano step model, I mean the nano model is only for the typical topology, which is provided from the PLECS block. So I should made my model myself using Sub-cycle average model.
So I’m trying to make as like this (the task2 part is going to be used to Transformer), and also I realized the RT box 3 or 1 whatever the maximum sample time is 1e-6, so I scaled down my design like 500kHz → 50kHz. but even 2e-6 is not working in my model using RT box 1.
But we have a RT box 3 so I assigned three task to each CPU. and then finally run at 2e-6 sample time. but still not working at 1e-6 sample time due to the overrun limit(even overrun limit 300000 was not working).
Overrun
but when I use sample time like this,
the CPU core looks like this.
So my problem at this point is that even my Task 0 is only caputure 50kHz PWM at 2e-6 sample time, the Core 1 looks really hard to manage. Is there any proper way to implement my working? like making sample time 1e-6 without overrun error or something… It would be really great if I could get some experience about how to properly use RT box for not typical DCDC topology at high frequency. Thank you for reading my long explanation!
So far my progression is good due to your advice and explanation! I just want to make more properly, thank you, have a good day!
FCCLRC_RTbox(CPU123_inquiry).plecs (39.4 KB)
If you have access to an RT Box 3 you should use the FlexArray solver in conjunction with the sub-cyle average modules instead of trying to split up the model onto different CPU cores. The resulting FPGA step size will be much smaller than the reduction you can achieve on the CPU.
Thank you for your advice. The results look much better with FlexArray, and I appreciate you pointing me to this feature.
I still have one question about the timing of the PWM Capture signal.
From my understanding, the analog output waveform is updated at the FlexArray step size, so the analog output accurately reflects the FPGA solver timing. However, when I observe the PWM Capture signal configured as “Sub-cycle average,” the waveform still appears to update at the CPU discretization step, which is 2.5 µs.
(I used just demo of FlexArray and used the Analog Out block to check the PWM Capture
Does this mean that the PWM Capture output is updated at the CPU step, even though the electrical circuit is running on FlexArray? Or is the PWM Capture actually processed on the FPGA/FlexArray side, and I am only seeing a CPU-step-rate signal because of how it is being monitored or routed to the scope?
I thought PWM Capture was also handled by FlexArray, so I would like to confirm whether my understanding is correct.
Thank you!
At the moment the signals that are displayed in the scope in External Mode are only updated with the CPU step rate. This is something we want to address in a future TSP release.
For the FlexArray simulation, the PWM Capture blocks operate at the FlexArray step size, so this is independent of the display in the scopes.
Thank you for your reply.
I just want to make sure I understand correctly. The waveform I measured above was not from the External Mode Scope, but from the physical Analog Out signal using an oscilloscope. As shown in the screenshot, I connected the Analog Out block to the PWM Capture block.
If the PWM Capture block operates at the FlexArray step size, and the Analog Out update period is also equal to the FlexArray step size, shouldn’t the physical Analog Out signal reflect the FlexArray-rate updates?
I was a bit confused because the CPU step still seems to appear even when measuring the physical Analog Out signal. I would really appreciate any clarification you can provide.
Sorry, I missed that part.
However, for the FlexArray solver only operates on electrical models and only the PWM Capture blocks that are fed to gate signals in these models operate with the FlexArray step size. If a PWM block is directly connected to an AnalogOut block, the code for the resulting connection is processed on the CPU, so the AnalogOut block is only updated with the CPU step size.
