cancel
Showing results for
Did you mean:
cancel
Showing results for
Did you mean:

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

15-Moonstone

## PWM Controller Issue

Hi,

People here on the forum helped me define a PWM controller, in the past. I made a tweak to that formula, so that it starts at zero. However, I've noticed there is a weird issue with Mathcad. If you look at two cycles, it will be off when it should still be on. This happens on the second cycle. It turns off one time step too soon. However, it's random and depends on the duty cycle entered. I'm wondering if there is another way to define this, so that this issue can be avoided.

I've messed around with it as much as I can but have reached a dead end.

Thanks,

Anthony

1 ACCEPTED SOLUTION

Accepted Solutions
24-Ruby V
(To:Werner_E)

Ah, I see now. And now I am wondering why you posted a sheet with a value of d where the issue is NOT showing up!??

I set the duty cycle d to 35% and I get this:

The function returns 0 while its supposed to return 1.

Reason is that you experience simple rounding errors. These are common when dealing numerically in a computer program and cannot be avoided. An often seen example is shown below, showing that even just the order a calculation is done can make a difference:

When we let Mathcad show the max of 17 decimals we see whats going on.

The values of tc and tc(1+d) seem to be exact 1 s and 1.35 s,

but decimal numbers like these most of the times cannot be stored exactly in binary representation and when you use them for any calculations the round-off errors may show up in the results as can be seen here:

Even simple and obvious calculations can yield unexpected rounding errors:

Thats the reason why in programming its a rule not to ask if a value is exactly zero but rather if its approximately zero (if |value|<10^-12 or the like).

If that effect is a severe issue in your application, you might add a small number like this:

Another option can be to round every numbers involved down to a certain precision.

I found that all it needs it to round tc down to nanoseconds (use the "Round" function with an upper case "R" to do so)

This at least solves the problem for d=35% and the second cycle. No guarantee that it will also work for the fifth cycle or for other values of d.  It may be necessary to round down ALL involved numbers. E.g. I found that when I still use d=35% but use picoseconds instead of nanoseconds he problem persists. So it might be a better idea to round down all numbers used in the function and no the number stored on worksheet level.

(it should not be necessary to define tc rounded down as shown before)

I guess picoseconds may be to small as some round-off errors might be larger. You have to find a value which is a good compromise between accuracy of results and elimination of round-off and conversion errors.

There sure are other ways to define a pulse (using the Heaviside function or using the if-function instead of the boolean expression) and to make it periodic you could replace the mod(a,b) function by a-b*trunc(a/b), but rounding errors can happen no matter what kind of calculation expression you are using.

6 REPLIES 6
24-Ruby V
(To:prop_design)

I wonder what you think is wrong in the file you posted. Your function returns 1 for every positive multiple of 0.5 s and thats the way you defined your function. I am not sure what you mean by the "function turning off one time step too soon in the second cycle".

Here is your "check" as I see it when i open your file. Do you experience different results?

BTW, Mathcads definition of Hz is not wrong, its just not the one you are used to. Thats the reason Mathcad also provides a unit Hza.

24-Ruby V
(To:Werner_E)

Ah, I see now. And now I am wondering why you posted a sheet with a value of d where the issue is NOT showing up!??

I set the duty cycle d to 35% and I get this:

The function returns 0 while its supposed to return 1.

Reason is that you experience simple rounding errors. These are common when dealing numerically in a computer program and cannot be avoided. An often seen example is shown below, showing that even just the order a calculation is done can make a difference:

When we let Mathcad show the max of 17 decimals we see whats going on.

The values of tc and tc(1+d) seem to be exact 1 s and 1.35 s,

but decimal numbers like these most of the times cannot be stored exactly in binary representation and when you use them for any calculations the round-off errors may show up in the results as can be seen here:

Even simple and obvious calculations can yield unexpected rounding errors:

Thats the reason why in programming its a rule not to ask if a value is exactly zero but rather if its approximately zero (if |value|<10^-12 or the like).

If that effect is a severe issue in your application, you might add a small number like this:

Another option can be to round every numbers involved down to a certain precision.

I found that all it needs it to round tc down to nanoseconds (use the "Round" function with an upper case "R" to do so)

This at least solves the problem for d=35% and the second cycle. No guarantee that it will also work for the fifth cycle or for other values of d.  It may be necessary to round down ALL involved numbers. E.g. I found that when I still use d=35% but use picoseconds instead of nanoseconds he problem persists. So it might be a better idea to round down all numbers used in the function and no the number stored on worksheet level.

(it should not be necessary to define tc rounded down as shown before)

I guess picoseconds may be to small as some round-off errors might be larger. You have to find a value which is a good compromise between accuracy of results and elimination of round-off and conversion errors.

There sure are other ways to define a pulse (using the Heaviside function or using the if-function instead of the boolean expression) and to make it periodic you could replace the mod(a,b) function by a-b*trunc(a/b), but rounding errors can happen no matter what kind of calculation expression you are using.

15-Moonstone
(To:Werner_E)

thanks werner,

i used your method of adding a tolerance to tc. it seems to work as expected now. sorry to have confused you with the original post. you had to run various duty cycles to see the problem. so i didn't think it would matter how i saved it.

anthony

15-Moonstone
(To:prop_design)

attached is the updated version. sorry that units of Hz is controversial apparently. in my field Hz is always rev/s. So no offense is meant. When I say Mathcad is wrong, I mean it's wrong for my field of work.

24-Ruby V
(To:prop_design)

Discussions about Hz vs Hza, rev=1 vs rev=2 pi. rad being a unit or just number 1, etc. go way back to the beginning of Mathcad.
Obviously its not possible to make all people equally happy at the same time 😉