Slowly but surely, the chapter called Original Prusa i3 MK3S+ will have to come to a close eventually, although we’re not planning to drop the support tomorrow. Either way, the MK3 series had a long and wonderful run. The first units were sent in late 2017 and we’ve been working on updates and improvements ever since. The recent firmware releases brought important additions to an already long list of safety features, particularly the Thermal Model Protection system that continuously checks whether your printer performs as expected with pinpoint accuracy. We had great safety systems in place from the start, but there’s always room for improvement.

Thermal Model – Quick Recap

The 3.12 firmware for the MK3/S/+ brought a new safety feature called Thermal Model Protection, which we covered in an extensive article.

So, just a quick recap: We’ve introduced this new protection feature to quickly identify and address unexpected heating issues in your 3D printer. The objective is to stop the heating process within 10-12 seconds to prevent any potential damage. These issues encompass various factors such as wiring problems, malfunctioning heater blocks, thermistor faults, and external variables like drafts and the formation of extruder blobs.

This functionality relies on an internal hotend simulation. The firmware continuously monitors the thermistor readings to ensure they follow a predefined thermal model pattern. If any irregularities are detected, the printer responds within seconds by displaying a “THERMAL ANOMALY” warning, which disappears once the readings return to their expected values within 5 seconds. If the anomaly persists, the printer will deactivate the heating and trigger an audible warning to alert the user.

The question is: what happens if your 3D printer is heavily modified?

Collecting the data

We analyzed over 150,000 measurements to create the thermal model for our stock MK3S+ 3D printers. Basically, we checked the ranges of various parameters (temperatures, power output, time) and created a general profile that could be applied to all our printers safely. This meant pushing the printers to and beyond their limits (yes, there was smoke). For example, we used a custom heater block with space for 2-3 thermistors, so we could plug in a broken thermistor along with a fully working one and compare the two in real time.

However, it wasn’t in our power to test every single available modification to our printers and prepare individual thermal models. Our printers are open-source, and everybody is free to tweak, tune and hack them in any way they see fit, but since safety and reliability are among our top priorities, we had to draw an unpopular line somewhere. The Thermal Model was it.

Shortly after release, we started receiving reports from various users. Some of them were in fact the printer’s screams for help. The Thermal Model Protection kept bothering the users simply because their printer’s components were damaged and had to be replaced. Whenever the new system threw an error, it was serious. Our recommendation is pretty clear in this matter: if your smoke detector starts annoying you with constant beeping, the solution isn’t to remove its batteries. Same with the new firmware safety features. Of course, that doesn’t mean that the firmware is 100% bulletproof – we already identified and resolved a couple of unusual cases. So if you have a stock MK3S+ and the protection system is giving you trouble, rather than “removing the batteries from a smoke detector” please contact us and we’ll be more than happy to assist you.

So those are the stock and user-modified printers. And then there is the Revo.

The Revo hotend made by our friends at E3D is a popular alternative to the MK3S+ stock hotend. Even though it’s a great piece of hardware, it’s still a third-party modification. Since our team was fully dedicated to finishing the MMU3, the Revo had to be tackled in a different way. Fortunately, the Revo has very consistent characteristics.

Measuring the Revo

Due to the limited capacity of our dev team, we turned to our community for help. Many GitHub users rushed in to assist us – our biggest thanks go to alexiri, kromeninja, ulab, JWvP, snafu1282, matthiazzz, sdh2, devejhilton D-an-W and MaroonOut09 just to name a few. Thank you, everyone, who chipped in and helped us shape firmware 3.13, your contributions are most appreciated!

We asked community members to measure temperatures and fans under specific conditions. The response was amazing and we were able to collect at least some initial data pretty quickly – one of the things that also helped is the fact that Revo hotends have consistent properties across the entire range of manufactured hotends.

Once we had collected the base data, we prepared an update for the thermal model which was distributed as an experimental firmware to double-check whether we got it right. As it turned out, it was a step in the right direction. The results were promising, but we needed a larger sample. We couldn’t collect enough data from community members and we also didn’t want to use way too generic (wide range) values because that would render the protection system much less reliable.

Meanwhile, we were waiting for E3D to deliver us their official data. E3D needed to check various batches of their Revo extruders to find the edge values, so we could see what is the range for various parameters. Once we obtained these values, we could finally make the last step: compiling everything into the firmware file.

Eventually, we settled on a separate set of binaries – it’s easier to flash the right firmware file rather than adjust values in Settings. And what’s more: with these systems in place, we can now easily add your thermal models – if you would like to add support for Thermal Model Protection for your third-party hotend, get in touch with us and we’ll get you up to speed.

More community contributions

We have released the new 3.13.2-RC1 firmware recently and it features even more community contributions. The 8-bit architecture is severely limited (so it won’t be able to run, e.g., Input Shaper and Pressure Advance), but it’s always awesome to see how code optimizations can save valuable bytes. With the recent changes to the code, we were able to save 6 kB of internal flash memory (even with the MMU3S and Thermal Model in place). This gave us more space for community-made additions.

We have implemented the “En-/disable Fil. Sensor” functionality submitted by Commod0re and also the support for the M118 G-code by Robomagus which enables sending of messages (Serial print) to hosts like Octoprint or PrusaLink.

And last but not least – in firmware 3.13.0, we’ve implemented support for Meatpack provided via pull requests by scottmudge! This is an exciting development because Meatpack essentially allows for G-code compression with a ratio of ~0.61 with only a little processing overhead.

And that’s all for today. I hope you enjoyed a little sneak peek into our firmware “kitchen”. We’ll be sure to bring you more dev diaries in the near future.