Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Oct 30, 2022
01:40 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
01:40 AM

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

Solved! Go to Solution.

1 ACCEPTED SOLUTION

Accepted Solutions

Oct 30, 2022
05:51 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
05:51 AM

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

Oct 30, 2022
05:01 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
05:01 AM

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.

Oct 30, 2022
05:51 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
05:51 AM

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.

Oct 30, 2022
11:15 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
11:15 AM

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

Oct 30, 2022
11:44 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
11:44 AM

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.

Oct 30, 2022
03:23 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
03:23 PM

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 😉

BTW, you know that "rev" is already predefined in Mathcad? Its defined as 2*pi or 2*pi*rad.

Oct 30, 2022
03:28 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Oct 30, 2022
03:28 PM

i just realized that the files i use the pwm controller in are all dimensionless, because the state space solver doesn't support units. so the forcing frequency is in rad/s and the number of cycles is 1rad rather than 1rev. so the file i posted with units isn't really even used.

thanks for the tips on hza and rev. i was just trying to get Hz to be rev/s so that it's clear to non mathcad users. if i were to put hza in there, it would just cause more questions. but i guess it's a mute point, since the important files have to be unitless. i'm glad i caught it though. for me cycles means revolutions. i only now realized that it's being interpreted as radians. it's a shame you can't use units with a lot of the solvers. i had to take a lot of time and make sure what the units actually were, so that i could compare to the FEA models i was checking.