Upgrading a Robo3D R1+ Mainboard

by Roderick W. Smith, rodsmith@rodsbooks.com

Originally written: November 30, 2020; latest revision: January 19, 2021

This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!

Donate $1.00 Donate $2.50 Donate $5.00 Donate $10.00 Donate $20.00 Donate another value


This page documents my experiences upgrading the control board on a Robo3D R1+ 3D printer from its original 8-bit board running Marlin to a new 32-bit board running RepRapFirmware. This now-discontinued printer is a fairly typical Cartesian i3-style printer. If you don't know what any of this means, chances are this page isn't for you. If you do understand it, though, and if you're interested in improving the functionality of your Robo3D R1+ (or of another 3D printer), then read on!

Note that installing a new motherboard in a 3D printer requires familiarity with handling electronics, possibly including crimping new connectors, soldering, and using a multi-meter. You don't need to be a master at any of these things, but you'll likely have to do more than unplug wires from the old board and plug them into the new one. In addition, my project involved installing a bleeding-edge firmware build of a type that's not officially supported by the new board's manufacturer. Finally, I installed a new LCD control panel, again replacing the firmware with an unsupported community-developed branch. You should undertake such a project only if you're comfortable with these tasks, or are willing to learn (and possibly do damage to your printer in the process). Scaling back the project to avoid tasks that give you pause is possible; use your own judgment about how much to undertake.

The index to the left shows the overall structure of this page.

Setting Goals

The Robo3D R1+ is a low-cost Cartesian i3-style printer from the mid-2010s

Figure 1: The Robo3D R1+ is a low-cost Cartesian i3-style printer from the mid-2010s

In late 2017, I purchased my first 3D printer: a Robo3D R1+. (Figure 1 shows this printer after my upgrades.) At the time, I found the printer to be frustrating and unreliable; however, I was fascinated by the technology, and I went on to build an entirely different 3D printer (a Kossel XL delta printer design). Three years after buying the Robo3D, I decided to begin upgrading it to make it more reliable and more versatile.

One of the big problems I had with the Robo3D, from the start, was its very primitive and awkward control firmware, Marlin. Although Marlin is popular in the 3D printing world, I disliked it. Changing certain options (such as adding an LCD control screen) requires making changes to source code files, recompiling the firmware, and uploading an entirely new firmware build to the control board. What's more, I had problems with inconsistent bed leveling and with the two Z axis lead screws turning unequal amounts, leading to a tilt in the X-axis gantry that would eventually cause failures when bed leveling via the G29 command. Turning off the hotend heater and then turning it back on again before the hotend cooled down, or changing the temperature before it reached its original set point, would raise a spurious thermal runaway error, which was extremely frustrating. All of these problems should be correctable in firmware, but if there were in-Marlin solutions, I wasn't able to find them.

I much preferred the RepRapFirmware used by the Duet 2 WiFi board I used in my Kossel. In addition to providing a simpler way to configure the printer, RepRapFirmware and the Duet line of control boards provide a Web interface (the Duet Web Control, or DWC) to the printer, enabling uploading files to print via a Web browser (or direct from some slicers), which simplifies the printing process. Similar functionality can be achieved via the OctoPrint software run on a Raspberry Pi. In fact, I used OctoPrint from the start with my Robo3D, but it's not quite as flexible as RepRapFirmware's DWC, in my experience. Using OctoPrint also does nothing to address all the Marlin frustrations I experienced.

The Robo3D's control hardware consists of an Arduino MEGA 2560 and a RAMPS shield. This is a common 8-bit control system, and it's adequate for controlling a Cartesian printer; however, it cannot run RepRapFirmware or other more sophisticated firmware implementations such as Smoothieware, which are designed for 32-bit control boards. Although there are other 8-bit firmware options, replacing the 8-bit hardware with a 32-bit control board seemed like the best way to go. To be sure, a 32-bit CPU is overkill for this printer; but it's worth it to be able to run RepRapFirmware.

A less important problem with the original configuration is that it uses Allegro A4988 stepper driver chips. These chips are popular on low-end 3D printers because they're cheap and reliable; but they are noisy and they're known to create minor surface printing artifacts. Thus, I wanted to replace these chips with something better.

