Marlin 1.1.8 on CR-10s

TLDR – Get to the changes man! I don’t have all day!

I’m still new to 3D printing, but I’m no stranger to technology. I’ve dabbled in arduino and raspberry pi, so when I found out that’s what is sitting in my CR-10s control box I felt comfortable upgrading firmware. I ran several prints on the stock firmware, but after I made all the rookie mistakes like not leveling the bed right, or figuring out an adhesive process for my first layer, I found that mesh leveling was the way to go. So I did what any geek would do and hit up Google to research how to enable this feature.

I found a great article by (HERE). David Randolph lays out how to update firmware to Marlin 1.1.6 as well as 1.1.7 and even gives the line numbers to each of the features that need changing. I thought it would be similar to jump to 1.1.8, but was I wrong.

David does a fine job at showing you how to edit the configs and uploading the firmware to your printer, so at this time I’m just going to go through the changes I had to make to upload Marlin 1.1.8 to make it work on my CR-10s.


Scroll down for the full instructions and feature changes…

Step 1: First, you need to get Marlin 1.1.8 (Links break… follow the development here if that doesn’t work: )

The release shows up as Marlin-1.1.x and depending on when you’re viewing this post it could be updated to a newer version. So check that first before just flashing blindly.

Step 2: Download my config files at your own risk. They work for me on my CR-10s, but I take no responsibility for you destroying your machine. Download them from Here

Step 3: Extract the then add the config files you downloaded in Step 2 to the Marlin folder (overwriting the ones that exist).

I’m assuming you all are semi-techy and should know to put the files in Marlin folder within Marlin-1.1.x after you extract it.

Step 4: per David’s instructions on compiling and uploading firmware so I’m assuming you’ve already followed his instructions on setting Adruino IDE and loading the libraries. Open the Marlin.ino file (found in the Marlin folder within Marlin-1.1.x folder) in Arduino IDE, compile, and upload.

If you want to follow along with the changes I made and learn a thing or two or see why I did what I did then you need to snag the Marlin 1.1.8 bugfix files Configuration.h and Configuration_adv.h. I found them here:

Trial and Error

I started by making the common sense changes like changing the filament to 1.75mm instead of 3mm. Take the time to scroll through the configuration.h and configuration_adv.h files. The developers include a lot of comments about each feature and are pretty good about letting you know “If you change this you could blow something up so be cautious.”

Some of those types of changes are particular to what you are using, so make the changes that you will find in David’s guide, but realize that some of them can be changed to what works best in your environment. The line numbers have definitely changed, but scrolling through you will see that they are just a few higher in the doc than 1.1.7. I’ll include include the line items for the items I changed in 1.1.8 in a future update.

I uploaded the firmware after making the changes that David recommends and had a slew of troubles. The axis’ were all misconfigured, I couldn’t get connectivity to my octopi, and other problems like inverted movement. So I started looking through the config files and after about an hour I was able to get it going.

PIDtune Fail

I use Octopi running on a raspberry pi 3 (highly recommended fyi) and with my older firmware I started running into a temperature fluctuation issue on my hotend. It was resolved by running a PID autotune which I then installed the PIDtune plugin to make life easier (and more automated).

I have two tasks after updating firmware. #1 – Level the bed, and #2 – run PIDtune to hone in the temp on the hotend. When I ran PIDtune it immediately failed out with a thermal runaway error (completely false positive because nothing was heated yet and temps were showing their typical ranges).

Back to the firmware I went… making changes to the thermal protection features, testing, failing, and so on. It turned out to be a bug with 1.1.8 and that’s why the bugfix files were needed. One problem fixed… several more to go.

Thermal Runaway False-Positives

So there’s two methods for bed heating in Marlin, Bang-Bang and PIDTEMPBED. I’m still researching what each of them is specifically, but from what I can tell is that the Bang-Bang method allows the temperature to bounce for a set period within a certain range. This setting is within the Configuration_adv.h file and deals with HYSTERESIS. I was trying to increase my bed temp to 90 degrees because of my PEI and I started receiving a lot of false-positive thermal runaway errors and the printer would give me a HALTED message. As I dug into it more it I found out that the Bang-Bang method was being used in the firmware. I switched it to PIDTEMPBED and made some changes to the Thermal_Protection section.

All you have to do is uncomment line #394;


Make sure to comment out the following or you’ll receive a compile error:


Thermal Protection Settings:

#define WATCH_BED_TEMP_PERIOD 120 // Seconds
#define WATCH_BED_TEMP_INCREASE 1 // Degrees Celsius

The numbers in red are what I changed. I increased THERMAL_PROTECTION_BED_PERIOD to 90 so that it had more time to monitor the changes, and I increased the THERMAL_PROTECTION_BED_HYSTERESIS to 12 which I hope means that it has a wider range and allow for the bed to do it’s job.

The WATCH_BED_TEMP_PERIOD was increased to 120 in a similar thought to the protection period, and the WATCH_BED_TEMP_INCREASE was reduced to 1. I believe this is waiting to see if the temp will go up 1 degree within 120s. If it doesn’t then it halts.

Break it fix it, break it fix it – Fix it for good!:

