marlin tft display free sample

Instead of expanding existing 12864 graphical interface I"ve made a new implementation of MarlinUI class dedicated for color screen of particular resolution (128x128).

With MarlinUI class implementation, once you have a working status screen you need to implement about 5 drawing functions to get a fully functional menu.

With new UI working it was a matter of several night to implements new IO subsystem for FSMC and get new UI to MKS Robin TFT. Then I could start working on new display resolution and touch support.

In this video, I am showing you how to connect Bigtreetech TFT35 touch displays to your SKR 1.3 or 1.4 mainboard, why it has two different modes to use it and what to configure in Marlin 2.0 for it.

So, you might have noticed, there is multiple different shapes and sizes of this Bigtreetech TFT35 display available. This one is the TFT35 E3 3.0, which has the knob underneath the display and this fits also in the Ender 3 stock display mount, there is also the regular TFT35 with the knob on the side but they technically absolutely work the same.

The first one is the touch screen mode, where you have a nice color touch display to control your printer, start printing for example, set the temperature and see the status of your printer.

The second mode is the "Marlin" or 12864 simulation mode, which will show the original printer menu from the Marlin firmware running on the SKR mainboard.

But you might ask, why is there two modes in the first place? Is the 12864 simluation or "Marlin" mode there to give you a nice retro feeling if you want it? Well, yes and no. You actually need the 12864 simulation mode in some cases and I"m going to tell you why.

So the display itself has no further logic beyond interpreting and showing that information - being just a dumb monitor. It also sends back the button pushes and controller knob turns to the mainboard but that"s it.

The TFT35 and all other models of this display on the other hand have a full 32bit microcontroller with it"s own memory on board that has it"s own firmware and can be upgraded and programmed independently from the printer mainboard.

The information that is sent back and forth over that serial connection is not pixels. It"s just GCODE commands and GCODE reponses. That makes this display more or less act like a raspberry Pi that runs Octoprint on it or a computer that runs Pronterface for example. And what is shown on the display to you is not controlled by the printer mainboard firmware if you"re in touch mode.

But being independent from the printer also means that the TFT touch display is agnostic to what kind of printer you exactly have. So for example it doesn"t know and it also doesn"t care what kind of stepper motor drivers it has or what kind of firmware it"s running.

The serial cable that comes with your display will have a plug that fits into the RS232 or TFT slot at the back of the display. So let"s plug that in here.

It might be that the display orientation is swapped, that also depends on how you like to mount the display to your printer. So if you need to change the display orientation, you can do this from the touch display by tapping Settings → Screen → and then rotate UI. Then you will need to run through a screen calibration tapping the red dots that appear in the corners and then finally the center.

The next issue you might have could be that the display shows "no printer attached" so that it cannot communicate to the printer. That"s actually normal when you freshly turn the printer on and it should then disappear after a few seconds. If this error persists any longer, your baudrate setting for the serial connection is most probably different from what you have set in Marlin firmware.

This can be fixed by going into the settings menu of the display and then tapping the baudrate setting to switch it between 115200 and 250000. I have set my serial connection speed in Marlin firmware to 250000 at the beginning of Configuration.h, so 250000 should be working. And after a few seconds, the error disappears for mw.

If you find that also setting both sides to 250000 still doesn"t solve the communication issues, you should try to lower the speed in Marlin firmware to 115200, then flash a new build to the mainboard and try again to set the speed to 115200 on the display.

Now, let"s see if we can use the 12864 simulation mode already. Push the dial for three seconds and then select Marlin Mode and confirm the selection.

Sometimes it needs a turn of the knob to get it to work but mine stays black. The reason might be that I have configured the ANET FULL GRAPHICS DISPLAY in Marlin firmware. So I am going back to my Marlin Configuration.h, I am going to comment that out.

