Please take a minute to review and accept our Terms of Use.
Welcome to the PLECS User Forum, where you can ask questions and receive answers from other members of the community.

Many technical questions regarding PLECS are answered on the Technical Solutions page of our website. Tutorial videos, specific application examples, and pre-recorded webinars are available on our YouTube page. Please follow us on LinkedIn for the latest Plexim news.

Glitch in Variable Phase PWM block?

0 votes
420 views
Hello all,

I'm using the Variable Phase PWM block to generate PWM signals for 2 full-bridges that are phase-shifted. Within each full-bridge, their half-bridges have 50% duty and are phase-shifted to create a zero vector modulation.

The problem is that I'm getting a leg short when the inner phase-shift of the full-bridge crosses 0.25. This can be seen in the picture below. I also attach a minimum reproduction of the behavior. The scope has an "error" channel that points out when the short happens.

Is this a bug? Or am I abusing the block in some way (I don't see how)?

Best regards,
asked Apr 5 by ThoseWhoWish2B (20 points)

1 Answer

0 votes
Hello all,

in the meantime I found a solution. When using the Variable Phase PWM block in vectorized mode (inputting a vector to it) I get the glitch, but it's fine if used as a scalar.

Luckily, I could get away with using one block and then inverting its output to drive the lower transistor since my duty cycle is fixed at 50%. Attached is a self-contained testbench using the workaround.

Still think it's worth it to look into it, the block seems to support vectorization when I look into its C-script...

Best regards,
answered Apr 6 by ThoseWhoWish2B (20 points)
Thanks for bringing the issue to our attention and for creating a representative model. In your original model you basically were generating a complementary signal by phase shifting the carrier another 50%. The approach in your revised model is a much better way to generate a complementary signal.

The glitch seems to happen when the sum of the two phase offsets is exactly 1.0 when the phase inputs are reloaded.  At this point the carrier on the second channel actually wraps back around and is exactly equal to the compare value. A quick skim through the code shows this should be handled but it might be a numerical precision issue. I will investigate further.
...