Color sections of live graph when kiln had to catch up

[NacMave10]

Great project. I'm a user now. I feel that it would be useful to color the live graph (orange?) for the sections that had the kiln to catch up. As it currently is, it seems that the kiln could just perfectly follow the profile which isn't usually the case.

I could give a try at this change but my coding skills are a bit rusty.

[jbruce12000]

I'm marking this as a feature. Not sure the goal here... I guess if a kiln is constantly trying to catch up, you'd see that in the graph and [possibly] take action based on it. Making it a bright color [like orange] will make folks think that it's bad and must take action to fix it... which is not always the case. Lot's of folks want to heat as fast as possible [or cool as fast as possible] to a specific temperature.

kilns can only heat so quickly. some have elements that are underpowered or old... and this max heating ability of a kiln decreases over time. anyone can ask a kiln to heat faster than it's capable.

lastly, if kiln_must_catch_up=True in config.py, the profile is stopped until the temp is in the window... which means that no new points get added to the graph [because essentially no time has passed]. So this feature would not matter in that case.

[jbruce12000]

I created some software for graphing a kiln run. It has a report that shows every time the kiln was trying to catch up. It also has graphs of all the PID params plus others. The purpose is for me to easily visualize someone's kiln run to help them troubleshoot and adjust.

https://github.com/jbruce12000/kiln-stats

[captaincaden]

How cool would it be to give a link or a button of some kind in the websocket that would get the data file, and generate those graphs from the kiln-stats software and then send it back as the pdf in the browser automatically or download it. Sounds complicated, but would be a useful tool, and wouldn't need to happen until either onclick with conditions that information to produce the graphs was available. Could possibly make it easier for people to just send you the pdf file too if in need of analyzation.

on the topic of colors, and unrelated to this I've often thought about how you could also give a popup notification in the websocket when something adverse happens that ends a run instead of the generic 'run completed' in the event something stopped the kiln that was not completion of the profile. The complication there is that it would have to stick around long enough or until someone closed the notification to be any more useful than just checking the logs, and it would have to be added for it to know that it didn't complete, instead it errored out. For those who may be new to it, when a failure happens and all they see on the front end is green 'run completed' it could be confusing.

[jbruce12000]

The idea of generating graphs for delivery to the client is interesting, but complex. There would have to be a unique identifier for each run to make it easy to grab from the logs. I've never tried generating these graphs on a raspberry pi, so I'm not even sure all the packages are available [pdftk,sqlite,python modules]. If everything can be installed, would it run? It takes significant processor time on my desktop to produce. How long would it take on a PI? Would most people understand the output? What docs need to be produced to explain the output? This was intended as a troubleshooting tool for me to help others. Since the code was never intended for general consumption, what needs to change? so many questions.

[captaincaden]

The idea of generating graphs for delivery to the client is interesting, but complex. There would have to be a unique identifier for each run to make it easy to grab from the logs. I've never tried generating these graphs on a raspberry pi, so I'm not even sure all the packages are available [pdftk,sqlite,python modules]. If everything can be installed, would it run? It takes significant processor time on my desktop to produce. How long would it take on a PI? Would most people understand the output? What docs need to be produced to explain the output? This was intended as a troubleshooting tool for me to help others. Since the code was never intended for general consumption, what needs to change? so many questions.

Good points. The more I thought about it, the more I realized that realistically, if the project was made for general consumption, it probably would have the same effect. Just would have to take more steps to get to it.

I was thinking more that the graphing program would be run on the computer accessing the client (of course, this has OS conflict resolution issues too). and that the client would just initiate it after it got the data, and if the program wasn't installed or wasn't able to open it would just return an error after clicking a button in the client. I'm not even sure if it's possible to do what I'm thinking lol. Like the crossing of data and executing other programs from a websocket on a different device like this. Just a thought I had, haha.

[NacMave10]

Back to my suggestion, I feel that the current display gives the wrong impression that the profile was perfectly followed while in many cases, it is not the case. To show this information in the same chart is indeed challenging and I'd agree that the best option would be to generate a dedicated graph. One thing not too complex that could be added to the current view is how long the kiln had to catch up (a duration, or better a percentage of the original profile value). This duration could be updated live.

[jbruce12000]

Well, what's interesting here is that no profile is ever perfectly followed. I get what you're saying though... the current temperature is outside the window [that you set in config] and it has been outside the window for X seconds.

I wonder if this is actionable though. Would you stop a firing because it's outside the window? is it just informational? I guess when folks are first working to tune the PID, having a visual cue of being outside the window would be useful.

[NacMave10]

This would be informational. If this number gets too high, you may want to look into the details, maybe your kiln is just not suitable for this type of profile.

[rondoc]

I have tried to find out why the controller just stopped very near to a completed firing. I checked files but cannot find any data with correct date of the stoppage. Dated files with data on either side of actual date are present in the syslog files. For non coders like me it would be very helpful if upon a stop, for any reason during a firing, the data for that occurrence would be very easily found. Ideas ? (BTW my elements are SiC " globar" type and the resistance changes with temperature so basing kWhrs on just time is not valid. It would take monitoring current so this is outside the scope of this project. ) Thanks Ronald.