The Robo3D R1+ has five stepper motors: one each for the extruder, X axis, and Y axis; and two for the Z axis. This dual-Z-axis configuration is a good design feature, but as I noted earlier, the two Z axes frequently fell out of alignment, particularly near the top of tall prints. Although it's possible to control two stepper motors via one driver chip, independent control seemed desirable to me, meaning that any board I'd buy would have to support at least five independent drivers. Furthermore, I would like to eventually install two extruders on the printer, with appropriate hot end support, for two-color and/or multi-material printing. This will require another stepper motor and driver, for a total of six. (Alternatively, I could drop back to controlling both Z-axis motors via one stepper using a splitter or, with some boards, a second plug connected to the Z-axis stepper driver on the control board.) Support for at least two hotend heaters may also be desirable, depending on what solution I pick for my eventual multi-extruder configuration.

To be clear, the problems I've just outlined are only the beginning of my difficulties with the Robo3D R1+. Other problems that are not directly addressed by a control board upgrade include the unreliable mechanics of its bed leveling system, difficulty loading filament, excessive ringing/ghosting artifacts, heated bed temperatures that drop off at the edges, a delicate glass bed that's been accumulating chips for years, poor printing tolerances (making it impossible to print certain print-in-place movable objects), and more. This upgrade is only the first of several that I'm likely to perform. I may try replacing some bed components to make it flex less and/or install a BL Touch or similar bed-leveling system to replace the Robo3D R1+'s flaky touch-based system; or I may upgrade the extruder and hotend to something that's easier to load and that provides dual-filament support. Ultimately, I think the Robo3D R1+ can be turned into a decent i3-style printer, even though it was disappointing out of the box.

Selecting Components

With these design goals in mind, I began researching control boards. The need for six stepper drivers in a 32-bit board severely limited my options. Some possibilities (in late 2020) included:

In addition to the main control board, I wanted an LCD control panel. To be sure, many users of RepRapFirmware don't bother with such a control panel, instead relying on Web browsers on computers, tablets, or smart phones near their printers. I find it convenient to have a dedicated user interface that doesn't require logging in, though. Broadly speaking, there are three classes of LCD panels that can be used with RepRapFirmware:

I like the idea of supporting innovators in the 3D printing space, so I was initially drawn to the Duet 2 WiFi and PanelDue; however, the price for this approach was off-putting, particularly when adding the expansion board for my eventual move to a dual-extrusion setup. Also, I already own two of these boards — one for my Kossel XL and another for a SecKit SK-Go2 that I'm about to assemble. I was curious about how RepRapFirmware would work on third-party hardware, and BTT seems to do a better job than most Chinese compnies at honoring open source principles, so I decided to give the BTT SKR Pro v1.2 a try, along with a BTT TFT35-E3.

In addition to these components, some others were required:

The total cost for all of these components was about $150.

Printing Parts

Replacing the motherboard of a 3D printer usually requires making some physical changes or adapters because the boards' form factors are not standardized. That was definitely the case for this upgrade. The most difficult part of this process for me was designing a mount for the new board. As detailed shortly, in Installing Hardware, I also needed to literally hack away parts of the inside of the printer's plastic case. To begin, though, I printed the following parts from Thingiverse:

If you use another control board or screen, or if you're upgrading a printer other than the Robo 3D R1+, you may need to find other printable parts to facilitate the upgrade.

Installing Hardware

The new mounting bracket secured in the printer

Figure 3: My mounting bracket in the printer

Swapping a control board on a 3D printer is simple in principle, but a bit tedious in practice, because so many wires connect to the control board, and you must keep track of which wires connect to what components during the swap. In addition, the connectors used on the wires may not match the new board, and so may need to be changed. Wire lengths can also be a problem.

Although the BTT SKR Pro fits in the space where the original control board fit, there wasn't sufficient clearance for some of the wires that plug into the board. Thus, I used a Dremel tool to cut away part of the interior dividing wall in the printer, so as to give me sufficient access to the board's connectors.

I used a combination of Elmer's glue and screws to secure the mounting plate in place. Figure 3 shows the bracket installed, with part of the dividing wall cut away. This plate mounts over two small standoffs inside the printer; one is under the bottom-right standoff on the mounting adapter (as oriented in the photo, with the printer on its left side), and you can see the screw securing the other one in Figure 3. The screw used to secure the bottom-right (as oriented in the photo) corner of the new board both secures the board to the adapter plate and helps secure the adapter plate to the printer's case.

The board mounts on its bracket with its USB port and micro-SD card slot facing the center of the printer

Figure 4: The board mounts on its bracket with its USB port and micro-SD card slot facing the center of the printer

