kiln_must_catch_up can sit for hours when cooling (versus heating)

[amahpour]

Given the nature of how well insulated Kilns are, if a schedule starts when the kiln is already partially hot (i.e. 120 F) it could take hours to cool down to a lower temperature (e.g. 80 F) to start the schedule.

I love the feature of pre-heating before running a schedule but if the kiln already slightly overheated or, in some cases, overshoots at the beginning of a schedule, it can take hours to get back on track.

Adding smarts to the "cooling" side of kiln_must_catch_up is the most optimal way of fixing this (e.g. if the delta is > 20 degrees F then cool down, otherwise, proceed) but separating the single kiln_must_catch_up flag into kiln_must_catch_up and kiln_must_cool_down individual flags would be a great start.

[captaincaden]

In theory, my idea of having the ability for the kiln to adjust the profile based on where the current temperature is when you start would also solve this, I believe.

As far as I know, this function was already included in the blinka branch, but isn't currently a part of the main branch.

[amahpour]

@captaincaden Thanks for the tip - didn't notice that branch. Is that the what the ignore_tc_temp_high config option is for?

[captaincaden]

I believe ignore_temp_too_high, when set to True in config prevents the kiln from shutting down if the temperature passes the temperature set in emergency_shutoff_temp . It was part of a request to be able to pick and choose which failure conditions you wanted the controller to ignore, and in turn just log the error instead of the error causing the kiln to stop running. Some people have had issues of random, noncritical thermocouple errors causing the kiln to totally stop when it didn't need to, so giving the option to ignore certain emergency conditions helps that out. Ignoring emergency shutoff temperature is probably not something most would want to do, but having the option for troubleshooting or something like that is helpful.

[amahpour]

Got it. So is there a flag I can use just for kiln_must_catch_up (real setting) but not kiln_must_cool_down (made up setting)?

[captaincaden]

The controller already has a 'too hot must cool down' cycle that it uses, but like you've mentioned, it can take a long time for that to happen naturally.

With this branch, without the controller (automatically, like what I proposed a while ago, and what I believe was committed to the blinka branch) or you making a change to where the profile is starting (this option has worked for me in the past, using the API to tell the kiln to start at a certain point in the profile), it will have to cool down if the target temperature (plus or minus the pid_control_window in config) before it will be able to proceed if kiln_must_catch_up is set to True.

Check out my issue I opened a while ago where we discussed this issue. It has some mentions of how to use the API to go on in tell the kiln to start say 40 minutes into the firing to combat the issue, as well as all of the mentions of the feature of the kiln automatically starting the profile based on where the kilns temperature currently sits that was added to the blinka branch.

https://github.com/jbruce12000/kiln-controller/issues/121

[captaincaden]

@jbruce12000 I would love to see the automatic profile shift based on starting temperature feature added into this branch, although I know it's in the blinka branch. (https://github.com/jbruce12000/kiln-controller/issues/121) I'd like to switch to the blinka branch, but it will just take a while and a bit of work to reconfigure and unsolder which wires I've used on the gpio pins from this project to the gpio pins needed for the blinka branch. I remember some discussion of trying to make it so that changing input/outputs wasn't necessary but unsure if that was ever completed or not.

[rondoc]

Lets make life simple...make profiles that start at different temperatures. Then just pick one that fits the occasion. This obviates the problems I think you are addressing. I have two controllers for my kiln and one is the pi ( in original version I think) .. The other is a simple controller that can select the power level in steps, from 1/16 full power to full power in 1/16 steps. For a very long candling, often overnight, I use the lowest setting of the steppable one. Then I switch over to the pi with a profile that starts about where the candling has ended. I hope this is some help. ronald

On Sun, Nov 19, 2023 at 1:18 PM captaincaden @.***> wrote:

@jbruce12000 https://github.com/jbruce12000 I would love to see the automatic profile shift based on starting temperature feature added into this branch, although I know it's in the blinka branch. I'd like to switch to the blinka branch, but it will just take a while and a bit of work to reconfigure and unsolder which wires I've used on the gpio pins from this project to the gpio pins needed for the blinka branch. I remember some discussion of trying to make it so that changing input/outputs wasn't necessary but unsure if that was ever completed or not.

— Reply to this email directly, view it on GitHub https://github.com/jbruce12000/kiln-controller/issues/161#issuecomment-1817980490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXA65G2HSYXP55NIV3UGKY3YFJZTZAVCNFSM6AAAAAA7LQRL72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXHE4DANBZGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Anger is usually regrettable, kindness rarely.