Then I am looking for the REPRAP DISCOUNT FULL GRAPHIC SMART CONTROLLER, this is the right setting to enable for the 12864 simulation with the TFT35 and I am uncommenting this line. Don"t confuse this with the REPRAP DISCOUNT SMART CONTROLLER, that"s not the right setting to enable.

Now, I am building and uploading this new firmware for the SKR mainboard with Auto Build Marlin and if you"ve missed my full guide how to do this, I"ve linked that particular video up here for you.

And finally, we can use the print menu to print something from the SD card slot of the display. So let"s insert an SD card with some models here at the side and start a print.

So you can see, that the display immediately changes to a new dialog that shows the printing progress, the current temperatures and we also have access to babystepping and speed adjustment settings from here.

Next up in this series, I am going to show you how to flash the latest bigtreetech firmware to the TFT35 display and also how to customize the UI to show more useful information on the start page, and to be more colorful with custom icons and logos.

Marlin deals with a variety of different displays and needs to display a lot of different languages in different scripts on them, within their capabilities. The system described here solves some of the related problems that need to be overcome with in a limited environment.

Marlin 1.0 and 1.1 currently support: HD44780 (and similar) with Kana charset A00 HD44780 (Page 17) These are very common, but sadly not very useful when writing in European languages.

On all these displays you can define 8 custom symbols to display at once. In Marlin these characters are used on the Boot Screen, and on the Info Screen for the Bed Temp, Degree symbol, Thermometer, “FR” (feed-rate), Clock, and Progress Bar. On the SD Card listing screens some of these characters are re-used again for Up-level, Folder, and Refresh.

Graphical displays provide complete freedom to display whatever we want, so long as we provide a program for it. Currently we deal with 128x64 Pixel Displays and divide this area into ~5 Lines with ~22 columns. So we need monospace fonts with a bounding box of about 6x10. Until now we’ve been using a custom Marlin font similar to ISO10646-1 but with special symbols at the end, which made ‘ü’ and ‘ä’ inaccessible at 6x10 size.

All these languages (except English) normally use extended symbols not contained in US-ASCII. Even the English translation uses some Symbols not in US-ASCII (e.g., ‘\002’ for Thermometer, STR_h3 for ‘³’). In the code itself symbols may be used without taking into account the display they’re written on.

The upshot of all this is that on Western displays you’ll see a ‘~’ while on Cyrillic an “arrow coming from top - pointing to left” (which is quite the opposite of what the programmer wanted). The Germans want to use “ÄäÖöÜüß”, the Finnish at least “äö”. Other European languages want to see their accents too. For other scripts like Cyrillic, Japanese, Greek, Hebrew, … you have to find totally different symbol sets.

The Japanese translator dealt with two scripts, introducing a special font for Graphical Displays and making use of the Japanese extended character displays. Thus he ended up with two pretty unreadable language.h files full of ‘\xxx’ definitions. Other languages either tried to avoid words that included special symbols or just used the basic symbols without the accents, dots… whatever.

Make output functions that count the number of chars written and switch the font to Marlin symbols and back when needed. (ultralcd_impl_DOGM.h) (ultralcd_impl_HD44780.h)

Make three fonts to simulate the HD44780 charsets on dogm-displays. With these fonts the translator can check how the translation will look on character-based displays.

Split ‘dogm_font_data_Marlin.h’ into separate fonts and delete. (+dogm_font_data_6x9_marlin.h, +dogm_font_data_Marlin_symbols.h, -dogm_font_data_Marlin.h)

If you make extensive use, your file will look like language_kana.h and your language file will only work on one of the displays (in this case DISPLAY_CHARSET_HD44780 == JAPANESE).

If you want to make use of more than a few symbols outside standard ASCII or want to improve the portability to more types of displays, use UTF-8 input. Which means defining another mapper.

The mapper_tables do their best to find a similar symbol in the HD44780fonts (for example, replacing small letters with the matching capital letters). But they may fail to find a match and will output a ‘?’. There are combinations of language and display which simply have no corresponding symbols - like Cyrillic on a Japanese display or _vice-versa. In those cases the compiler will throw an error.