Fan and hotend terminal blocks are on the same edge as the micro-SD and USB ports, making direct outside access to those ports difficult. Thus, I mounted the board with those items facing inward and used extension cables to provide outside-the-printer access to these ports. I drilled two screw holes next to the printer's existing USB port access point and mounted the USB extension cable there. I designed a mounting adapter for the micro-SD card extension that fits in the same slot as the printer's original SD card reader; this design is part of the same Thingiverse project as the SKR Pro mounting plate. Figure 4 shows the new board mounted in the printer, but with almost nothing wired up.

The bulk of the physical installation work involved wiring up the new board. As I removed the original board, I used masking tape to label each wire. One challenge is that the wire connector types didn't match. The original Robo3D wires used a combination of Dupont and Molex KK connectors; but most of the sockets on the SKR Pro board use JST XH connectors. Fortunately, Dupont connectors can fit in JST XH sockets, although they might not be optimally secure, and their orientation is not idiot-proofed. JST XH pin headers are smaller and harder to crimp than their Dupont counterparts. For these reasons, I left the Dupont connectors as-is, paying careful attention to orientation when that's important. Most of the components that used Molex KK connectors were fans or LEDs, and the matching sockets on the SKR Pro were all screw terminals, so I swapped the Molex KK connectors for ferrules to connect to the screw terminals. The two thermistor wires used Molex KK connectors, but their equivalents on the SKR Pro are JST XH connectors, so I needed to cut the wires and crimp on new connectors.

I have some notes on specific connections:

Overall, physically swapping the boards went about as well as I'd expected. Designing the mounting plate was the most time-consuming part of the job, since I needed to print several prototypes before I settled on the final design. If you upgrade your printer in exactly the way I did, or if you can find an existing mount for your printer/board combination on Thingiverse, you won't run into this problem. The second biggest problem was ensuring that the various wires were firmly secured. I had problems with some of them coming loose during testing, but the setup seems to finally be stable.

One issue deserves special mention: Using the ESP8266 WiFi board I purchased, it is not possible to update the WiFi board's firmware without jumping through some extra hoops. Two approaches are possible:

I performed my first WiFi firmware update using the first method and it worked fine. I then put together a two-wire cable, with a JST XH connector on one end and an eight-pin Dupont shell on the other, with only the two required pins attached. Figure 6 shows the SKR Pro end of this cable, half inserted into the motherboard. I added the following line to my board.txt file to support this configuration:

8266wifi.serialRxTxPins = { PC.7, PC.6 }

Of course, if you use another motherboard, or if you use something other than the serial input on the SKR Pro's ESP-01S socket, you'll need to specify other pins. In any event, with this configuration in place, I was able to downgrade to my previous WiFi module firmware, then re-upgrade to the latest, as a test of this configuration; it worked fine. Time will tell whether the cabling stays put. It could easily be shaken loose from the WiFi adapter module because of vibrations as the printer operates, although at least the JST XH housing is on top of the WiFi module, so gravity is working in my favor.

Configuring RepRapFirmware

Physically replacing a 3D printer motherboard is only half the job; the new board must be told about the hardware it's controlling. Installing RepRapFirmware on the board is quite easy:

  1. Download the appropriate firmware version for your board and configuration from the LPC/STM32 RepRapFirmware Releases page. Pick the filename with lpc or stm32f4 for your board's CPU type, and with esp8266wifi or sbc, depending on whether you want to use an ESP8266 module or a Raspberry Pi SBC configuration. If you're using a genuine Duet3D board or a clone of one, it should come with RepRapFirmware pre-installed, but you can install an updated version from the Duet3D github page.
  2. Rename the firmware-{cpu}-{wifi}-{version}.bin file to firmware.bin and place it on a micro-SD card.
  3. You must also prepare several other files and directories, as described in the LPC/STM32 RepRapFirmware wiki. (This wiki suggests fully configuring the printer at this point. This is possible; but you can also start with a generic configuration file and fully configure the printer later. I describe printer configuration shortly.)
  4. Insert the micro-SD card into the board and power it on. If you can see the board, you'll see an LED blink as it copies the firmware file to its internal storage

That's basically it for firmware installation. You should be able to connect via a USB port and use Pronterface or a terminal program to connect to the printer and issue an M115 command. The response should reveal that the board is running RepRapFirmware, like this:

FIRMWARE_NAME: RepRapFirmware for STM32F4 based Boards FIRMWARE_VERSION: 3.2-beta3.2_1 ELECTRONICS: STM32F4 FIRMWARE_DATE: 2020-11-13