[jbruce12000]

I have certainly run into this problem. My solution has always been to modify the schedule to be at or slightly above the current temperature of the kiln. This way, you don't have to wait for the kiln to cool. This can be done through the web interface, or you can edit the file for that schedule on the command line.

[amahpour]

Right. I've always done that in the past but I notice that then I get overshoot I have to wait as well. That's the real issue here...

[jbruce12000]

Ah, that's a completely different issue. If you have that much overshoot now, you need to tune the PID so overshoot is reduced.

I'd really like to see the logs [and your config.py] when this happens so I can chart the kiln run and give you proper advice. There is a script called ziplogs to zip up the important stuff from /var/logs [if thats where your logs go].

You can make the pid control window larger using the setting pid_control_window. It's likely that your telling your kiln to heat up as fast as possible using kiln_must_catch_up=True. So it goes 100% as it is told to do, reaches the window at 5F [or C] before the set point, pid control starts, but it's WAY to late at the point and it blows past the wanted temp... then it sits around for a long time while it cools.

Another option is to set kiln_must_catch_up=False... so it will continue to the schedule [instead of pausing] and once temps are back inside the window the pid will kick in... and likely repeat that cycle with smaller and smaller peaks.

[jbruce12000]

The kiln_must_catch_up setting pauses if the current temperature is outside the window... either too high or too low. You define the size of that window.

There is no setting just for being too low.

If I were you, for now, set

kiln_must_catch_up=False
pid_control_window=50

This way, PID control kicks in much earlier and begins reducing power from 100% to much smaller amounts [mostly controlled by P and I]. To tune the PID to reduce overshoot, make P smaller by half. test it. Double I. test it. Double D, test it. In that order.

If the loop is critically damped [well tuned], you can expect a slight overshoot and settling to your desired temp with very little oscillation.

Read this if you haven't already: https://github.com/jbruce12000/kiln-controller/blob/master/docs/pid_tuning.md

[amahpour]

@jbruce12000 thanks for the response and mad props for putting this repo together. This is such an awesome project.

Everything you stated above is totally logical and that’s what I’ve done in the past…I was just hoping for an even more “intelligent” way of doing things but I’ll just go back to how I’ve always done it (which always worked in the past for).

[jbruce12000]

hmm. I'm not trying to shut you down. I really do think that something like making the pid control window larger could solve your problem... without a big investment in time or effort.

I don't think that creating a new setting for this (like kiln_must_catch_but_only_if_its_too_cold) is the right thing to do.

[amahpour]

Lol. I agree. Closing issue.

[jbruce12000]

I actually think this is a problem worth tackling. I've definitely had this issue and maybe there is an easy solution. I'm exploring two new settings...

low_start_temp = 300
slow_start_percent = 20

This would let you set a percentage of the max power below a certain temp. In this case, when heating outside the PID window, 20% of max power is applied to the elements.

You decide how gradual you want things to be. You decide when they should stop being gradual.

[jbruce12000]

I'm only making changes on the blinka branch. To use this feature, you'll need to switch to that branch. You'll likely need to do some re-wiring if you're not using that branch already.

[jbruce12000]

in simulations, overshoot goes from 24F without the new settings to 4F using the config above. I tested with a schedule that starts 200F and the kiln heats as fast as possible from 65F to reach that.

[jbruce12000]

This does not solve your original problem, but this is something that has always bugged me... so I'm going to move forward with the fix. I'll get it tested tomorrow and merged.

[jbruce12000]

This feature is complete. @rondoc you might be able to get rid of your 2nd controller with the addition of this. not sure. this is only on the blinka branch.

This is the section I added to config.py with the two new configuration parameters:

########################################################################
# low temperature throttling of elements
# kiln elements have lots of power and tend to drastically overshoot
# at low temperatures. When under the set point and outside the PID
# control window and below throttle_below_temp, only throttle_percent
# of the elements are used max.
# To prevent throttling, set throttle_percent to 100.
throttle_below_temp = 300
throttle_percent = 20

[rondoc]

I like having my other controller. It gives me hands on flexibility beyond the pi kiln controller. I built it about 40 years ago and it still works!! I doubt if the pi will last that long due to the failure possibilities in either hardware or software. The pi is fantastic and I really like its features especially the ability to monitor remotely. In order of liked features here's my list.

1. Remote monitoring .
2. Programmable temp./time curves.
3. Fail signals from over temp.
4. Thermocouple fail alarms
5. I didn't design it so I can spend more time on my ceramics!!:)
6. Cost calculator.
7. Amazing support from users and coders who are often both. Thanks everone. Ronald.

