It would be a great value-add for Octoprint to log temperature data from hotends and perhaps beds and kept running stats on their performance. It seems obvious to me that as components wear out, there will be clear shifts in the standard deviations in the temperature data that can be used to alert the user before there's a bigger problem.
The temperatures are regulated in a closed loop, so this will stay the same over time.
The only proof of 'wear' can be made on different power consumptions. And this will differ depending on the ambient conditions.
So you have to collect more data than just the temperature of the heating components.
I've witnessed my temperature graphs get more and more wobbly over time with some printers. Could be due to heaters wearing out or thermistors becoming loose, or possibly other reasons. I'd like some kind of historical trend overlay shown in the temperature graph so I can get a sense of when my machine's outside of its typical ranges.
Ever made a PID tune?
Yes. I’m not an idiot. But, you have no way of knowing that.
I’ve made custom printers. My first printer was a very early MakerBot. The list goes on.
TLDR; My desire for this feature comes from experience.
Thinking about this request and, as @Ewald_Ikemann pointed out, the temperature control is closed loop I wonder if what needs to be captured is the PID values over time.
When the temperature graph starts to get "wiggly" is often an indication that a PID tune is needed. Capturing the output of that tuning over time may be a better indicator.
Another thought is that one could write a plugin that captures the temperature data with timestamps into an external database. The statistical analysis would not be part of OctoPrint but would be separate software. I believe there are applications designed to analyze time-based data.
Regardless of usefulness, this really is the appropriate answer in any case: this is a plugin. It wouldn't be terribly difficult to log, although producing something useful from the output is what would what would be arguably more complex.
prometheus or one of the influxdb plugins would be a good option for this logging since that's what these systems are kind of designed for.
Certainly it could be done through prometheus (etc) and that's likely how I'll get there on my own. However, I think there's an opportunity here for Octoprint to continue to lead by offering some extra smart functionality.
@b-morgan commented that PIDs should be captured, and I sort of agree, but my original point was that while printing at the same PID tuned temp, over time, I've witnessed the variance in my temperature graphs increase slowly over large numbers of hours of printing. The issue has almost always indicated my heater cartridge needs replacement.
This absolutely could be a plugin, but with the rising pressure from Klipper, I think this might be a fine opportunity to keep Octoprint extra fresh?
No pressure here on that front. Klipper works completely fine with OctoPrint, one does not exclude the other as some people may lead you to believe. Yes there are more performant options with Klipper, but that's because they are purposefully programmed specifically for that platform.
I guess there's no reason to put in the effort then?
In this case you may compare OctoPrint with Mainsail or Fluidd. These are the frontends.
OctoPrint is the server and can support a frontend, Klipper the firmware solution.
BTW: I also run Klipper with OctoPrint
Yes, fair point. I should have said Mainsail. Anyway, I just would like someone to implement this in to core Octoprint. I think it'd actually be useful.
Going further, it'd be really neat to have some running telemetry from printers (who opt in) going somewhere for mass comparison. Probably would be ugly to try to keep hardware variations straight though..
1 Like
This would really be @foosel 's decision, but given the fact that the plugin system was created specifically for this reason (allowing users to install what they find useful) and those existing plugins already existing, I don't see this something getting adopted into core OctoPrint.
I think the cost of the data storage is going to be the limiting factor here; assuming you mean looking at the comparison of temperature over time compared to other user's printer's temperature over time, especially if you want any kind of long-term historical data.