The next step is to get the printer connected to the local network. LPC/STM32 boards require changes to board.txt so that the firmware knows how to find the ESP8266 module. For the SKR Pro, see this wiki page for details. If you build the ESP8266 module yourself, it will also need to be flashed with the DWC firmware, as described earlier; but mine came pre-flashed, so I didn't need to do that. With these items configured, the rest of this task is covered in the Duet3D wiki. It involves issuing a series of g-code commands to tell the ESP8266 module about your local WiFi network and to connect to it. (You can also enter these commands in your config.g file. Some of the commands need only be issued once, though, and they hold your WiFi password, so you may prefer to do it manually, as I did.) With that done, it should be possible to connect to the printer via a Web browser, and it becomes possible to set up all the printer-specific details, such as the printer's bed size, thermistor type, stepper driver configuration, etc.

Duet3D provides a Web-based configuration tool for RepRapFirmware; however, this tool won't quite do the job for printers running the LPC/STM32 port of RepRapFirmware. Instead, a fork of the configuration tool for these boards is available. Thus, if you're upgrading a printer other than the Robo3D R1+ or using a control board other than the BTT SKR Pro, you should start with whichever of these sites is appropriate for your control board. You may need to make manual changes beyond what the Web configurator can handle. I saw no way to set up a dual-Z-motor configuration using the Web tool, for instance, so I had to edit config.g manually. Once you have a configuration, you might want to compare the resulting config.g configuration file with the one I present shortly; most of that file's settings should apply to other control boards, if you're starting with the base Robo3D R1+ hardware and setting it up in a way that's equivalent to my configuration (in particular, the independent Z axes and my fan/LED configuration).

If your configuration exactly matches mine, or is very close to it, then you may be able to use my configuration files with few or no changes. I'm presenting both a .zip file that bundles all my configuration files together and a few individual files so that you can peruse them online:

Before you try to use my configuration files on your printer (or use those generated by an online configuration tool), you may want to note a few points:

After configuring the firmware, I began testing the printer. I did this in steps — I checked that I could home and control each axis, checked that each axis moves approximately the amount I expected it to, tested the hotend and heated bed temperature controls, tested and calibrated the extruder, and so on. I ran into numerous minor problems. Many of these were caused by loose electrical connections. Others were configuration options that needed tweaking — the Robo3D R1+'s unusual bed probe was particularly tricky to set up.

I performed a PID tuning of both the hotend and heated bed, as described in the Duet3D wiki page on this topic. This process is similar to the same task using Marlin or other types of firmware, so it's probably familiar to you. I saved the results to config-override.g by typing M500 in the DWC's console. I've copied the resulting M307 lines over to config.g. If you're using the Robo3D's original hotend, these values should be close to correct for you, but re-tuning for your own printer is advisable. Be aware that the RepRapFirmware developers implemented a new PID tuning mechanism in version 3.2-beta3.2, to which I upgraded just days after installing my upgrade. My sample files provide the PID tuning values created by the new tuning algorithm.

The Robo3D bed probing mechanism produces a poor height map

Figure 7: The Robo3D bed probing mechanism produces a poor height map