Ps anyone want my step controller circuit It is zero crossing system with 1/16 steps from 1/16 to full power. Just ask..just the schematic :) Ronald.

On Tue, Nov 21, 2023, 6:56 AM Jason Bruce @.***> wrote:

This feature is complete. @rondoc https://github.com/rondoc you might be able to get rid of your 2nd controller with the addition of this. not sure. this is only on the blinka branch.

This is the section I added to config.py with the two new configuration parameters:

########################################################################

low temperature throttling of elements

kiln elements have lots of power and tend to drastically overshoot

at low temperatures. When under the set point and outside the PID

control window and below throttle_below_temp, only throttle_percent

of the elements are used max.

To prevent throttling, set throttle_percent to 100.

throttle_below_temp = 300 throttle_percent = 20

— Reply to this email directly, view it on GitHub https://github.com/jbruce12000/kiln-controller/issues/161#issuecomment-1821084037, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXA65G3FLWSZUV4HMPGQ4GLYFS6KDAVCNFSM6AAAAAA7LQRL72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRRGA4DIMBTG4 . You are receiving this because you were mentioned.Message ID: @.***>

[amahpour]

@jbruce12000 just curious, why are you maintaining the blinka branch versus merging it to master?

[jbruce12000]

@amahpour my intention has always been to make merge blinka into the master branch... I've been looking for a way to make this less impactful, but using hardware SPI requires re-wiring.

Once I merge, if anyone using old wiring pulls the repo, their kiln will stop working.

I plan to do this merge some time in Dec. I'll post instructions with a hash that people can use to pull the old version if they like.

[amahpour]

Got it. @jbruce12000 Why did you need to switch to Hardware SPI?

[jbruce12000]

I did not need to switch to HW SPI. My goal was to not manage the thermocouple libs for the 31855 and 6. By using blinka, Adafruit owns and manages those. It also opens up the ecosystem to a hundred boards... https://circuitpython.org/blinka.

I think some folks have explored software SPI [with blinka] which would allow virtually any GPIO pins to be used. I have not yet explored this.

[jbruce12000]

Software SPI looks pretty straightforward. I might find some time to test this during the holidays. If it works ok, it might be an easier transition for some.

https://github.com/adafruit/Adafruit_CircuitPython_BitbangIO

[jbruce12000]

here too... https://learn.adafruit.com/circuitpython-basics-i2c-and-spi/spi-devices#software-spi-and-i2c-2837764

[amahpour]

Yeah. Looks pretty straight forward. Adding that as a supported option would be awesome.

[chipgarner]

@jbruce12000 My pull request #132 from last February allows using software pins. It only includes the 31855 as I could not get it to work for the '56.

[chipgarner]

@jbruce12000 PS the above pull request code first looks for the TC on the hardware pins. If it finds nothing, it tries the software pins. I tried everything I could think of to get BitBang to work with the MAX 31856 put could not get it to work with the new Adafruit libraries.

Most users are probably using the '55.

I think it would be pretty easy to get the '56 to work by using the old Adafruit library. The could could switch

[jbruce12000]

@chipgarner thx. I wonder if the 31856 lib has been fixed. I think you opened issues for that. Have they been addressed?

[jbruce12000]

@chipgarner I don't see any issues on https://github.com/adafruit/Adafruit_CircuitPython_MAX31856

If there is still a problem... I'd like to open an issue. refresh my memory, what was the problem?

[chipgarner]

@jbruce12000 I can't find it either. The Adafruit instructions now include using the software pins. I don't think this was the case when I worked on this last February.

I have had a problem with the '56 halting. It never returns from the wait. This happens very occasionally, it might work for 20 hours or more and then quit. It resumes some time later. It is not temperature dependent. This may be a problem with my '56 only, but it might easily go unnoticed by users running kiln-controller unless it were to happen at the wrong time.

I have ordered another '56 and will try again getting the software pins to work when it arrives next week.

[jbruce12000]

ok. keep me updated. I'll take a look at the PR for merge of 31855 code. my goal is to have an easier way for folks to migrate from the master branch to blinka.... and sometime in Dec, make blinka the master branch.

this project needs to move on so we can tackle other things like better testing.

[amahpour]

FWIW I'd like to help refactor everything into classes and write some unit tests...

[jbruce12000]