On Mon, Aug 29, 2022, 6:35 AM NacMave10 @.***> wrote:

This would be informational. If this number gets too high, you may want to look into the details, maybe your kiln is just not suitable for this type of profile.

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

[jbruce12000]

There are a few cases where I've seen nothing logged at all by the kiln-controller process:

• killing the process
• rpi crash
• power outage [brown out, black out]
• brick that does not supply enough current to the rpi causing outage

At this point, aside from newly introduced bugs, everything that can cause the process to stop is be logged. Feel free to post the logs to new issue so I can take a look.

Sorry you wont benefit from cost changes I'm making.

[chipgarner]

Several of these issues are related to how the code handles the kiln lagging behind the desired heating rate. The kiln goes full on and delays updating the schedule and graph until it gets up to the desired temperature and then continues, as if no time has passed.

This solves the rather important problem of keeping subsequent scheduled ramps in tact. If the time just continued it could miss the next ramp and hit the end of the schedule before the firing was completed.

My Bartlett controller seems to handle this differently. If the kiln lags the programmed heating rate it takes the actual current rate and uses it to extend the rest of the schedule. It uses the actual ramp to compute how long it will take to complete the current programmed ramp temperature and moves the program schedule out by the needed amount. Instead of fixing the lag by waiting, it fixes it by changing the schedule. This means we can graph the actual time and show the deviation from the originally programmed time.

This is related to a couple of other issues, "starting a profile based on what temp the kiln is" and Actual delta-C degrees/hour heating rate". They all depend on how the lag is handled using the timeline. I think all three of these issue are easier to solve with the above method,

The idea is to recover from lag by changing the schedule rather than stopping it.

I am playing around with this and will post if I discover anything useful.

[jbruce12000]

@NacMave10 is this slippage percent based on the total time of the whole profile? or just to the current point in the profile?

just a whole decimal percent? or accurate to two digits like %0.17?

My guess is that for most profiles the percent would be pretty small.

[chipgarner]

Here is an image from the simulator. The kiln falls behind the rapid heating rate at around 1500 f and pushes the schedule out. It meets back up at around 2000 f and follows the rest of the schedule.

The code is a kludge, it just adds 10 seconds to any remaining data point in Profile any time it hits "Kiln must catch up ...". I think the right way to do this is to track the actual ramp rate and use it to compute how long it will take to finish the segment, and then simply add the time to the remaining points.

[chipgarner]

Tracking ramp rate is also useful for seeing if your kiln is working as it should, as mentioned somewhere here, and is related to PID settings. It only becomes relevant if the kiln is full on for some useful length of time.

[jbruce12000]

@chipgarner I'm not sure whether you're baiting me with this conversation or not. I'm going to assume you have good intentions. The kludge in the code, as you so delicately refer to it, was well thought out. It pushes the entire profile out one time step (which in your case was set to 10s) until the kiln catches up and gets back inside the window defined by the user.

Using an estimation of when a complex system is going to reach a specific temperature is impossible. Some ovens/kilns might never reach the target temp. This could happen if the elements are old or if one element died or the user asked the oven to do the impossible, power outage etc etc.

This software is used by potters, glass artists, knife makers, scientists... and each of them has unique ovens designed to do specific jobs. An estimate like you suggest above is unlikely to work in all cases. The "ramp rate" is not static and changes based on temp of the kiln.

If kiln_must_catch_up is set to True, people expect that, based on the name, the profile is stopped while the kiln catches up. Modification of the profile, even if you could accurately predict when it would catch up, is not what folks expect. A lot of controllers have this feature "heat as fast as possible".

[jbruce12000]

I don't think asking the kiln to do the impossible [like heating faster than it can] should be the common case. It should be the exception. This is why kiln_must_catch_up was created in the first place. Some folks want to ignore the capabilities of their kiln and heat as fast as possible.

[chipgarner]

Sorry Jason, I was not clear at all. The kluge is in my code, not yours. Your code adjusts the schedule by changing the start time to now. This changes it by the right amount, which is the important thing, but makes the timeline shown on the graph wrong.

My idea is to add time to the remainder of the schedule instead of changing the start time. I tested this by adding an arbitrary ten seconds each time an adjustment is needed. This works in the example graphed above as the 10 seconds is about right for the time constants and heating rates chosen. It's my quick kludge to show a different way of adjusting and presenting the timeline. It will not work in the real world as is, and as your excellent code does.

To make this work you need to know, at least approximately, the heating curve for the particular oven. A linear ramp rate is not a very good approximation as you said. It may work well enough as the timeline would readjust when the temperature fell below the assumed ramp. If not an exponential curve might, and the constants can be calculated by observing the ramp.

The reason I am interested in this is that I think many people firing ceramics want the kiln to go at its maximum rate for part of the firing so that it finishes as quickly as possible. This tends to be the case most often for larger kilns.