Near the end of my configuration process, I tried running a G29 mesh bed leveling command. This command is supported by Marlin, and the sample slicer start g-code provided by Robo3D places a G29 command at the start of every print. With RepRapFirmware and the configuration created by the online configuration tool, the process was more thorough (110 probe points vs. 9 with Marlin), and therefore time-consuming. One of RepRapFirmware's great features is that it can display a 3D graphical representation of the bed surface, as shown in Figure 7. As you can see, the result is pretty bad — the deviation across the bed exceeds 0.5mm. I got very different results on some subsequent tries, though. Some of these were better than shown in Figure 7, but others were just as bad. I suspect that the bed level may be affected by removing and replacing the printer's bed. Perhaps this is why Robo3D's sample slicer configurations include a G29 command at the start of each print. As a compromise, I'm manually running a G29 whenever I adjust the bed in any way, but not at the start of each print. (See the upcoming section, Adjusting Slicer Profiles, for information on how I've adjusted my slicer configurations.) Another option, of course, would be to adjust the mesh grid settings (via M557 in config.g) to be less thorough, thus making it reasonable to run a G29 at the start of each print. It's best to run the G29 command with filament removed from the printer and the bed and nozzle thoroughly cleaned. If filament is loaded during a bed probe, the nozzle will leave little specks of filament behind; and if G29 is run again, these specks will throw off the second probe's results. This is awkward if a G29 is run at the start of each print, of course.

My first test print suffered from layer shifts because of too-high acceleration values

Figure 8: My first test print suffered from layer shifts because of too-high acceleration values

At this point, I began printing, but my first test print was not perfect — it came out with some pretty severe layer shifts on the Y axis. It turns out that I erred in copying the acceleration values (set via M201 in config.g) from my Marlin configuration. This produced far too aggressive acceleration, which resulted in failures. I corrected this problem by reducing the acceleration values. Figure 8 shows my first and second prints (of a simple calibration cube) side-by-side. Once the layer shifting was fixed, I slightly tweaked other settings over the following days to optimize my prints. (My configuration files, referenced earlier, incorporate these changes.)

For some reason, although the steps per mm settings I computed based on my old Marlin configuration for the X, Y, and Z axes were spot-on, this was not true of the equivalent setting for the extruder; I needed to calibrate the E stepper. I found that the optimum value was 3105 steps per mm with 1/64 microstepping. The Marlin configuration for the printer specifies 723.38 steps per mm with 1/16 microstepping, which should work out to 2893.52 steps per mm with 1/64 microstepping — that is, I need over 7% more steps per mm than the stock Robo3D configuration would suggest. On the other hand, a third-party updated firmware specifies 800 steps per mm, which works out to 3200 steps per mm at my 1/64 microstepping, so that's much closer to my figure. Perhaps the discrepancy has to do with different brands or types of filament. (I used Hatchbox PLA for my calibration.)

Configuring the BTT TFT35-E3

The LPC/STM32 wiki has a page on connecting various LCD control panels. I initially found that omitting the serial.aux.rxTxPins line in board.txt was necessary; all of the provided examples resulted in the LCD panel being unable to communicate with the motherboard. I later discovered that the following line in board.txt would also work:

serial.aux.rxTxPins = { A.10, A.9 };

As noted earlier, I used the displays's default 115,200 baud rate, which must be set to the same value on both the printer and the display itself. (I also tested with lower baud rates, including RepRapFirmware's default of 57,600 baud, but the only effect was to slow down some operations.) Activating the control panel requires an M575 line in config.g, the details of which are described shortly.

The BTT TFT-series LCDs' firmware can be updated, and their configuration changed, by copying firmware files (with .bin filename extensions), a font and icon directory (with a name like TFT35, with the number changed to identify the screen size), and config.ini configuration file (for the original BTT firmware only), to an SD card. When that card is inserted in the display and the display is reset or powered on, it will read the relevant files and update itself. (This does not work if the files are placed on a USB flash drive; the update works only via an SD card.) It's possible to update only the firmware file or config.ini file in some cases, although if the new firmware requires icons it can't find, it will insist that you make them available to it.

Literally hundreds of forks of the display's firmware are available; however, I know of two that are worth considering (with two other predecessors of one of these):