@chipgarner on the blinka branch, I added support for hw and sw spi and autodetection based on what pins you use... so if you use the proper hw spi pins in config.py, it will assume you want to use hw spi. I'm not sure if autodetection is the right thing to do. maybe just adding a config parameter for it is more clear.

anyway, test the latest blinka with the 31856 when you get it. lmk how it goes.

[captaincaden]

@jbruce12000 I updated with your most recent changes in the blinka branch and it runs as expected with 31856 for me. Detects that I'm using hardware pins, and shows the output as expected in both kiln-controller and test-thermocouple. Cant say how it behaves using software pins since I already swapped everything to the hardware pins, but 31856 behaves normally for me in current blinka on hardware pins.

Just a heads up you left ignore_too_many_tc_errors set to True in blinka. Unsure if that was intentional, but thought I'd mention it. I left it false for the tests I did with 31856.

[chipgarner]

ignore_too_many_tc_errors is True because the 31855 hits a lot of errors at high temperatures. I have tested this on two 55's and characterized it to some extent.

The MAX31855 reports occasional errors at lower temperatures. By 900C it reports lots of errors, at least a third of the measurements are errors. By 1100C well over half the attempted readings return errors. This is repeatable, and the same pattern occurs on the way down when the kiln is off, so this is not from electronic noise.

kiln-controller works fine, it really only needs a good temperature every minute or so. Still, I find this a bit unnerving.

[rondoc]

I have not had any tc errors, (55 chip). I think that these are caused by accidental grounding of tc wires. And may be shorting wires together.. Correctly putting the tc wires in ceramic tubes is essential. Also using tc connectors from kiln to chip. I fire to cone10 with no problems. The pid is not perfect at low temps but not a problem it is within a degree to cone 10... can't get better. As I mentioned b4 making a new profile to match an already hot kiln is not a challenge. IDEA: It would be nice to be able to make a new profile while firing is in progress so switching profiles would be easier .

On Thu, Nov 30, 2023, 1:19 PM Chip Garner @.***> wrote:

ignore_too_many_tc_errors is True because the 31855 hits a lot of errors at high temperatures. I have tested this on two 55's and characterized it to some extent.

The MAX31855 reports occasional errors at lower temperatures. By 900C it reports lots of errors, at least a third of the measurements are errors. By 1100C well over half the attempted readings return errors. This is repeatable, and the same pattern occurs on the way down when the kiln is off, so this is not from electronic noise.

kiln-controller works fine, it really only needs a good temperature every minute or so. Still, I find this a bit unnerving.

— Reply to this email directly, view it on GitHub https://github.com/jbruce12000/kiln-controller/issues/161#issuecomment-1834576267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXA65G7SM7IBI2EFXA7EV2LYHDZ57AVCNFSM6AAAAAA7LQRL72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZUGU3TMMRWG4 . You are receiving this because you were mentioned.Message ID: @.***>

[chipgarner]

@rondoc I don't think you will see the errors unless you are looking at the logs. I see the errors with different setups and thermocouples. No errors on the same TC using the MAX31856 or a Fluke. Jason also reports errors at high temperatures.

I was able to repeat this with two different '55s and it seems to have the same temperature dependence on heating and cooling.

I don't think the TC's will work at all with the wrong kind of wire, or the wrong wire on the wrong line.

[captaincaden]

