Buck converter equations solving

[athurin]

Hi,

I have tried to solve a basic buck converter equations "in time domain", using functions (I am quite used to do it in a "discrete" way with fixed step solving). Unfortunately, the odesolve gives some very strange results. Thee current is suposed to go up and down in regular sawtooths going up or down according to the PWM function, but it looks like sometimes the solver skips some transitions, causing the current to jump in stupid ways.

I hoped using the odesolve would give me more resolution in the solution (possibly more than I can plot), but this doesn't help me in trusting the solver. Unless I did something wrong ?

Best regards

Adrien

[RichardJ · Accepted solution]

It doesn't like the non-smooth (in fact, discontinuous) function, because you have points where the derivative is undefined. Set the intervals for the ode solution to a "weird" number so that it avoids the points where the derivative is undefined. A different definition of PWM also seems to help.

[athurin]

Thanks for the example, I will spend some time studying it. Although I see that if I increase the time (and the number of points in the odesolve), the problem comes back. Does that mean that I can't solve the equations over a large timescale ?

Surprizingly, adding a very large number of intervals to the odesolve doesn't solve the issue. Even with many (>10) points per period, the solver is still "blind" to some of the PWM changes. This can't be explained by just points where the derivative is undefined, because even if something weird happens at 2 points over 10+ in the cycle, the other 8+ should be right, and not have a random slope.

Anyway, I was hoping that Mathcad would be capable of giving finding an analytical solution to the equations, not a numerical one. That would have given me almost infinite time resolution, which is precious in some cases : I have been solving this kind of systems with fixed step before, but when there are some high frequency parasitic phenomenons, fixed-step solutions may diverge if the step is not chosen carefully. Since I don't know in advance the frequency of the parasitics, it would have helped to have "infinite" resolution for solving, even if the plotting resolution was limited. Obviously, this is not going to happen. At least, with manual/fixed step solving, I know what is happening, and I have some control on what goes wrong and why.

By the way, does that mean that if I add parasitics (tiny capacitors to have non-instantaneous transitions), there are more chances that it will solve it properly ?

[RichardJ]

Thanks for the example, I will spend some time studying it. Although I see that if I increase the time (and the number of points in the odesolve), the problem comes back. Does that mean that I can't solve the equations over a large timescale ?

What do you mean by "large"? I just tried it to 1s and it worked OK.

Surprizingly, adding a very large number of intervals to the odesolve doesn't solve the issue. Even with many (>10) points per period, the solver is still "blind" to some of the PWM changes. This can't be explained by just points where the derivative is undefined, because even if something weird happens at 2 points over 10+ in the cycle, the other 8+ should be right, and not have a random slope.

I think that the way odesolve works, when you get a weird point the error propagates to all the following points. So the trick is not to use a large number of points, but rather a number of points that makes the solver skip all the discontinuities.

Anyway, I was hoping that Mathcad would be capable of giving finding an analytical solution to the equations, not a numerical one.

Unfortunately Mathcad's symbolic engine can't solve differential equations.

By the way, does that mean that if I add parasitics (tiny capacitors to have non-instantaneous transitions), there are more chances that it will solve it properly ?

It depends on how small they are. It's a numeric solver, so you would need to make them large enough that the solver doesn't see the transition as instantaneous. I don't know how large that would have to be,

[athurin]

Thanks, I will spend a bit of time studying that. I understand better how all that works now.

I will see how it goes on, but so far, it seems more hassle than working in discrete time, with arrays, as I usually do.

[RichardJ]

Actually, upon closer inspection you are right. I can't make it work for very long times. I guess sooner or later it hits a bad point, and fails, no matter what number of points are chosen.

[HarveyHensley]

Adrien,

You might be interested in this approach. It puts some curvature in corners of the step function and also eliminates the infinite slope at the transitions. For more about the cubic ramp function, see http://communities.ptc.com/docs/DOC-2947 and http://communities.ptc.com/community/mathcad/chemical_engineering/blog/2012/07/27/no-sharp-corners-allowed.

Do the results, especially I(t), look right?

Harvey

[athurin]

That looks absolutely great. Thank you very much !

[HarveyHensley]

I have cleaned up the worksheet. The square wave can be created directly with the SR function, thereby eliminating some steps. Also I removed the "t" range variable that you had because it is not needed and I think it is easily confused with the integration time variable.

[athurin]

This is going to be very helpful. Thanks !

[HarveyHensley]

Adrien,

Alan Stevens discovered that the Rkadapt routine worked for another square wave when using MC 15.http://communities.ptc.com/message/242222#242222

I went back to your original problem in Prime and applied Rkadapt to it and it seems to work fine. You have to remove the units in Rkadapt and some of the other ODE solvers in Prime. My worksheet is attached.

[athurin]

That looks great ! I will need to spend more time on it to understand how that works, but it seems to behave itself and that's great (and it looks reasonably easy to implement !)

Thanks a lot !