In January of 2021, Thro42 announced that he was working to add RepRapFirmware-specific features to the official BTT build of the firmware, starting with adding the ability to print from the motherboard's micro-SD card. As of late January, that task is incomplete, and in fact the latest version I tested (downloaded on January 18) was badly broken — selecting a file to print from the motherboard's micro-SD card resulted in an error message and a frozen display. (This problem was caused by code added by another developer that broke Thro42's new features.) When I initiated a print from the DWC, it worked fine, although the display did not show the status screen (described shortly). Thus, as of January 18 of 2021, the original Thro42 fork is still my preferred firmware for my TFT35-E3; however, that could change at any time.

Initially, all three of the RepRapFirmware-optimized variants had problems communicating with my SKR Pro motherboard, although the original BTT version did not. The forks seldom connected when the printer was first powered on or reset, but they did connect if, ironically, the "disconnect" option was selected from one of the sub-menus. What's more, these versions of the firmware would often stop communicating with the printer when certain operations were performed manually, such as homing the print head or displaying a list of files to print (or macros, in the case of the Thro42 variant). These problems did not affect the original BTT version of the firmware.

I eventually discovered a fix for these problems: Although the firmware documentation specifies passing an S3 parameter to M575 in config.g, it's actually necessary to pass an S1 parameter, thus:

M575 P1 S1 B115200                             ; enable support for PanelDue

According to the Duet3D wiki, S3 identifies "raw mode with checksums," which is how most g-code-based LCDs communicate, whereas S1 specifies "PanelDue mode, checksum required," which seems to imply a PanelDue-specific communications mode. In practice, it seems that the developers of the forks have, whether intentionally or not, made their forks work better with this PanelDue-specific protocol than with the more generic one.

With the S1 version of the M575 command in place, the Thro42 fork began working fine, without any communications glitches. The LCD panel does take a few seconds to connect to the printer, though, when it's first powered on or after a reset. During this time, a flickering "Connecting..." message appears on the screen. When the LCD connects, it beeps and shows the printer's IP address.

If you use the original BTT version, or some other g-code-based display that's not optimized for RepRapFirmware, you should probably pass S2 or S3 instead of S1. (S2 is just like S3, but without checksums. Thro42 has recommended use of this variant with the latest BTT firmware that incorporates his extensions.) Thus, you'd use:

M575 P1 S2 B115200                             ; enable support for TFT35-E3

To make the latest versions of the official BTT firmware work with the motherboard's own micro-SD card, you'll also need to set an option in the config.ini file on the display:


This setting defaults to a value of 1 ("auto-detect"), which does not (currently) work with RepRapFirmware. As development is proceeding, this detail, and others, are subject to change without notice. If you have problems or questions, I suggest you ask them on the #tft-screen-support LPC/STM32 Discord channel.

When printing, the TFT35-E3 shows a special print status screen

Figure 9: When printing, the TFT35-E3 shows a special print status screen

Depending on the firmware version and how you begin a print, the TFT35-E3 can produce a print status screen, as shown in Figure 9. (Compare this to Figure 2, which shows the main screen when not printing.) This screen appears with the stock BTT firmware when printing from the panel's SD card or USB flash drive; or with the RepRapFirmware-specific forks when a print is launched from the printer's own micro-SD card (whether begun via the DWC or from the LCD panel). This is a useful feature because it removes options that might disrupt the print, such as the option to home the printer; and it adds a BabyStep function to adjust the print height for optimal first-layer adhesion. There's also a crude print status report that shows the elapsed print time and percentage — but no estimated completion time. You can, of course, terminate the print from this status screen. Unfortunately, when starting a print from the DWC with the original BTT firmware, the TFT35-E3 does not show this status display.

All four firmware branches provide a number of options you can set from the display's user interface. In the original BTT build, it's possible to set most of these options using a file called config.ini on the SD card; if you insert an SD card with this filename and reset, the display will read the new options. In fact, this file provides a few settings that don't seem to have equivalents in the user interface. Thus, it's worth perusing this file for options that are worth changing. (For instance, the onboard_sd_support option must be set to 1 before the stock firmware will even show an option to display files on the motherboard to print — but as noted earlier, that option ends up hanging the display.) All three of the third-party builds ignore this file, so you can't adjust options in this way with them.

My experience with the TFT35-E3 so far suggests that it provides useful functionality. With the stock firmware, it can preheat the printer prior to printing, move the print head, and print files from a USB flash drive or SD card. The very latest stock firmware builds add the ability to print from files on the motherboard's micro-SD card, although that function was broken on the specific build I tried. When using the RepRapFirmware-specific forks, and especially the Thro42 variant, integration with RepRapFirmware is tighter, which makes these versions superior. These versions lack some features of the original BTT branch, but at the moment, the features gained outweigh those lost.

Based on my experience with a PanelDue, it's more tightly integrated into RepRapFirmware than is the TFT35-E3 (especially with its stock BTT firmware); for instance, both the PanelDue and the DWC show the same three estimates of print time, based on the file size, layer time, and filament usage. (Recent versions of RepRapFirmware add a fourth time estimate based on the slicer's figures, but that estimate does not appear on the PanelDue.) Overall, as of December of 2020, I'd say that the TFT-35E running BTT's stock firmware provides about 50% of the functionality of the PanelDue, and the Thro42 version provides about 90% of a PanelDue's functionality. The main feature that's missing is display of the completion-time estimates.

Development of the BTT TFT firmware is proceeding at a rapid clip. The first commit to the BTT TFT firmware repository on github is dated July 16, 2019. The bcmob fork appears to have occurred on April 10, 2020. Between then and now (December of 2020), the BTT fork has picked up features such as support for config.ini and updates to the manual g-code entry screen, while the RepRapFirmware forks have added all their RepRapFirmware integration. With Thro42 now working to better integrate RepRapFirmware support into the stock BTT firmware, it's definitely worth keeping an eye on that version of the firmware. If you use that variant, upgrading your display to the latest version is probably worthwhile.

Adjusting Slicer Profiles

Because my printer is now running new firmware, some changes to slicer profiles were necessary. I use several slicers, but PrusaSlicer (the successor to Slic3r Prusa Edition) and ideaMaker are the two I use most often. I therefore focus on the changes I needed to make in these two slicers' configurations.