@chipgarner I use 31856 and rarely see thermocouple errors. I have all of the predefined errors set up to send me an email in the event any of them happen, so I see them immediately when they do happen (if it's a tc error that kiln-controller logs, it gets emailed). Out of hundreds of completed firings and thousands of hours of the project running idle I've probably seen 3-4 (unexpected) TC errors. But I do like the comfort of having the ability to set it up so that it doesn't just stop the kiln on the ones that aren't critical errors.

And you're correct, TC's won't work with wrong wire types or incorrect polarity.

[chipgarner]

@captaincaden I am also seeing very few errors on the '56. However, the annoying one I do see is a complete halt of the thread. This seems to happen very occasionally - I have seen it run for more than 20 hours with no problem. The error may clear itself, I have seen it do this more than once within about 5 minutes. I don't know if this occurs on the main repository version, I see it on the blnika version and with other software using the new Adafuti library.

I am pretty sure the blinka version will just keep running, with the one thread halted, and keep reporting the old temperature. If the reported temperature flat lines you will not see it on the graph as the kiln will be trying to catch up, so it would be very easy to miss this error.

I also find this a bit unnerving. I have only tried one '56 and have another on order to see if it also errors.

[chipgarner]

@rondoc It would be very interesting to see one of you firing logs. It is certainly possible that you have a '55 that is working better.

[captaincaden]

@chipgarner Interesting. How often do you see that happening? Is that what originally was the issue when you were testing the '56?

[rondoc]

Why persist with the 56 chip? It's intended for other thermocouples as well as K yype. I did try the 56 on the Adafruit board but didn't find it any different so stuck with the 55. The 56 must be more complex so possibly somewhat frail. R

On Thu, Nov 30, 2023, 3:15 PM Chip Garner @.***> wrote:

@captaincaden https://github.com/captaincaden I am also seeing very few errors on the '56. However, the annoying one I do see is a complete halt of the thread. This seems to happen very occasionally - I have seen it run for more than 20 hours with no problem. The error may clear itself, I have seen it do this more than once within about 5 minutes. I don't know if this occurs on the main repository version, I see it on the blnika version and with other software using the new Adafuti library.

I am pretty sure the blinka version will just keep running, with the one thread halted, and keep reporting the old temperature. If the reported temperature flat lines you will not see it on the graph as the kiln will be trying to catch up, so it would be very easy to miss this error.

I also find this a bit unnerving. I have only tried one '56 and have another on order to see if it also errors.

— Reply to this email directly, view it on GitHub https://github.com/jbruce12000/kiln-controller/issues/161#issuecomment-1834709187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXA65G4GLU7GOUUAGGFY7PDYHEHS7AVCNFSM6AAAAAA7LQRL72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZUG4YDSMJYG4 . You are receiving this because you were mentioned.Message ID: @.***>

[rondoc]

How do I get a firing log to you? Needs to be simple it's almost my 87th birthday! Ron.

On Thu, Nov 30, 2023, 3:22 PM Chip Garner @.***> wrote:

@rondoc https://github.com/rondoc It would be very interesting to see one of you firing logs. It is certainly possible that you have a '55 that is working better.

— Reply to this email directly, view it on GitHub https://github.com/jbruce12000/kiln-controller/issues/161#issuecomment-1834715582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXA65G73SFSEBB6KRCBJHITYHEIL5AVCNFSM6AAAAAA7LQRL72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZUG4YTKNJYGI . You are receiving this because you were mentioned.Message ID: @.***>

[chipgarner]

@rondoc I will check on how to get a log and send you an email. The reason for the '56 is that some people using kiln-controller are already using it. Some are using platinum thermocouples which are now very cheap from China and are supposed to last longer.

Thank you for making me feel young at almost 73.

[chipgarner]

@captaincaden The issue was I couldn't get software pins to work with the '56 with the new Adafruit library. It works with the old (non-Micropython) library. The halting is a separate issue and is possibly only on the on '56 I have tested, but I think it may be common and slip through most kiln-controller users.

[chipgarner]

@jbruce12000 The hardware pins are different on different boards but you can access any board with hardware pins with the same code in Micropython:

self.spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)

This works for any board with hardware SPI pins, I only tried it with the Pi.

The user only needs to specify the pins in config.py if they are using software SPI.

[jbruce12000]

@chipgarner yeah, I could eliminate the spi pin config for hw spi, but if the autodetect route doesn't work, or someone needs to override, it'd be handy to have. I'm just not sure about this yet. I figured for a first pass... 1. verify all configured pins match hw SPI defined pins 2. call board.SPI and let it handle hw SPI for whatever board is being used (not just pis). 3. make sure instructions are clear

@captaincaden thx for testing. glad it works ok for hw spi on 31856. Sorry about the setting for too_many_errors. That should not be the default. It's 31855 thing I've always experienced. I have a really nice k type tc with ceramic isolators... I'm doing all the things right, but I still get errors at high temps... mine start at 1600F and errors increase with temps. PS, you decided a few weeks too early to move to blinka. I only get a few weeks a year to work on this due to life, so you get what you get.

Also, I feel like I was the only one using the blinka branch. I've been kinda fast and loose with commits. Now I gotta be more careful about what I do.

@rondoc Happy early 87th!

[amahpour]

Hey guys. For those not experiencing any errors whatsoever can you post pics of your setup? I'm particularly interested in @rondoc's setup with with comment:

Correctly putting the tc wires in ceramic tubes is essential. Also using tc connectors from kiln to chip

My log errors are intermittent reporting shorts to GND and VCC. At first I thought it was the plasma stuff (reminds me of Single Event Upsets in spacecrafts) but I also discovered the errors at 300-400F. I set the config to ignore those error register bits and so far so good (almost done with my first cone 6 run).