HOW TO: PID Auto-Tuning for Ender 3 and Other 3D Printers

Swings in temperature for your 3D printer’s hot end, such as the Ender 3, is just plain no good for quality print results. Steady, controlled heat is what you are looking for and getting it right can be great for your print results. PID auto-tuning is a way to control the temperature by using an algorithm to determine the values that the printer uses to heat and maintain temperatures. Below you will find the instructions to set your PID values. This method is going to change the values that are stored in your printer, and used every time it heats. This method is great for setting the PID values if you use very similar filament, and cooling most every time you print. If you use a lot of varying filament, or use cooling on some and not on others, you will want to modify your slicer printer settings to set the PID values for each configuration. Lets take a look:

  • First off, use a terminal command processor to send commands to your printer – such as OctoPrint, Repetier Host, or Simplify 3D.
  • Start your printer in a cooled state, with the material you are going to use (such as PLA) primed in the hotend – either from a previous print or heat the printer and push through a few inches of filament and let it cool back down
  • Start the cooling fans if you intend to use them as part of the results you want from the PID test. Send the command M303 E0 S205; to the printer for a temperature of 205C – change the S value to whatever target temperature you are looking to get stable heating for like this:
M303 E0 S205;
  • The printer will take about 5 minutes or so and run through the auto-tune test.
  • When it is complete, Marlin will spit out the test values for P, I and D looking something like this near the end of the output:
Recv: PID Autotune finished! Put the last Kp, Ki and Kd constants from below into Configuration.h
Recv: #define DEFAULT_Kp 27.44
Recv: #define DEFAULT_Ki 3.60
Recv: #define DEFAULT_Kd 52.26
Recv: ok
  • Now tell your printer that you have new defaults, sending in new values for the PID values that you received from the test. In my example I send it the values like this
M301 H1 P27.44 I3.60 D52.26;
  • And it returns a success looking like this:
Recv: echo: p:27.44 i:3.60 d:52.26
Recv: ok
  • Next up, you will want to save your settings to the firmware, or the next time you cycle the power, you will lose the settings, so send the save settings command like this:
M500;

There you go, you should be all set to go with stable PID settings that make your printer produce better prints . A couple of quick things to note:

  1. I have seen some varying settings and re-running the whole thing a few times will give you interesting variations in the values returned. The first time I ran this on a printer, the resulting values produced oscillating temperatures (around +-4 degrees C) which is a little too much. You are looking for tight temperature ranges – I was happy with the settings above that roughly stayed very solid in the 204-206 degree C range. Re-running the test a few times you may find a set of values that really tighten it up for you as well.
  2. Remember, if you are swapping in another brand of filament, a different type of filament (like going from PLA to PETG), or using fans vs. no part fans, you will want to either re-run this test and store them in firmware to use until you change them again, or send the M301 command in your printer profile with each of the values for P, I, and D for the configuration each time you go to print. This method takes a little more work, but ensures that the settings are correct for the config you are intending to use.

That’s it for today, if you have a comment or tip leave it below – we would love to hear from you. Happy printing!

Testing in Production

This is a topic that always draws some great responses when discussed where I work. Do you Test on your production systems?

I always come to the same conclusion on this one. Why wouldn’t you want to test in production? I know, I know. Your system is too “special” or “secure” or “regulated” or whatever to be able to test in production. So what are you going to do? Let your customers test it for you? Throw the code over the wall to the people that matter most and hope that it works for them? Take the chance that your customer will just understand when the house of cards comes crashing down in a burning heap of lame?

To those that say it just can’t be done, I say that maybe your system is just lacking testability – you haven’t built it right. To me a testable system is one that has a great handle on control and is inherently observable. If you can’t control and observe the software, you are dead out of the gate. Often, if you solve the control and observation issue, you will find a system that you can test in production – because you engineered it to be easy to do so in any environment.

So take a look at your systems and ask yourself if there are any measures you can take to affect the testability of your system in a way that would lead you to be able to test your system in production. Face it, no matter how you try, your QA systems will never be the same as your production systems. The data, traffic, configurations, scale, timing, etc. will just never match well enough that the tests you run in those environments will catch everything. Change control, make it observable and make sure your system works in production before your customer does it for you!

Centralized vs. Federated Integration Test in the Enterprise

I have been working on the question of federated vs. centralized integration test practices in the enterprise lately. As I have done some research into the topic, I have found that few resources are around on the topic. While some white papers exist, it appears that most companies are in the federated camp: relying on individual divisions to create their own integration test strategies – even when there are many ties among their applications that could benefit from a centralized approach.

Some companies like Google have extremely large tests that involve many applications, and even automate them to some extent. Most though, including the ones that I have worked for, spend time testing software from within their respective silos in an effort to protect their own. Each of these groups tend to create and maintain redundant sets of tests that cover their application needs.

The problem is that many of these needs are the needs of many of the other groups and a great deal of redundant and poorly performing tests are written. Every group creates a test to “create a user and password” for instance. Each is created in their silo and when the functionality changes, each breaks in their own way. Tests that perform things as trivial as this, and of course much more elaborate are created all of the time that could be shared.

Creating a centralized integration test group may be able to fix this redundancy issue and help protect production quality as you do so. Sharing resources, test data management, and testing know how might be a way to create a group that solves the issue of poor communication across your organization when it comes to system integration test. This one set of testers will help build the “moat” that protects your production castle from impending doom.