The necessary changes to slicer profiles focus on the start and end g-code options. Other slicer settings, such as speeds, temperatures, and so on, should not need changes, since they relate to physical characteristics of the printer. (There might be exceptions in some cases, though. For instance, on a delta printer, you might be able to print slightly faster with a 32-bit control board.)

Prior to the upgrade, I used the following as my start g-code in both ideaMaker and PrusaSlicer:

G28 X0 Y0 Z0 ; home all axes
G1 Z5 F5000  ; lift nozzle by 5mm
G29          ; probe the bed
G92 E0       ; zero the extruded length
M420 S1      ; enable use of bed-leveling data

This start code has a few problems with my new board:

Implementing these changes, the new start g-code is:

G32         ; home axes and align the bed
G92 E0      ; zero the extruded length
G29 S1      ; use data from most recent height map

The end g-code doesn't strictly require any changes; however, adding a G29 S2 will disable the use of the height map, which can prevent problems with commands used between prints that might require that the height map not be active.

A couple of additional changes are helpful, but not strictly necessary, with ideaMaker. The first of these changes relates to completion-time estimates. As noted earlier, RepRapFirmware's DWC provides up to four such estimates, based on filament usage, file progress, layer time, and the slicer's embedded time estimates. When printing files generated by PrusaSlicer, the DWC presents all four of these estimates. (A fifth estimate can also be produced, as described shortly.) Most of these estimates show as "n/a" when printing g-code generated by ideaMaker, though; only the file progress estimation is shown. RepRapFirmware can generate the layer time estimate if one more line is added to the start g-code:

; layer_height={layer_height}

This line can go before or after the other start g-code lines. Note that it begins with the g-code comment character of a semicolon (;). This is not technically g-code; it's a comment that RepRapFirmware knows enough to parse to extract the print's layer height, which it can then use to calculate a time estimate based on the number of layers printed.

I don't know of a way to coax RepRapFirmware into generating an estimate based on filament usage, which I find is often the most accurate print-time estimate; or to use ideaMaker's own completion-time estimate, which it shows after you've sliced the model. You can, however, use RepRapFirmware's simulation feature to simulate a print: The firmware reads the entire file and calculates how long each move will take. This produces a very accurate fifth completion-time estimate; however, it's an extra (albeit minor) hassle and takes some time, so I rarely do this myself.

Deleting M1001 g-codes from ideaMaker prevents warnings from appearing

Figure 10: Deleting M1001 g-codes from ideaMaker prevents warnings from appearing

The second optional ideaMaker configuration change relates to the fact that this slicer inserts M1001 and M1002 g-code commands in .stl files that it generates. Neither Marlin nor RepRapFirmware understands these codes, but Marlin quietly ignores them, whereas RepRapFirmware displays a message about an unknown command (and otherwise ignores the unknown g-code). To prevent these warnings from appearing, the Post-Process sub-tab in the slicer's g-code options tab can be used, as shown in Figure 10. To do this:

  1. Begin to slice an object.
  2. Edit your slicing template.
  3. Select the GCode tab, then the Post-Process sub-tab.
  4. Click Add and, in the resulting dialog box, select Remove All Occurrences of SOURCE as the Command Type.
  5. Click in the Source field and type M1001.
  6. Click OK. You should see the removal action appear in the Post-Process Commands area of the Advanced Settings dialog box.
  7. Repeat the previous three steps, but type M1002 in the Source field.
  8. When you're done, click Save to save the changes.

Unfortunately, these changes can't be made globally; they must be made to every template, which can be a bit tedious. Fortunately, they're both "bonus features" that aren't really necessary.

Only the changes to the start g-code are really critical, and even then, pre-upgrade g-code intended for Marlin might print with the new motherboard in place. The new start g-code produces better bed leveling, though.

Evaluating the Upgrade

When I first bought my Robo3D R1+, I was disappointed with the printer — but intrigued enough with the technology that I wanted to learn more. After building my own Kossel XL, I'd learned enough to have a good idea of what needed to be done to my Robo3D to get it working the way I wanted, and this control board upgrade was a good first step.

The most obvious change to my operating printer is that it's quieter. The original Allegro A4988 stepper drivers made the printer "sing" whenever it was operating. The new Trinamic 2208 drivers are much quieter — the printer's dominant noises are now its fans and the sounds of the bed and print head moving about. This is a welcome improvement, but it's one that I could have achieved much more easily and inexpensively by replacing the A4988 drivers with Trinamic drivers without swapping out the entire control board.

