overshoot and used power calculation

[rmPscr]

Hello and, firstly, congratulations and thanks for the work with this, it's really great!

I have a small issue with my controller only going to the next step after about a minute or so, which sometimes results in an overshoot (because for one minute beyond set time for next step it keeps the heating ramp going), such as in the picture (I changed the skin a bit...).

As you can see, at around 17.04 hour mark it should have started a slower ramp, but instead it continued the rate of rise for another minute, going 20° over, then allowing to cool and continuing. Do you know why this might be? I haven't found it in the code... (even tho the actual temperature line appears above the set temperature line, the kiln never overshoots on ramps -- visually, it has to do with the tension of the chart lines, which I changed to 0 since; I'm sure because I was monitoring the temperatures live).

Thanks!

p.s. I have an ACS712 power meter, which is not really accurate and was more of a nuisance than a help so I removed it. But I still want to know, at least with some approximation, how much power I used, so I implemented a software power meter based on mains voltage and kiln power, as a backup to a power meter. Not perfectly accurate, but does the job better than a cheapo power meter.

If there is a power meter, then use it, else use software calculation:

• added 2 more fields in the preferences where one can input their mains voltage and kiln power in watts
• based on kiln power I calculate the coil resistance
• based on coil resistance and mains voltage I can check how much amps it draws
• based on amps, pid_out and sample time I can calculate energy consumption

p.p.s. You don't have q,Q,v and V in your allowed characters for accepted program filenames (PIDKiln.h:175)

[Saur0o0n]

Hi,
Starting from bottom...
Letters fixed - true, those are not common in my language so I kind of forgot about them :)
Power metering is currently rudimentary, I've added it because I had a coil to measure current draw and wanted to test it - but without voltage measurement it's ... quite useless in terms of actual power measurement, it more like allows to check if the heating elements is acutely working or not :).

On the overshoot problem. I understand you actually referring to temperature overshoot - not the graph showing it wrongly right? (since you mentioned graph pressure).
PID is recalculated every second, but the heating element is updated (on/off) every 5th second (PRF_PID_WINDOW) - since those big ones, don't like to be on/off too often. If you see overshoot in longer period of time, I would say that PID is set so. But I must admit, that that spike is quite interesting. Do you have program logs?

[rmPscr]

Hi and thanks for the reply.

At some point I was looking online for filename validator tools because I could not understand why I couldn't upload a file named simply... bisque.txt :). The absolute last thing I tried was to check the code for allowed characters...

No, unfortunatelly I don't have the program logs from that firing because since then I changed code and re-uploaded (the power consumtion code), thus deleting all logs from the esp..., also debug was off... but I did check them and there was nothing apparently wrong (so I didn't think to save them), just that it went to the next step a bit more than a minute after set time. Not only where the graph shows the spike, but also on the next one, where it was supposed to start dwell at 1000°, and the next, on cooldown. Its a much smaller 'spike' because the ramp slope was smaller, more difficult to see with the chart line width, but it still went over maybe 6° at around the 18:00 hour mark:

My fear is that if I have to burn something at close to the limits of my kiln, in an even longer program (10-12 hours), this overshoot (in time actually) will bring the temperature to higher than the materials in the kiln are rated for.

But in my case I changed your code a bit to read TC and compute PID 4times/sec, 250ms being what the max31855 can handle, and changed the window to 2.5 seconds -- the SSR can handle even 1 sec window time in my experience, with 1% on-time being 10ms which is half period at 50Hz, and that is the minimum window that makes sense with a zero-crossing SSR. I did it because I have a small homemade kiln (oven really) with a lower inertia than the big ones and only 2.4kW power at 20°C (2.2kW at 900°) and I use it also as a heat treat oven at lower temperatures (850°) where I need faster response because I open the door.

So I changed the interrupt to 250ms. Everything else stays the same in the program loop (functions called every 1 second are still called every 1second, same with functions called every 10 seconds) -- this is by resetting cnt1 counter at 39 instead of 9 and calling the one second functions every (cnt1+1)%4==0). But cnt1 is a local variable, right?, so it shouldn't mess anything else up... In short, KilnPID.Compute() and Update_TemperatureA() every 250ms, Program_calculate_steps(), LCD_display_mainv1() and SAFETY_Check() every 1s and the rest every 10s.

I realise that messes up things a bit but is 1 minute over mark after 6h30m exagerated? Also, if I check the window time every 250ms instead of 1s than actual window size is even closer to the 2500ms set time...

So why is the controller continuing with a rate of rise in temperature even after the set temperature was reached? For example, at 17:04 it was supposed to be 945°, instead, calculate steps set it at 965°. This is not a temperature overshoot (as in, PID related) -- it's a time overshoot (which based on ramp slope translates in a temperature overshoot), right?

My only explanation is that by doing what I did, I either messed up something with the Program_calculate_steps(), even if it is still called every second; or there is a more general timing issue (a millisecond is not a millisecond). This only happend with a long pottery firing schedule, it doesn't really happen with short ramp-ups to temp and dwell, so I suspect a desync somewhere that adds up in time. The LCD is also updated every second, except its not exactly every second, if it were, on screen1 I wound see the time changing every second, but sometimes it skips, quite often actually.

I realise this is probably something I did -- voiding the warranty by messing with your program :) -- but I was curios if you or anyone else had this time overshoot issue on long firing schedules.

Thanks!