No, this isn’t a Daft Punk song, but per the line below I changed the value in yellow to 0.00 (it’s yellow in the firmware, not this post). I can’t recall what the previous setting was, or if this actually fixed anything, but because my X-axis was out of wack I gave it a shot. I would have put it back to the original value if I could recall it. (I know, I could very well go into the original files and see what it was, but my system is running great so I’m going to leave it as is).
#define HOTEND_OFFSET_X {0.0, 0.00} // (in mm) for each extruder, offset of the hotend on the X axis

I originally had the bed center feature uncommented but I had to disable the it so it would home in the right direction. For some reason the firmware was centering 0 in the back right of the bed instead of the front left like I was used to. By disabling this feature the bed now centers in the middle of the bed which is what I want. (see “Safe-Homing” below) The problem was that I didn’t know why so I was concerned that the axis were not properly configured.
// @section homing
// The center of the bed is at (X=0, Y=0)
//#define BED_CENTER_AT_0_0

My theory was right and when I went to level the bed my nozzle hung off the bed at the far X points. I homed again from the LCD and I noticed that my X was at -20 and Y was at -8. So I dug through the configurations.h file again and found this:
// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS -20
#define Y_MIN_POS -8
#define Z_MIN_POS 0
#define X_MAX_POS 300 //X_BED_SIZE
#define Y_MAX_POS 300 //Y_BED_SIZE
#define Z_MAX_POS 400

I changed the X_Min and Y_Min to 0, uploaded the firmware again and voila, it worked as intended. See below:
#define X_MIN_POS 0
#define Y_MIN_POS 0

Safe Homing

This part is up to you. I haven’t done any testing with it yet, but if you define safe homing on this will move the extruder to the position you designate after homing. Mine is in the a little offset from left front of the bed (150 would be the center of my 300mm bed though… get it?)

First you should uncomment the following:

Then, make the changes you see below as you see fit. My values for X and Y are both 110.
#define Z_SAFE_HOMING_X_POINT 10 //((X_BED_SIZE) / 2) // X point for Z homing when homing all axes (G28).
#define Z_SAFE_HOMING_Y_POINT 10 //((Y_BED_SIZE) / 2) // Y point for Z homing when homing all axes (G28).

Mesh leveling

Mesh leveling is awesome… but don’t be a noob like me and enable it in your gcode I found out. You can do this by adding M420 S1; right after your G28 or G29 line. If you’re using Simplify3d you can add it to the start script within the Process Settings. In Cura (3.2.1 at least) you have to go to Settings–>Printer–>Manage Printers–>Select your printer then click Machine Settings. You can add M420 S1; after the G28 code in your Start Code at the bottom.

David recommends using 3 points (which are multiplied out to 9 for mesh) but I like to use 4 which gives me 16 points on the bed. It depends on how warped your bed is really and mine has a few spots that the extra few points help with. As the config file states do not go over 7 (49 points) unless you want to break stuff.

You can make that change with this line:
Line 994 – #define GRID_MAX_POINTS_X 4

Compiling Errors

So I compiled and verified and ran into an error. The console in Arduino IDE is great if the project has error codes and the Marlin devs provided those within the package. So all I had to do was search for the lines that were referenced in the error codes, try to fix it, then re-compile, re-verify, and run into the next error. This happened 3 or 4 times and I don’t recall all of them but they were pretty self-explanatory. You might have to run through a few of these because I fixed them before this write-up. I’ll do my best to remember the changes.

One stated that I couldn’t have the babystep zprobe offset enabled if something else was enabled. I think it related to the leveling feature I had enabled.

The two features I disabled (commented out) in configuration_adv.h was the following:

I don’t use the babystep feature anyhow so disabling a feature related to it was a minimal impact for me.

After that change I got an error that stated the babystep gfx required the zprobe offset. So I disabled that one too:

Moving on from there, the next error was one that must have been added in 1.1.8 because I looked back at previous versions and never had to change these values:

You need to make sure that #define TEMP_SENSOR_0 is set to a value of 1 (according to David’s post) which in every firmware I downloaded so far it was already set. There are sensors that go from 0-4 though then the bed temp sensor. The error that came up stated since I set the value of extruders to 1, I couldn’t have more than one sensor. So I commented those out to disable them:
//#define TEMP_SENSOR_1 1
//#define TEMP_SENSOR_2 0
//#define TEMP_SENSOR_3 0
//#define TEMP_SENSOR_4 0

Finally, the last error (that I can recall) was related to the Autoleveling. I only use mesh (until I get my EZAbl) so I disabled all but the mesh leveling.

The Final Fix

After all that I went to print and found that the bed leveling threw an error in Octopi. I remembered that I didn’t store the settings to eeprom after I leveled so I went through it again on the LCD, stored settings then started a print. Worked like a charm… or did it?

Everything looked good except that the filament was coming out, not going in!! Easy enough fix, just modify this line to false and we’re in business:

#define INVERT_E0_DIR false (Was true)


Feel free to leave comments (scroll all the way to the bottom of the page, the theme is a little weird I know). I’m always interested in helping others out, but also let me know if I messed up. We can’t learn from our mistakes if we don’t know what we did wrong.


2 thoughts on “Marlin 1.1.8 on CR-10s

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s