[chipgarner]

@jbruce12000 Apologies again. Also, my kludge is an overly complicated way of dealing with this, as you have basically said above.

Coloring the dots as suggested is an easy first step. Another idea would to have the UI plot the actual kiln temperature in real time. The (proven) kiln controller code would then work as it is.

[jbruce12000]

To have the kiln plot the temperature in real time, you can set kiln_must_catch_up=False.

I think what you're saying though is that the temperature should be flat-lined when kiln_must_catch_up=True until the temperature is reached... this way it shows up in the display.

[NacMave10]

@NacMave10 is this slippage percent based on the total time of the whole profile? or just to the current point in the profile?

just a whole decimal percent? or accurate to two digits like %0.17?

My guess is that for most profiles the percent would be pretty small.

Decimal percentage is for sure good enough. I think that is some cases, this percentage won't be small.

[chipgarner]

I could not find an easy way to change the colors on the graph. It is a really good idea and would also improve the idea proposed here. This is simply to graph the time/temperatures in real time. This is similar to what I proposed above but does not require any changes to how the code works, only what is graphed. The figure below shows the result.

The kiln starts at 25f and the target temperature is 200f. It heats rapidly and overshoots the target, and then settles down to the target temperature. (kiln_much_catch_up is True and pid_controll_window is 5f) The graph depicts this as it happens instead of going straight up as it heats and then straight down in the overshoot. (Note that it would still be great to color the line while this is happening.) The graph then flatlines until the one hour 200f preheat is complete and then starts heating up on the next ramp.

Again, this is exactly how it performs now, only the graph is changed. This example purposely shows a heating rate that the kiln is not powerful enough to sustain. The graph bends over as the heating rate falls behind the profile rate. At 2000f, the profile slows. The temperature graph slows to this rate when the oven temperature finally reaches 2000f and continues at the rate until the hold at 2250f, where it flattens out as in the profile.

The profile includes a cool down. This can be useful to graph in real time as it shows the kiln thermal time constant. It can also give you an idea of how long the cool down will take next time.

Again, this real time graph would also be improved be coloring when the kiln time has stopped updating. It just makes lot more sense to me to see graph with time along the bottom show the actual time that things happen.

@jbruce12000 I am making a pull request to show that this is a pretty minor change and does not impact function, which is working great.

[rondoc]

Sorry to add to this but the kiln constants change with the load of ware. I think a simple approach with the opportunity for modifications by the end user is better than trying to make it a universal kiln controller. Ronald.

On Sun, Jan 15, 2023, 7:28 PM Chip Garner @.***> wrote:

I could not find an easy way to change the colors on the graph. It is a really good idea and would also improve the idea proposed here. This is simply to graph the time/temperatures in real time. This is similar to what I proposed above but does not require any changes to how the code works, only what is graphed. The figure below shows the result.

The kiln starts at 25f and the target temperature is 200f. It heats rapidly and overshoots the target, and then settles down to the target temperature. (kiln_much_catch_up is True and pid_controll_window is 5f) The graph depicts this as it happens instead of going straight up as it heats and then straight down in the overshoot. (Note that it would still be great to color the line while this is happening.) The graph then flatlines until the one hour 200f preheat is complete and then starts heating up on the next ramp.

Again, this is exactly how it performs now, only the graph is changed. This example purposely shows a heating rate that the kiln is not powerful enough to sustain. The graph bends over as the heating rate falls behind the profile rate. At 2000f, the profile slows. The temperature graph slows to this rate when the oven temperature finally reaches 2000f and continues at the rate until the hold at 2250f, where it flattens out as in the profile.

The profile includes a cool down. This can be useful to graph in real time as it shows the kiln thermal time constant. It can also give you an idea of how long the cool down will take next time.

[image: image] https://user-images.githubusercontent.com/9686132/212590157-7e270187-5160-443f-b02f-587db2ca6616.png

Again, this real time graph would also be improved be coloring when the kiln time has stopped updating. It just makes lot more sense to me to see graph with time along the bottom show the actual time that things happen.

@jbruce12000 https://github.com/jbruce12000 I am making a pull request to show that this is a pretty minor change and does not impact function, which is working great.

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

[jbruce12000]

@rondoc I'm not sure I understand your comment. Can you give me a specific case that you're thinking about?

[jbruce12000]

@chipgarner so, are you thinking of having a setting control what graph gets displayed... or maybe a checkbox [or dropdown select box] on the client?

do you want to display just one graph? or both overlaid like your screenshot?

I personally think the overlaid graph is confusing.

[jbruce12000]

This is complete, but since it shows time slippage due to catching up, it cannot be shown on the index page... So I added what I consider to be a "state" page. It shows stuff that I think is useful and describes the state of the kiln.

just go to /state and that will redirect you to /picoreflow/state.html

It has this graph and a lot more.

[jbruce12000]

remember, this is on the main branch. this might be a big change for you.