Percentage Error
TC
Posts: 1,019
Hello all,
I was thinking today about my reflow oven, the PID takes a error value does what it has to do, and outputs a value. But that value is being "clipped" because my PWM has a scale of 0 to 1000 (0% to 100.0%)
So I did some research and found percent error. I figured that would be great to use. Why not start with a percentage, and end with a percentage.
What I currently have for calculating the error
What I would like to use
But wouldn't you know it, I hit a snag. The equation returns a floating point number, I am trying not to use floating point. So my question is, Does anyone know how I can do percentage error without floating point?
Thanks
TC
P.S. all my values are scaled up by 1000. Examples;
0.001 * 1000 = 1
100 * 1000 = 100,000
1.234 * 1000 = 1234
I was thinking today about my reflow oven, the PID takes a error value does what it has to do, and outputs a value. But that value is being "clipped" because my PWM has a scale of 0 to 1000 (0% to 100.0%)
ControlValue[idx] := (((Pterm[idx] + Iterm[idx] + Dterm[idx]) + long[TempPtr][Bias]) / 100 ) #>0 <#1000
So I did some research and found percent error. I figured that would be great to use. Why not start with a percentage, and end with a percentage.
What I currently have for calculating the error
error[idx] := set[idx] - current[idx]
What I would like to use
error[idx] := ((set[idx] - current[idx]) / set[idx]) * 100
But wouldn't you know it, I hit a snag. The equation returns a floating point number, I am trying not to use floating point. So my question is, Does anyone know how I can do percentage error without floating point?
Thanks
TC
P.S. all my values are scaled up by 1000. Examples;
0.001 * 1000 = 1
100 * 1000 = 100,000
1.234 * 1000 = 1234
Comments
What is the highest value above the decimal point that you have?
If it it's 15bit why not scale them all up by 65536 instead (<<16)
Then the lowest bit represents 0.000015
Well if 1 = 1,000 then 100 = 100,000
The problem is not the value limit. the problem I am having is dealing with the integers. Lets say I set the oven to 50C and the oven is currently at 20C, Using a calculator
((50 - 20) / 50) * 100 = 60%
Everything is setup and done to accept the scaling. The PID refreshes every second (because I wanted it to, and I am happy with how it handles it), the PWM counts from 0 to 1000, and if the Control Value is => the PWM counter, the output is turned on. Each cycle of the PWM is 1ms. So lets see, if I scaled up the values more, I could be pushing it that the prop miss the counter and have to wait over 50 seconds for the counter to come back.
yes, I have a anti-windup in place set to 100%
t := cnt repeat repeat idx from upper to lower current[idx] := 0 error[idx] := 0 Pterm[idx] := 0 Dterm[idx] := 0 ControlValue[idx] := 0 repeat idx from Upper to Lower current[idx] := (long[TempPtr][idx] ~>(32-12)) * ScaleFactor 'Get current temperature from parent object if current[idx] == 0 current[idx] := set[idx] error[idx] := set[idx] - current[idx] 'error[idx] := ((set[idx] - current[idx]) / set[idx]) * 100 'percentage error Pterm[idx] := (long[TempPtr][Pgain] * error[idx]) / ScaleFactor Iterm[idx] := ((long[TempPtr][Igain] * error[idx]) + Iterm[idx]) / ScaleFactor #>0 <#(100 * ScaleFactor) Dterm[idx] := (long[TempPtr][Dgain] * (current[idx] - LastError[idx])) / ScaleFactor LastError[idx] := current[idx] ControlValue[idx] := (((Pterm[idx] + Iterm[idx] + Dterm[idx]) + long[TempPtr][Bias]) / 100 ) #>0 <#1000 repeat PWM_counter from 0 to 1000 outa[EnablePin] := 0 'Pulse enable output so missing pulse detector can start. If ther is no pulse, heaters can not be contorled outa[EnablePin] := 1 if ControlValue[Upper] => PWM_counter AND ControlValue[Upper] <> 0 AND ControlValue[Lower] => PWM_counter AND ControlValue[Lower] <> 0 outa[UpperPin] := 1 outa[LowerPin] := 1 elseif ControlValue[Upper] => PWM_counter AND ControlValue[Lower] < PWM_counter outa[UpperPin] := 1 outa[LowerPin] := 0 elseif ControlValue[Upper] < PWM_counter AND ControlValue[Lower] => PWM_counter outa[UpperPin] := 0 outa[LowerPin] := 1 else outa[UpperPin] := 0 outa[LowerPin] := 0 waitcnt(t += (clkfreq/1000))Or that you want to use % for pwm value, same problem there as integers can not do odd number fractions without many decimal points.
As you are controlling a heating element, cycle length can be very long so time is on your side.
When you use 1/1000 duty does rounding error really matter temperature vise?, or is it the principal of the thing?
When it comes to computers 10/100/1000 are not good numbers, so try to base everything on 16/128/1024 instead.
So the trick is that you don't add 1 every cycle up to 1000, but 9-to-11 up to 10'000 instead as that gives you better granularity.
If you make everything <<16, the granularity is very prices.
if that still creates errors., then it's Bresenham's Algorithm:
http://www.romanblack.com/one_sec.htm
This is not for "displaying' a percentage error. This is for "calculating" the percentage error of the set temperature, and the current temperature. As I said in my first post, "the PID takes a error value"
I have added a substantial amount of insulation to this oven. Starting at around 25°C (77°F) it will take the oven a little less than a 1 minute to get to 250°C(482°F) with both heaters on. So the cycle length has to be fast to keep up with the oven. Plus at 1 second cycles, the PID is happier and the oven is able to regulate its self A LOT better than say a 5 or 10 second cycle. I know, because I tried them.
Still a newbe with calculating time, so I could be wrong. Give you a couple constants. CLKFREQ := 80_000_000 (cant overclock), PWM cycle must be 1 second (no options, not going to change it), and one cycle counts 0 to 65535.
80 million cycles / 65536 (don't forget "0") = 1220.703125 clock cycles per count of the PWM.
Now since I don't want the overhead of floating point(no need for it) the " .703125 " is lost. We reverse the calculation to check our work,
1220 clock (CNT) cycles * 65536 cycles per second = 79,952
What I can see from that is trying to synchronized the delays(pg 219 in the manual) would be imposable. And whats the point of trying to keep things in sync, just to go to a better scaling when the current scaling works great?
I never said anything about creating errors.
I question if you know what "error" I am talking about. Let me explain my error.
Lets say I want my oven to be set to a temperature of 250°F, and the oven is currently sitting at room temperature of 75°F. The "error" is the difference between them. 250°F - 75°F = 175°F
Now lets use the same values, but figure out the "percent error"
((250 - 75) / 250) *100
(175 / 250)*100
0.7 * 100 = 70% error
That is what I would like to do. Where my PID gets a percent error input, does all of its calculations, and outputs a percentage to the PWM.
Thank you so much for your input Tony. And I am truly sorry if I may have said something that might of offend you. I respect everyone on here (except spammers, cant stand spammers), and I don't ever want to offend anyone. But sometimes you have to get your point across.
Why not create a conversion factor and say 1024 = 1%. That gives you a granularity of 1/1024.
PUB Main Repeat ErrorTop := GoalTempTop - ReadTempTop BiasTop := BiasAdjust(ErrorTop) PWMTop := ErrorTop * BiasTop 'add a Max output based on the pwm max duty ErrorBot := GoalTempBot - ReadTempBot BiasBot := BiasAdjust(ErrorBot) PWMBot := ErrorBot * BiasBot 'add a Max output based on the pwm max duty Waitcnt(80_000_000 + cnt) Pub BiasAdjust(elementErr) | bias 'method to boost temp at a greater rate when larger error. If elementErr> 200 'or whatever the range would be for the top 25% of temp range in the profile Bias := 10 Return Bias If elementErr> 100 Bias := 5 Return Bias If elementErr> 10 Bias := 2 Return Bias If elementErr> 1 Bias := 1 Return BiasThis does not have built in methods to limit the max temp increase per second, that would need to be included in the goal profile. This does not answer your direct question
Btw you do not need D in the math. Is your main program insuring you do not exceed the max temp increase per second?
Back to your real question, I would not bother with adding another layer using the %. I would scale up where needed, the scale back to the usable PWM range. Temp is such a simple/slow medium to track and adjust.
Could you provide a quick example? I am quite not understanding.
Just wondering, could you not use a look up table?
What does it hurt to have D in the math? It offers me more options, since the gain can be as low as .001.
As of right now, my program does not control temperature per second. That is the next thing I am going to work on. Right now, for testing, I set a temperature and the oven goes to it and holds that temp.
That is why I wanted to know. My PID works great right now, but if something simple could make it better why not try it. I AM NOT going to redo the work I have that works. I have spent WAY to much time on this oven, and I want to just finish it to get it out of my hair. I have set a required completion date for programing the major portion of the code. That does not include minor bugs or tweaking. I want to be done by end of May.
I'm sorry if I'm missing the point of your question. But it seems to me that if you want to keep integers, can't you just change the order of the calculations?
Wouldn't that just truncate the result to a whole number in % units.
Your 70% example
As written it is Which either uses floating point or truncates the .7 to 0
Changing the order gives: which keeps everything integers
That's essentially the method I use in forth (although backwards)
Again, If I've missed the point of your question or oversimplified it, I apologize.
Tom
.
Why do you think I want so bad to figure this out? I want to see what I can do, with the requirements that I set over 9 months ago. Yes, I have been working on this oven for almost 9 months. And I have redone the PID 4 times. I know the formula by heart. My problem part is, I keep changing things. Well since I set a complete date I don't want to change anything that will take me days to figure out and get it running great.
That is why I was asking the question. I know someone on here has done or figured out how to do percentages with integers. Math is not one of my strong points, but I try.
I knew that was going to be my problem from the start. When I do it on a calculator, and I see numbers to the right of the decimal point. I know then the prop cant do it by its self (excluding modulus, floating point, etc..)
You hit my question right square on the head. And I am very happy how simple it is, Thank you. I am going to try it for a couple hours, and see if there is any improvement.
Right now you are making all the calculations based on temperature measured in degrees so:
set[idx] := desired temperature in degrees
current[idx] := adc reading converted to degrees
set[idx] and current[idx] along with ScaleFactor are used to calculate Pterm, Iterm, and Dterm
Pterm, Iterm, and Dterm along with Bias are then used to calculate ControlValue
ControlValue is then used to control the heater PWM
Here is what I suggest trying:
set[idx] := adc reading equivalent to the desired temperature
current[idx] := adc reading
set[idx] and current[idx] are used to calculate Pterm, Iterm, and Dterm
Pterm, Iterm, and Dterm along with Bias are then used to calculate ControlValue
ControlValue is then used to control the heater PWM
set[idx] and current[idx] may need to be scaled (by shifting) for best results, or the pwm loop count could be changed.
The only time you would need to calculate the temperature would be when you want to display it. Everything else would be done in integer math.
This project has been pushing me on learning more spin, more on process control, more on everything. That is why I started it, and want to complete it. Usually when I get overwhelmed with a project, I put it off to the side and tell myself " I'll get back to it later on ". But I never get back to it. The forgotten project becomes parts for my next idea. I want to stop that with this reflow oven. I want to have a working oven that I can use by the end of May. It might not have everything I wanted, but I can add them later. I have accounted for everything I want this oven to have. Both in spin (pin naming), and the schematic. If I wanted to, I could have a board made up right now, but I want to make sure everything is right.
The temperature measurement is coming from 2 MAX31855 modules. The modules are designed and made by Maxim. The chip outputs a 14-bit temperature value, with each bit = .25°C (150°C = $0258) I drop the 2 right most bits, because I found the oven just works harder for nothing trying to maintain a .25°C temperature range.
But it does not matter now, I found out the MAX31855 chips are junk. At room temp (25°C) they read correctly, but the higher the temperature the larger the temperature difference. I have a Fluke DVM that can measure temperature. So I used it to check the temp of the oven. I had the oven set to 250°C, and the Fluke was saying the temp was 295°C. So I thought the Fluke was wrong. So I grabbed my $20 meat thermometer that has a separate probe and put it in the oven. The meat thermometer was about 5°C cooler than the Fluke. So that confirmed the 2 MAX31855 are not calculating the temperature correctly.
I am going to ditch the MAX31855's for this project. And make a proper thermocouple measuring setup.
I agree it is. I looked over everything and double checked everything. I could not find any problems. One thing I did notice, the cold junction of both chips are about 10℃ cooler then the area they are at. If I place my finger on the chip to warm it up, I can get a correct reading from the thermocouple.
I have no idea how to correct that since the chip handles the correction.
Sure, no problem
CON Upper = 0 Lower = 1 VAR long cog long stack[10] long ChipSelect[2] long MISO long Clock PUB start(upper_pin, lower_pin, MISO_pin, CLK_pin, TempPtr) ChipSelect[Upper] := upper_pin ChipSelect[Lower] := lower_pin MISO := MISO_pin Clock := CLK_pin cog := cognew(get_raw(TempPtr), @stack) PRI get_raw(TempPtr) | X, idx dira[ChipSelect[Upper]] := 1 dira[ChipSelect[Lower]] := 1 dira[Clock] := 1 dira[MISO] := 0 outa[ChipSelect[Upper]] := 1 outa[ChipSelect[Lower]] := 1 outa[Clock] := 1 repeat repeat idx from Upper to Lower outa[ChipSelect[idx]] := 0 'Get raw data from upper MAX31855 repeat 32 X := (X << 1) | ina[MISO] outa[Clock] := 1 outa[Clock] := 0 outa[ChipSelect[idx]] := 1 long[TempPtr][idx] := X X := 0"TempPnt" is in the parent object
This code is for displaying the temps on the screen.
It is a IOtech DBK52. I was going to use what I found from this to create a thermocouple reader of my own. These things were not cheap, and company's wanted the best accuracy for testing. So I figured, why spend hours designing and testing my own, when an engineer almost 20 years ago did it for me.
You are not going to need the sign anyway, but this dos put it correctly in the long.
Can you post the binary for:
A complete response from the device (all 32 bits as returned in binary), plus show the Fluke temp in C. Room temp plus with the oven at some temp (ie 250C)
TC - this is an interesting thread and it sounds like you are learning a lot. The company I work for makes furnaces to heat glass. The furnaces might be 100' feet long or so. Similar to your reflow, we use PI control with a 1 second cycle. I'm not in the controls group, I'm a mechanical guy, but I dabble where needed.
Anyway, it occurs to me that working with percent error is no different than what you are already doing, but would require changing your PID constants - I don't think it will gain you anything.
Let's say error1 is your current method and that error2 is based on your percentage method. Assume the setpoint is 200 and the current is 100.
error1 = 100. error2 = 100 / 200 = error1 / 200. error2 is always just error1 multiplied by some constant value. (I left out mulitplying by 100, but since it is a constant is doesn't change the effect).
As far as clipping the output, that will always tend to happen. Anytime the error is greater than the control band, then the P drive will either be 100% or 0%. I don't see this as a problem, just the nature of the beast.
-Russ
I modified Jon McPhalen's (JonnyMac) jm_MAX31855 object, so I could run it with 2 chips and in another COG.
Here is a video from a resting state up to 250°C. For the thermocouple value you have to add a decimal point after the first 2 numbers. I was just to lazy to add it. So 10125 is actually 101.25°C
Thank you, I am learning a lot, and loving every minute of it. I never heard of anyone using percent error for a PID, and I wanted to try it and experiment with it. It made the oven perform worse.
I couldn't find any info if clipping of the CV was normal, so thank you for letting me know that it is normal. Now I will not worry about it.
Now I just have to get the temp to be correct (or closer then they are now)
My question as well, and just in case that is the problem, no reason to panic or buy new parts. As long as the readings are stable (off by the same amount) that can always corrected mathematically.
Yes I am. They came as a box set. When you buy the maxim max31855 development module, it comes with the thermocouple.
My question is, how can it be corrected?
I would double check the connections, programming, the chip, and thermocouple you received to be sure everything is as it should be. You can correct the readings to match the Fluke meter readings using the calculation below, but it is very strange to find that the correction requires a third order cubic spline to correct the reading. Makes me think your thermistor and chip are not a matched set.
TEMPERATURE = A + B*X + C*X*X + D*X*X*X
Where A = -4.5, B = 1.3, C = 0.0012, D = -0.000006 (-6 E-006) and X is the input from the MAX31855
That calculation should make the readings match very closely. The worst difference is 1% (2C) at 200 degrees C.
At work, we have different kinds of thermocouples, (probes, thick wire, thin wire, high speed, etc..) I will grab a few and test them out and see if they make any difference. At work we only use Omega K type thermocouples.
Thank you for the "third order cubic spline" I had no idea equations like that existed. Like I said, math is not one of my strong points. I am assuming the equation is the raw (14bit) value from the MAX31855. I will make a "DAT" table that will convert the temps.