The ability to properly level the X-axis gantry via a G32 command is a more significant improvement. Although the mesh bed leveling feature (G29 in both Marlin and RepRapFirmware) can theoretically compensate for some lack of alignment, I was constantly frustrated by the printer's deviations, which would, sooner or later, result in its going out of control and driving the head up while trying to perform the G29 command, and the subsequent need to manually spin a lead screw to bring the gantry back into (rough) alignment. This way is much better.

Speaking of bed leveling, RepRapFirmware's ability to display an offset map is informative, and reinforces the need to upgrade to a better Z probing system — perhaps a BL Touch. I may investigate maintenance on the bed first, though; in setting everything up after this upgrade, I noticed considerable play in some of the bed components, which may be exacerbating the probing imprecision. Either way, this will be a project for another day.

The biggest advantage of RepRapFirmware over Marlin, though, is the former's DWC. This enables me to print without using an SD card or OctoPrint. The DWC user interface is smoother and more reliable than OctoPrint, in my experience. I can also make configuration changes in seconds that would take minutes with Marlin.

I can print in any of two or three ways with the printer as it's currently configured:

In most cases, whatever method is used to print becomes the only (or at least the best) way to fully monitor and control the print. For instance, if you use the DWC to launch a print, neither the TFT-35E nor OctoPrint will show estimations of remaining print time; and if you print files from the TFT-35E's SD card or USB flash drive, neither the DWC nor OctoPrint will provide much in the way of control functionality. Some settings, though, such as the hotend temperature, can be controlled from any interface device. The reset button on the TFT-35E will completely reset the printer, too, no matter what print method is used.

The bcmob, JimmymaDdness, and Thro42 variants of the TFT35-E3 firmware are partial exceptions to this rule of being able to control a print only via the original launch method — they all display a print status screen, shown in Figure 9, when the print is begun from the DWC. It's not quite as informative as what a PanelDue displays, but it's pretty good. This screen includes an elapsed print time and a percentage of the file that's been printed, but not an estimated completion time.

Overall, then, I'm very happy with this upgrade. My Robo3D R1+ has become more reliable, more flexible, easier to use, and is ready for a dual-extruder setup whenever I get around to installing it.

Comparisons to the Duet 2 WiFi

Because I own both a BTT SKR Pro and a Duet 2 WiFi, I can directly compare the two products. Several points stand out:

Many of these differences are trivial to the point of unimportance, although some of these do require some planning, such as obtaining appropriate internal connectors for the SKR Pro. You'll have to judge for yourself whether features such as the number of stepper drivers, availability of support, and speed of the DWC are important to you.

Overall, the two boards both seem to be quite capable. I'm not qualified to judge the quality of components or manufacturing, though. Time will tell how reliable my SKR Pro is; at the moment, I've been using it for about a month. The Duet 2 WiFi in my Kossel XL has proven to be reliable, with the caveat that I damaged the fan outputs because of some accidental mis-wiring early on. (I was able to work around the damage.)

For many applications, either board will work fine. As noted earlier, I chose the SKR Pro for this upgrade because I plan to eventually use that sixth stepper output to drive a dual-extruder configuration — something that would be possible, but significantly more expensive, with Duet hardware. I also just wanted to try out a different product, since I already have two Duet 2 WiFi boards. A Duet would be preferable if you didn't want to deal with third-party WiFi add-ons or forks of the main RepRapFirmware. Certainly I've invested more time into configuring my SKR Pro than I would have a Duet product. That said, the bulk of my extra time has been spent on the TFT35-E3 LCD panel, not on the SKR Pro itself. If I had to do it over again, I'd consider pairing an SKR Pro with a PanelDue 5i; I've invested time that's worth well over the $50 or so extra cost of the PanelDue over the TFT35-E3, with no real benefit.

If you're considering an LPC board, bear in mind that they all (to date and as far as I know) have half the RAM of a Duet WiFi, which creates limitations that I'm not experiencing. (My SKR Pro actually has slightly more RAM than a Duet 2 WiFi — 196 KiB vs. 128 KiB — but my understanding is that the extra is not currently helpful.) The biggest limitation of the LPC version, at least for me, would be the limit of one HTTP session, since I often connect to my printers from two or more computers, tablets, or phones to prepare and monitor my prints.

References and Additional Information

I've scattered references to outside resources throughout this page. Gathered here are the more useful of these references, along with a few others (mostly specific sub-pages of larger pages I've referenced earlier).

copyright © 2020-2021 by Roderick W. Smith

This document is licensed under the terms of the GNU Free Documentation License (FDL), version 1.3.

If you have problems with or comments about this Web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.

Return to my main Web page.