In short: Choose a mapper that works with the symbols you want to use. Use only symbols matching the mapper. On Full Graphic Displays all symbols should be fine. Using the graphical display, you can test for bad substitutions or question-marks that would appear on character displays by defining SIMULATE_ROMFONT and trying the different variants.

If you get a lot of question marks on the Hitachi-based displays with your new translation, maybe creating an additional language file with the format language_xx_utf8.h is the way to go.

In this file specify the mapper (e.g., MAPPER_NON) and font (e.g., DISPLAY_CHARSET_ISO10646_1) and translate some of the strings defined in language_en.h. (Remove #ifndef #endif from the defines.)

If there’s no existing mapper for your language then things get a bit more complex. With the Hitachi-based displays you can’t make something useful without a matching charset. For graphical display… let’s take the example of Greek: Find a matching charset. (Greek and Coptic)

If you want to integrate an entirely new variant of a Hitachi-based display. Add it to Configuration.h and define mapper tables in utf_mapper.h. You may need to add a new mapper function.

The length of strings (for menu titles, edit labels, etc.) is limited. “17 characters” was a crude rule of thumb. Obviously 17 is too long for a 16x2 display. So, language files are free to check the LCD width and provide shorter strings in the following manner:

On 16x2 displays, strings suited to a 20x4 display will be chopped to fit. So if shorter string isn’t provided, at least make similar strings different early in the string. (‘Someverylongoptionname x’ -> ‘x Somverylongoptionname’)

All translatable strings are first declared in language_en.h and then language maintainers follow up by providing translations in their own languages. Marlin includes a script named findMissingTranslations.sh which list the strings needing translation for one or more languages.

To find out which character set your hardware uses, set #define LCD_LANGUAGE test and compile Marlin. In the menu you’ll see two lines from the upper half of the character set: JAPANESE displays “バパヒビピフブプヘベペホボポマミ”

If you get an error message about “missing mappers” during compilation - lie about your display’s hardware font to see at least some garbage, or select another language.

MAPPER_C2C3: This is a mapper set by some language files, and indicates that Marlin should use the mapper for Unicode pages C2 and C3. In this mapper, strings are converted from raw UTF-8 input to single ASCII characters from 0-127, and indexes from 0-127 within the combined two 64-glyph pages C2 and C3.

SIMULATE_ROMFONT: Languages can opt to use the HD44780 ROM font special characters on graphical display. This method can be used for accented Western, Katakana, and Cyrillic if they don’t supply their own fonts, or just for testing character-based mappers on a graphical display.

DISPLAY_CHARSET_ISO10646_1: To support a graphical display, a language file must specify either SIMULATE_ROMFONT or a display character set. This specific option selects the Western font for use on graphical display. Others include ISO10646_5, ISO10646_KANA, ISO10646_GREEK, ISO10646_CN, ISO10646_TR, and ISO10646_PL. If no character set is specified, Marlin assumes ISO10646_1.

MAPPER_ONE_TO_ONE: Most character sets on graphical displays (including SIMULATE_ROMFONT) map the character index directly to its position in the upper half of the font. This is possible for character sets that have only 2 contiguous pages of Unicode containing all the special characters. Other mappers use logic or a lookup table to locate the glyph.

The answer to your question (baring in mind that the question is raised for Marlin 1.1.9) is the file ultralcd.cpp. Nowadays, you can also enable extra option through the Configuration_adv.h file, just enable:

This is how I used to do it if you want to add items to the menu in Marlin Firmware through the ultralcd.cpp. It is best to first look at the current implementation of the menu items. As you already mention Preheat PLA, that would be the first to search for. Searching in files is easy when you go to the github website with the Marlin firmware sources, functionality is available for searching in the files. Alternatively, download a copy of the firmware and use a free "grep" utility to search in files.

I was rebuilding one of my 3D printers — again — and decided I needed a display upgrade. A color screen is nice, but there are some limitations. I also found there are ways around these limitations, so I wanted to share my thoughts on a dual-mode color touch screen LCD controller for your 3D printer. The screen in question is a TFT35 from BigTree Tech. It is similar to an MKS screen, but it can operate in two different modes, as you will see.

A few years ago, I picked up an Anet A8 which was very inexpensive, especially on sale. Not the best printer, though, because it has that cheap acrylic frame. No problem. A box full of aluminum extrusion later, the printer was reborn. Over time, I’ve completely reworked the extrusion system and the Y-axis, leaving only the motors, bearings, and the controller/display as the original.

I happened to have one of these lying around so when I installed a new motherboard — a Fysetc Spider if you are curious — I also wired in the new LCD. I had to recompile Marlin, of course, but that’s easy. It all worked, it just looked a little bland.

There’s another way to control a printer, and it’s one you may have thought of before. Since the printer accepts commands via a serial port, you could take a computer like a Raspberry Pi with a nice LCD and just have it issue commands to the serial port. Bonus points if the board has more than one serial port so you can still hook up a PC or a Raspberry Pi running Octoprint or similar. Turns out, you don’t have to build this. The MKS touchscreen uses an ARM chip (it isn’t a Pi, though) and has a touch screen that you can use to control the printer. These come in different sizes and are usually called something like TFT35 for 3.5 inch display.

The advantage isn’t just appearance. Having a bunch of touch screen buttons makes many things easier. For example, if the printer is at (0,0) and you want to jog the head to (100,200), that ends up being a lot of button pushes in Marlin. With the touch display, you can bring up a navigation screen that makes it easy. Or, you can bring up an entire terminal and enter G-code. When you press Send, it shows the results of the command, if any. You can set a temperature with the knob, on-screen buttons, or press the number and type in what you want with a virtual keypad.

These displays are colorful and nice, but there are a few things they can’t do. Marlin has some wizards and user interaction that insist on a proper, local LCD. But the Marlin code thinks the MKS display is a remote host computer, connected over serial. Displays that can act like both types of LCDs are a sweet hack, and here’s the part that was never clear to me before: these displays can switch modes during printer operation. In other words, it is not a case of selecting a mode and rebooting everything. You can be looking at the colorful touchscreen, then switch over to the stock display while printing and then switch back any time you want. The best of both worlds.

On the face of it, the display looks like an MKS TFT. You have colorful menus and a touch screen. The connection for that is a simple two-wire serial port, along with — of course — power, ground, and an optional reset connection. They provide a cable you can use or modify to connect to your setup. There is also an EXT3 port for boards that have that connector.

If all you want is an MKS display, you are done. Since the display looks like a host computer, you don’t even have to recompile Marlin if the serial port you used was active. In my case, the second serial port wasn’t set up, so I had to recompile, but I do that often enough, anyway.

However, if you wire the normal EXT1 and EXT2 ribbon cables to your printer, the display can emulate a normal 128×64 LCD. If you are already set up to use one of these displays, you should not need to recompile Marlin to use this display. However, if you are set up for a different type of display, you’ll need to tell Marlin to use the normal “REPRAP DISCOUNT GRAPHICS CONTROLLER.”

Here’s what I never understood about the device. Looking at the write-up about it on different vendor sites like Amazon, Banggood, or AliExpress, it sounded like you could use the screen in either mode as a static configuration choice. In other words, you might wire up EXT1 and EXT2 and then use the emulated mode until you decided to switch over to serial at some future date. But that’s not how it works. You can connect all the cables and switch back and forth between display systems on the fly.

That’s huge. It means you can have a nice user interface that lets you control the printer, print from an SD card or USB stick, and even make customizations to the menu with the source code provided on GitHub or with a simple configuration file edit. (And, yes, you can add custom menu items simply.) But when you need to do something very specific to Marlin, or a new feature shows up that the LCD doesn’t know about yet, you can simply switch to the Marlin display mode. Then you can switch back.

The process to switch is simple. Just hold down the encoder knob or push the screen for a few seconds. A screen will show up allowing you to pick the Marlin mode or the BTT mode. Just touch the one you want. In Marlin mode, the touchscreen does nothing except switch modes, so you might want to use that method. If you hold the encoder down in Marlin mode, the printer will also see the repeated enter keys until the LCD pops up the selection screen.

Installing the LCD was straightforward save a few problems. For some reason, the pin 1 designation for EXP1 and EXP2 are not consistent among vendors. A Geeetech display worked fine with the Spider board, but the TFT35 didn’t want to come up in Marlin mode at all. I applied power at the serial port and the board appeared hung. The answer was to snip off the alignment tabs on the ribbon cables and flip them 180 degrees.

The serial port was also a mystery. With so little documentation on anything, I just soldered the power and ground wires and then hand twisted RX and TX so I could swap them until it worked. As I expected, the cable needed a cross on those lines to work. You also have to match the display’s baud rate to the port you are using.

After that, it all worked fine. The EXP1 and EXP2 connectors do connect to the board’s reset, so you don’t need to wire the serial port’s reset pin if you have those connected. However, I did notice that switching the mainboard to DFU mode will sometimes fail with the display plugged in. Reflashing the display requires an SD card that flashes a binary file and then reboots and loads fonts and icons. If it is connected to the Spider, it sometimes hangs when trying to reboot during an update. It also works sometimes, though, so I suspect it is just loading on the reset line. In any event, popping the connectors will make it work if you don’t want to try repeatedly.

The display has a number of other ports, but you probably shouldn’t use them. For example, there’s a port for a filament runout sensor. But if you connect it there, it will only work if you are printing using an SD card or USB stick in the display. A better option is to connect it to your printer and tell Marlin to notify the host if a filament break occurs. This will work with the display or something like Octoprint.

In theory, you should be able to connect Octoprint itself through one of the extra serial ports. However, I never got this to fully work. The subordinate port seems to work pretty well, but it never sends Octoprint acknowledgments so Octoprint waits forever or until you force it to continue — use the Fake Acknowledgment button in the terminal. Since the Spider has multiple serial ports, it isn’t a big deal, but in theory, the TFT should work a little better if it can intercept and filter the data stream between the printer and the host software. In practice, I don’t really notice any problems. Some Octoprint plugins like DisplayLayer can send status information to the TFT, anyway.

The truth is, I don’t switch over to Marlin mode very often, but it is nice to have it if I want it, and you can even change the colors to suit you. I really wanted the passthrough mode to work but couldn’t figure out what was going on without digging into the source code, and that might be a project for another day.

Another note: Using the jog keys sets the printer to relative mode. If you are used to popping codes into a terminal, you might want to get used to issuing a G90 before you send a move because the TFT will change it to relative anytime you do a jog.

These displays are inexpensive and easy to interface and since they can still work as a classic display, there’s no reason not to do this easy upgrade. There are plenty of mounting options you can print, of course. The finished result looks great and doing things like moving in both X and Y are much easier with the new display.

I’ve just updated the Marlin firmware on my Sumpod 3d printer since I’m always keen to have the latest features and bug fixes. To be honest, I don’t mess with the firmware that much, and if it wasn’t for the configuration file from my last version, I would struggle to remember what sort of configuration I would need to set in the latest firmware version.

Anyway, while my latest experience with 3d printer firmware is still fresh in the mined, I’ll share some notes about what settings you need to know to get a basic Marlin firmware configured enough to get a 3d printer working. The notes will focus on the Marlin firmware v1 and will include setting up a click encoder and LCD panel. But before going straight into getting the Marlin firmware configured, I’ll first quickly introduce you to a handy tool called WinMerge.

While the latest Marlin firmware continues to be developed, with many new features being added all the time,  I’ve decided to maintain a snapshot of the firmware that this guide is based on. Using this guide with the firmware it is based on will give you the smoothest 3d printer set-up experience.

For anybody that’s in the business of editing and configuring 3d printer firmware files such as the Marlin firmware, I would suggest downloading a copy of WinMerge. It’s free, open source software, and is cross platform, so the same tool will run on Windows and Linux.

You can use WinMerge to compare a clean version of your Marlin firmware against your edited version that you are using on your 3d printer. This will help to keep track and note all the changes made to the files that you might want to transfer to a newer firmware version.

Some motherboards listed in the Marlin firmware configuration file may not have support for some of the options or features available to configure. The notes will be biased towards the Ramps 1.3 board, but the note will still be valid for any Marlin firmware compatible board.

This Marlin firmware will be useful to those who wish to configure their own 3d printer firmware and want information that expands on the comments already made in the Marlin firmware. The notes are a brief guide on what the settings are and how to use them, leaving it up to the person who is configuring the 3d printer to decide what the final settings should be. I don’t guarantee that the information in this Marlin firmware guide is accurate, however, if you spot any mistakes please leave a comment at the end of the post. The Marlin firmware guide is likely to be updated to improve the information where necessary after publishing.

For Marlin Firmware V1 you will need Arduino 0023 IDE to save, compile and upload to the 3d printer motherboard. In the following notes, to edit the firmware, I’ll be using line numbers to reference the location of the code in the Marlin firmware configuration file. Although there is no line numbering in the IDE editor window,  you will see the line number at the bottom left of the IDE showing the current cursor position. Just move the cursor to any line with the mouse to update the line number.

So, to get started, open up the Marlin firmware Configuration.h in the Arduino IDE and work down the notes below. Use WinMerge to compare the changes to a clean non-edited version of Configuration.h for final review before uploading to the 3d printer motherboard.

Line 20 marks the start of the Marlin firmware configuration journey and this is where the baud rate is set to determine the speed of the communication between the printer interface software and the Marlin firmware. Two common baud rate options are defined with one, preceded with two forward slashes (//), commented out to disable. The default enabled option, 250000 baud rate, works well when used with Printrun/Pronterface and RepSnapper software.

You will see a list of motherboards to choose from preceding the code snippet shown above in the Marlin firmware configuration file. The code snippet above defines the Ramps 1.3 as the motherboard, you can select a board just by changing the number to any board that’s on the list. The Marlin firmware will manage circuit board pin assignments to match the motherboard you have selected. Pin assignment details for each motherboard type can be found in the pins.h file of the Marlin firmware.

Now we come to the thermal settings section of the Marlin firmware where things get a bit more complicated, however, we don’t need to touch the complicated stuff to get the printer up and running. Basically all we need to do is select a temperature sensor type for each of the sensors installed on the 3d printer. If you did not install the temperature sensors yourself, you may have to investigate what sensors you do have so that you can select the best match from the list. More about thermistors on the RepRap wiki.

If you are looking at the Marlin firmware configuration file you will see a list of temperature sensor types preceding the code snippet shown above. The code snippet above is setting up the 3d printer that features one hot end and a heated build platform. The temperature sensor selected for both features is 100k thermistor.

If you are using the Ramps 1.3 motherboard with the default pin.h file in the Marlin firmware, the motherboard connectors T0 and T1 will be enabled for the hot end sensor and the heated bed sensor. Changing the 1 to a 0 will disable that sensor. Change the number to select the best match for your sensor from the list.

Some hot ends and heated build platforms might have a maximum temperature rating much less than the default settings in the Marlin firmware, reducing the default maximum temperatures will help avoid accidental damage to the 3d printer if set too high in the interface software.

The Marlin firmware Mechanical Settings section will be about configuring End Stops, Stepper Motors, Build Platform Printable area and Steps Per Unit.

This section will be about configuring end stops in the Marlin firmware that are the limit switches for each axis on the 3d printer. Issuing a homing command from the interface software will cause the 3d printer to mechanically move each axis towards the end stop until the limit switch is triggered.  ENDSTOPPULLUPS will need to be defined where you have limit switches that don’t supply a voltage to the signal pin to generate a digital 1. Enabling pull up resistors will ensure that the end stop signal line will read a digital 1, and when the signal line is shorted to ground by the limit switch, you get a digital 0.

In the Marlin firmware ENDSTOPPULLUPS is defined by default, and ENDSTOPPULLUPS for each end stop connector on the motherboard are enabled individually from line 207. However, commenting out line 194 will only disable ENDSTOPPULLUPS that are also commented out optionally for each connector from line 197. Having this kind of fine tuning makes it easier to configure different types of end stops connected to the 3d printer. You may have mechanical end stop switches for axis X and Y that need pull up resistors enabled and optical end stops that don’t need pull up resistors enabled.

If ENDSTOPPULLUPS at line 194 in the Configuration.h file of the Marlin firmware is commented out, then the code snippet above, starting at line 196, will execute. This code snippet will allow you to configure individual pull ups for each end stop connector on the motherboard. You would comment out a define statement for an end stop where you don’t need a pull up by preceding the line with two forward slashes. You would normally need to enable pull ups when using mechanical end stop type switches that just simply sink the signal pin to ground on the motherboard end stop connector.

You should test the homing command while the axis is positioned at the centre of the travel distance. If you find that the axis won’t move when the home command is sent, then you may have the logic incorrectly configured. Be ready to reset the motherboard or turn off the power to avoid axis crash. Before making any test, complete the Marlin firmware configuration as much as possible. If you can reach the end stops easily, you can trigger them early before the axis has completed it’s travel for a safe test.

The above code snippet found on line 219 of the Marlin firmware Configuration.h file is commented out by default, which allows homing axis to end stops where end stop switches are connected to the X+, Y+ and Z+ connectors on the motherboard.

Normally the above code snippet would not be changed in the Marlin firmware and all the settings would be set to false by default. However, if your 3d printer has a Z axis handle fitted like my 3d printer you might want to disable the Z axis so that the stepper motor can be turned by the Z axis handle while the 3d printer is printing. I’ve often made a Z height adjustment to fine tune the gap between the nozzle and the build bed as the first layer begins to print.

We have reached the part in the Marlin firmware configuration file where you configure stepper motor rotation direction, end stop direction, travel limits and steps per unit. As long as the end stops are configured correctly, the following settings should be easy enough to sort out during testing.

This is where we decide which direction each axis will go when we control the 3d printer through the interface software. When we send a command to move +10mm on an axis, we expect the axis to move 10mm in the direction expected. The initial stepper motor direction can be difficult to predict without switching on the printer and performing a test. So I would suggest leaving these settings till last and complete the rest of the Marlin firmware configuration before proceeding with the test.

Once the Marlin firmware Configuration file is configured enough to operate the 3d printer, you can perform a test to check that each axis move in the correct direction. Set each axis midpoint of their full travel distance and then switch on the printer. After connecting to the 3d printer through the interface software such as Printrun/pronterface, test each axis by jogging them 10mm in the positive direction. The stepper motor rotation direction for each axis can be corrected from line 233 in the Marlin firmware configuration by changing the logic.

You would need to test the extruder stepper motor direction as well. This can be done without filament loaded and bringing the hot end temperature up to 175 degrees so the Marlin firmware will allow extrusion. Send an extrude command through the 3d printer interface software and observe the direction the filament drive gear pulley rotation. The rotation direction for the extruder can be corrected from line 236 by changing the logic.

Basically you tell the Marlin firmware which end of the axis the end stop switch is located. It is common for X and Y axis to home the hot end to the Zero location and Z axis end stop home to the maximum positive location. The code snippet above and the image to the right shows that configuration.

The measurement units are in millimeters and are defined from line 249 for the maximum positions in the Marlin firmware configuration file. The minimum positions can be left at the default 0 for this configuration.

Configuring steps per unit will be one of the last bits of fine tuning you do before you start printing for the first time. Calculating steps per unit accurately will give the 3d printed parts the best start possible. However, if you are just upgrading the Marlin firmware or upgrading from any other firmware, you can get the steps per unit figures from the old configuration file if you still have it.

Steps per unit means the number of steps a stepper motor has to turn to equal 1mm of axis travel. The units at line 275 of the Marlin firmware configuration.h file are in the order of X, Y, Z and E. Getting the steps per unit from another printer of the same design would be very close to what you need, and will help you run some stepper motor tests before you get down to calculating accurate steps per unit for the Marlin firmware configuration file.

To calculate steps per unit (mm) to put in the Marlin firmware configuration file, you need to find a good way to measure axis travel distance accurately. You may have to temporary remove the hot end so that the filament can be extruded in order to make measurements. Using a dial indicator in place of the hot end and a ruler taped to the bed can provide a good accurate way to measured travelled distance. To get the best accuracy you should sample at least 100mm of axis travel. You command the printer to move the chosen axis 100mm using an interface software such as Pronterface. You then measure the actual distance the the axis travelled. Using the formula below you can calculate the new steps per unit.

At this point, you have done enough configuration in the Marlin firmware and can now start 3d printing. If you are interested in LCD display and click encoders, read on.

The last section in the Marlin firmware configuration file is for additional features, this section allows you to configure some of the optional extras you might have attached to your 3d printer. For the purpose of this guide I’m just going to include notes for the LCD 16×2 and the LCD 20×4 with click encoder control panel. The RAMPS 1.3 Arduino shield and my Marlin firmware configuration will be used for this guide.

Enabling an attached 16×2 LCD or click encoder control panel is straight forward in the Marlin firmware. However, the pin assignments for the attachment connectors need to match those in the Marlin firmware pins.h file. You can check if the LCD and click encoder panel features are supported for your motherboard by looking through the the pins.h file of the Marlin firmware. If you are just updating the Marlin firmware you can check for pin assignment changes by comparing your old pins.h configuration file with the new version of that file. Any changes found can be used to update the latest version of the Marlin firmware.

To enable any type of LCD support in the Marlin firmware, ULTRA_LCD needs to be defined. To add support for 16×2 LCD display, line 303 needs to be uncommented like the code snippet above, by removing the preceding forward slashes. By default, the Marlin firmware does not have LCD or click encoder control panel enabled. Enabling line 303 and nothing else will give you support for 16×2 LCD screen that is connected to the motherboard pins as assigned in the pins.h file. Pin assignments are found in the pins.h file of the Marlin firmware under each supported motherboard type.

There are two popular types of click encoder control panels that can be enabled for the RAMPS 1.3 board. The first type is the Ultipanel, which can be found on Thingiverse, and the other type is the RepRapDiscount Smart Controller. For this guide I’m just going add notes for the Ultipanel since the other type is supported by RepRapDiscount RepRap wiki for the Marlin firmware.

Both lines 307 and 331 are not enabled by default. To enable 20×4 LCD display and click encoder, uncomment both lines by removing the forward slashes. This would also enable SD Card support as well, a feature that will be covered in another guide. It will not be necessary to uncomment line 303 if line 307 is enabled by uncommenting. ULTRA_LCD will automatically be defined when ULTIPANEL is defined.

Well that concludes the Marlin firmware guide for now, and I would expect to be making updates going forward to correct errors if any are found or just to improve certain aspects of the guide.

If you have any questions or comments about the Marlin firmware guide, please leave them below. However, if you need Marlin firmware support, this is perhaps not the best place to get it.