In a previous post I documented upgrading my Cetus 3D printer with a TinyFab ESP32 CPU. I've been pretty happy with that setup. I think this is a pretty solid printer - and being able to run any slicer I choose has been a big win.

So I guess the question is why upgrade again? In short, there are a few additional things I would like to have:

• Some sort of progress indication on the ESP32 web UI
• Integrated webcam support
• An easy way to send notifications - e.g. use https://ntfy.sh/ to push a print complete notification to my phone (my printer lives in my garage)
• Easily accessible GPIO for further printer upgrades

RP2040 CPU

I based my design on the Raspberry Pi minimal design for the RP2040. Breaking out microcontroller pins to the relevant pins on the mainboard connector. I exposed the few extra GPIO in case I wanted to add extra features - the most likely being control of a separate part cooling fan.

I decided to drop support for an LCD panel to free up some GPIO, since it's something I don't use and aren't planning to.

Excluding my time, getting a couple of boards made up, including component assembly (except the header pins) proved remarkably cost effective. Although, in all honesty, it was great practice doing some PCB design, which I hadn't done for a while. This was both the first four layer board I'd designed and the first time I'd had it assembled by the Fab.

The KiCad design files are available at https://github.com/richcarni/cetus-RP2040-CPU

Klipper overview

For those not familiar, Klipper consists of two components - one running on a microcontroller on the printer, the other running on a more powerful machine, typically a Raspberry Pi 4 but it doesn't have to be, that work together to control the printer. The idea is the more power computer can perform more compute intensive tasks like input shaping leaving the microcontroller to basically just drive the motors (and heaters, etc.)

A really nice extra feature of Klipper is that the printer's config file resides on the computer. This means that you can modify your printer and printer config without compiling/uploading the microcontroller firmware.

Installing Klipper firmware

First you need to compile the firmware. This process is well documented elsewhere (SKR-Pico README.md and Klipper installation). The relevant settings for this microcontroller when running make menuconfig are:

• [*] Enable extra low-level configuration options
• Micro-controller Architecture = Raspberry Pi RP2040
• Communication interface = USB

When compilation is complete, a klipper.uf2 file will have been generated. The easiest way to upload this to the CPU involves:

• With the printer off, connect to your computer via USB
• Placing a jumper across the USB_BOOT pins
• Turn on the printer. The CPU should mount as a USB drive
• Remove the jumper
• Copy the compiled klipper.uf2 file to the USB drive
• That's it!

Running Klipper with Mainsail

I assume the process is similar for OctoPrint and Fluidd, but Mainsail is what I have been using.

Obtain and modify your printer.cfg file. In Mainsail this file can be accessed and edited through the Machine menu.

My printer is a MK3 (non-extended version) with a MK3 extension board and heated bed. I also installed a BLTouch bed levelling sensor (this post). If your configuration differs you will need to modify the config file accordingly. It's relatively straightfowards and well documented (Klipper configuration reference)

My printer.cfg file is available on my github

Was it worth it?

Without having done any direct side by side comparison, my impression is that print quality appears on par with what the Marlin based ESP32 CPU was producing. That shouldn't be a great surprise since I have emulated the print settings as closely as I could.

What about printing faster with input shaping? I don't know, I haven't played with that yet!

For me, the quality of life improvements make it worthwhile. Mainsail is so much more functional and nicer to use than the the ESP32 webui.

And, finally, I have a number of spare GPIO left. My next upgrade, if I ever get around to it, will be an independent part cooling fan.

For many the web interface will probably be the most attractive feature of the TinyFab ESP32 CPU. I eventually got it setup so that I could upload prints to the SD card at reasonable speeds without having to actually remove the card

The Web UI comes from a separate open source project, technically two: https://github.com/luc-github/ESP3DLib and https://github.com/luc-github/ESP3D-WEBUI

Overview (in pictures)

Assorted screenshots

Overall thoughts

Not as complete/fancy as OctoPrint but does all the basics. I started using it to upload to the SD card after I had a print failure while printing over usb/serial (I think it was a hardware issue with my PC, but made me see the benefits of printing off the SD card), since serial uploads are painfully slow and the SD card on the Cetus MK3 isn't readily accessible

A progress/estimated time remaining indicator would be the one feature I'd love to see added

Setup

Connecting to WiFi

The ESP32 can only connect to 2.4 GHz networks

You will need to be connected to the printer via USB and open a serial terminal (I use CoolTerm on Mac but PuTTY or screen or any other terminal is fine). Baudrate should be 115200, everything else

be OK as defaults

To connect to WIFI I used the following sequence of commands:

• [ESP100]<SSID>
• [ESP101]<password>
• [ESP102]DHCP
• [ESP110]STA
• [ESP444]RESTART

On restarting you should see connection progress logged to the serial terminal. If successful it will say connected and print the IP address

(By default the device should be called marlinesp on your network)

Once you have the IP address simply connect to the printer by entering the IP address into a browser

If required, user name/password will be admin/admin by default

<insert screenshot here>

For reference, all the serial control codes are documented in ESP3DLib/docs/Commands.txt:

Note:
1 - add space to separate parameters

* Display command list
[ESP]

* Set/Get STA SSID 
[ESP100]<SSID>

* Set STA Password 
[ESP101]<Password>

* Set/Get STA IP mode (DHCP/STATIC) 
[ESP102]<mode>

* Set/Get STA IP/Mask/GW 
[ESP103]IP=<IP> MSK=<IP> GW=<IP> 

*  Set/Get AP SSID 
[ESP105]<SSID>

* Change AP Password 
[ESP106]<Password>

* Set/Get AP IP 
[ESP107]<IP>

* Set/Get AP channel 
[ESP108]<channel>

* Set/Get radio state which can be STA, AP, OFF
[ESP110]<state>

* Get current IP
[ESP111]

* Get/Set hostname
[ESP112]<Hostname> 

* Get/Set HTTP state which can be ON, OFF
[ESP120]<state>

* Get/Set HTTP port 
[ESP121]<port>

* Get SD Card Status
[ESP200]

* Get full EEPROM settings content
but do not give any passwords
[ESP400] 

*Set EEPROM setting
position in EEPROM, type: B(byte), I(integer/long), S(string), A(IP address / mask)
[ESP401]P=<position> T=<type> V=<value>
Description:		Positions:
HOSTNAME_ENTRY 		"ESP_HOSTNAME"
STA_SSID_ENTRY 		"STA_SSID"
STA_PWD_ENTRY 		"STA_PWD"
STA_IP_ENTRY 		"STA_IP"
STA_GW_ENTRY 		"STA_GW"
STA_MK_ENTRY 		"STA_MK"
ESP_RADIO_MODE 		"WIFI_MODE"
AP_SSID_ENTRY 		"AP_SSID"
AP_PWD_ENTRY 		"AP_PWD"
AP_IP_ENTRY 		"AP_IP"
AP_CHANNEL_ENTRY 	"AP_CHANNEL"
HTTP_ENABLE_ENTRY 	"HTTP_ON"
HTTP_PORT_ENTRY 	"HTTP_PORT"
TELNET_ENABLE_ENTRY "TELNET_ON"
TELNET_PORT_ENTRY 	"TELNET_PORT"
STA_IP_MODE_ENTRY   "STA_IP_MODE"

*Get available AP list (limited to 30)
output is JSON or plain text according parameter
[ESP410]<plain>

*Get current settings of ESP3D
output is plain text 
[ESP420]

* Set ESP State
cmd is RESTART / RESET
[ESP444]<cmd>

* Change admin password
[ESP550]<password>

* Change user password
[ESP555]<password>

* Format ESP Filesystem
[ESP710]FORMAT 

* FW Informations
[ESP800]<plain> 

This is a pretty simple project combing and Arduino UNO and an INA226 power monitor IC. With a little bit of tweaking it can log measuring at a sample rate of 1.5 kHz

Hardware

• Arduino UNO
• INA266 breakout board (from AliExpress or similar, e.g. https://www.aliexpress.com/item/1005003065372229.html?spm=a2g0o.order_list.0.0.33121802ciAOVy)
• Breadboard and leads

Assembly

Pin Connections

Then put the INA226 in series with the device being measured. Commonly this would involve connecting IN+ to the device's positive supply voltage and IN- to the device VCC. Then connecting VBS to IN-

Firmware

https://github.com/richcarni/UNO-power-logger

Requirements:

• Install Arduino INA226 library (https://github.com/RobTillaart/INA226)

To hit a sampling rate of 1.5kHz required a few optimisations:

• I use PIND&(1<<7) instead of digitalRead(7). I haven't measured the performance gain here but I have for digitalRead, and direct port manipulation takes 1 clock cycle (63 ns) vs 4.4 us for digitalRead.
• I set I2C speed to 400kHz
• I use Serial.write() to push the minimum amount of binary data. 2 bytes for the shunt voltage and 2 byte for the bus voltage. Potentially this could be reduced to 2 bytes total if we just pushed out the INA226's onboard power (or current) measurement. The trade off is you can't have both and you either give up some resolution or range
• A serial speed of 115200 baud is sufficient

Logging software

https://github.com/richcarni/simple-power-logger

I imagine it would be easiest to write something in Python. Since I've been writing a lot of C++ recently, I used that.

The gist of it involves unpacking the binary data that is being transmitted over the serial port. Each packet of 4 bytes contains the shunt voltage (first 2 bytes), following by the bus voltage. Note that the shunt voltage is a signed 16 bit integer

[byte0, byte1, byte2, byte3], [byte4, byte5, byte6, byte7], byte8...

Data starts immediately after a specific start sequence ("#!#!#!\n")

I convert the raw readings to voltages, calculate current and power, and write out to a CSV file that I can open later in Excel or Python

The unit wasn't powering up - no sound, no LED activity.

On opening up, the fuse had blown. On inspection, no visible signs of failed components.

I replaced the fuse and heard a pop and then the faint smell of magic smoke. In retrospect I should have used the series lightbulb method when testing to limit current - lesson learnt. The fuse didn't blow this time but I turned it off pretty quickly.

This time on inspection there was clear damage to U101 (L6598 resonant controller), C119 and Q102 (switching MOSFET) and a couple of its gate components.

Fortunately I was able to find a service manual, troubleshooting guide and full schematics for all the boards in this unit. Hopefully they are easy enough to find online:

• Lifestyle PS 18, 28 and 48 Digital Acoustimass Powered Speakers Service Manual
• PS18/28/35 Troubleshooting Guide
• bose-ps28-48-sd268573-schematics (PSU)
• bose-ps28-48-sd267086-schematics (DSP)
• bose-ps28-48-sd267083-schematics (Amp)

I did as much in-circuit testing as I could to identify any other adjacent components by proximity but couldn't find anything glaringly out of the ordinary. I also used backlighting to visually check trace integrity - was also useful for identifying interconnections.

Backlit (right) images around MOSFETs (Q101 and Q102) and controller IC (U101) post removal

So I replaced those components plus the complementary MOSFET and all the MOSFET gate components, in all:

• R101, R102, R103, R104
• C119
• D101, D102
• Q101, Q102
• U101

To do that I first removed the heatsink/shield. I used hot air to heat the shield, then wetted with leaded solder and used a solder sucker to desolder.

This time I tested with a series lightbulb. It flashed previously on power on and then turned off. No activity on the power/status LEDs. I tested the supply to U101 (pin 12), which should be 12 V, but instead read only 2.5 V.

I found some very helpful information on a forum: Repair SMPS power supply from Bose subwoofer. This was a huge help in narrowing down where to look - and as it turns out, the mode of failure there appears to be the same.

Round 2

Based on the experience from that forum post, I began removing components and testing in isolation. I ended up replacing the following, some because they had failed and others out of precaution, because it was just easier than testing them rigorously:

• Q103
• Q104
• U103
• D103*
• ZR101*

(*replaced but appeared to test OK)

And success! 11.5 V on pin 12. Connected up to the rest of the unit - amber LED on the DSP board lights up initially and then the green LED starts blinking slowly (indicating "smart" speaker off state)

Parts list

List of the replacement parts used

Q101, Q102 MOSFET selection

The specific power MOSFETs used in the PSU appear to be obsolete today and not readily available. It wasn't too hard to find a replacement (a couple of options shown below) with equivalent specs - except for maximum power dissipation in an insulated package. Hopefully the original design had some headroom in this respect.

Power MOSFET comparison

Being completely new to SuperSlicer (a fork of PrusaSlicer), I'm no expert on its configuration. Apparently I did enough right to get some decent prints but I'm sure there is much that could be optimised. Nevertheless, I hope the information here is helpful - even if only a jumping off point.

At the time of writing I'm using SuperSlicer 2.3.57.6. For what its worth, here is my config bundle (cut and paste contents of word doc into plain text .ini):

superslicer_config_bundle.docx

This configuration includes just one filament (PETG) and has only been tested with a 0.6 mm nozzle. I am running my Cetus MK3 with a TinyFab ESP32 CPU, stock heated bed and BLTouch - see previous posts Cetus ESP32 CPU upgrade and Cetus BLTouch upgrade.

Various upper limits

From what I could gather from UP Studio, Tiertime Simplify3D profile and various online sources, these are my basic speeds and speed limits:

Printer Settings

I think I just created a default profile and modified from there.

General

cetus_bed.png

Custom G-code

Machine limits

Extruder 1

I set my Nozzle diameter to 0.6 mm

Filament Settings

I think I modified a generic filament but it's also possible to use/modify the included Prusa filament profiles.

Filament

Print Settings

Defaults except where indicated.

Infill

Speed

Width & Flow

In addition to my TinyFab ESP32 CPU upgrade, I also installed a BLTouch bed levelling probe on my Cetus 3D MK3.

Installation

I used this design to mount the sensor. I suggest checking the nozzle to probe offsets - mine differed from those quoted by a couple of mm. Also be careful of how the X and Y axes have been defined.

The BLTouch has two sets of connections, one for control (brown, red and orange wires) and one for sensing (white and black wires).

It seems the "typical" way to connect this up to a Cetus is to use the door check input for sensing and the unused header on the extruder board for control. I basically followed the super helpful write up at https://reeuwijk.net/post/162714620690/auto-bed-leveling-sensor-for-cetus3d https://www.tumblr.com/wbvreeuwijk/162714620690/auto-bed-leveling-sensor-for-cetus3d?source=share.

The problem with using the spare extruder header (IO17) is that the signal is inverted by a transistor on the Cetus mainboard (Q09 on my MK3). I couldn't figure out an equivalent to the SmoothieWare configuration solution documented here. I resorted to modifying the servo source code to invert the output. Ideally I'd prefer not make changes to "core" files like this.

In Marlin/src/HAL/ESP32/Servo.cpp:

void Servo::write(int inDegrees) {
  degrees = constrain(inDegrees, MIN_ANGLE, MAX_ANGLE);
  int us = map(degrees, MIN_ANGLE, MAX_ANGLE, MIN_PULSE_WIDTH, MAX_PULSE_WIDTH);
  int duty = map(us, 0, TAU_USEC, 0, MAX_COMPARE);
  duty = MAX_COMPARE - duty;
  ledcWrite(channel, duty);
}

I also considered some hardware solutions:

• Removing and bypassing transistor Q09. Relatively easy but would be somewhat difficult to reverse/undo. Seems like an odd excuse after all the modifications already made to the CPU board!
• Adding a simple inverting transistor circuit on the extruder board. Only tricky in that there isn't much spare space under the extruder cover.

Firmware - Pins

For me the pins were already setup correctly in firmware. For the setup just described they should be as follows.

In Marlin/src/pins/esp32/pins_MRR_ESPE.h:

// probe
#define Z_MIN_PROBE_PIN                       15
#define Z_PROBE_SERVO_NR                      0
#define SERVO0_PIN                            17

Calibration/Operation

There are many excellent online resources that cover the generic process of setting up and using a BLTouch. Some I found useful were:

• https://www.youtube.com/watch?v=eF060dBEnfs by Teaching Tech as a general overview
• https://www.youtube.com/watch?v=y_1Kg45APko&t=85s by Breaks'n'Makes for calibrating the Z-offset

The first in a series of posts documenting my experience upgrading a Cetus MK3 3D printer with a TinyFab ESP32 CPU and BLTouch bed levelling probe.

So far I am very pleased with how this upgrade turned out. Both in terms of improved printing performance, as well as the increased flexibility of having a more open source system. I can now choose my slicer, modify/upgrade the firmware (Marlin) and add 3rd party hardware like the BLTouch. With these upgrades, hopefully there is plenty of life left in this little printer.

Since, at the time of writing, the ESP32 CPU is still beta and there is little in the way of documentation, I decided to document my notes and hope it may be of some help to anyone either thinking about or going ahead with their own upgrade. This isn't intended to be a step by step guide and assumes a working knowledge of 3D printers and electronics.

Additionally, I have posted details of my

• BLTouch installation
• Super/PrusaSlicer settings
• ESP32 Web UI experience
• RP2040 Klipper upgrade

My hardware

I have a stock Cetus 3D MK3 with extension board and heated bed.

My upgrade involved installing a TinyFab UP!/Cetus CPU ESP32 (beta) and a ANTCLABS BLTouch (Smart V3.1) auto bed levelling sensor. I cover installation of the BLTouch separately.

The TinyFab CPU is version/release V1/R2 (schematic). My board came with a couple of modifications:

• A black wire connecting EN on the ESP32 to V_DD of U8 (a voltage supervisor IC)
• A red wire connecting P2, pin 11 to IO17 on the ESP32

Flashing firmware issues

I set out trying to flash the firmware via USB. However, the first issue I ran into is that the board wouldn't automatically enter serial bootloader mode.

I considered trying an over-the-air (OTA) update but even though I am quite familiar with EP32s, I have to admit I have never used OTA updates. I was able to connect to the unit over WIFI (it defaults to an access point) but wasn't able to pull up a web interface and I didn't go any further.

The easiest solution to flash over USB seems to be to use a jumper/switch on the unpopulated header labelled P4 to pull IO0 low on boot.

My experience was that it was necessary to disconnect the cables to the hot end and heated bed, because all the heaters turned full on in bootloader mode. Not to mention the onboard speaker!

Ultimately I ended up performing the following modifications...

Hardware modifications

/BEGIN DISCLAIMER!

The following is my solution to the issues I described. I certainly may have missed something simpler and it's also possible that they've been resolved in future revisions of this board. It is possible that there may be unanticipated side effects from these changes (so far so good but I will update here if I discover any). In attempting to replicate what I've done, one could easily irreparably damage their board.

/END DISCLAIMER!

Basically, I found/made a spare output pin on the ESP32 and used in place of the voltage supervisor IC to disable much of the IO during boot. More specifically:

• I removed the black wire, which was essentially powering U8 (a voltage supervisor IC)
• I broke the track between IO33 on the ESP32 and header P2, pin 23 (Z-STOP)
• I soldered a pull up resistor (10k) from 3.3V to the IO33
• I soldered a wire from IO33 to OE
• I removed C29 and R23
• I connected IO34 to P2, pin 23 (Z-STOP)
• I added a 1uF capacitor to EN (between TP1 and TP2 on the back of the board). This is a common issue/solution for boards using this kind of serial RTS, DTR reset circuitry. Effectively it delays EN going high on power/reset, which may be necessary to coax the ESP32 into serial bootloader mode, especially on Windows. Often a 10uF cap is recommended but 1uF worked for me.

Firmware modifications

In addition to the hardware modifications, in firmware it was necessary to:

• Free up IO33 by moving Z-STOP to IO34
• Define a PREINIT macro to pull OE low at the beginning of the Arduino setup() function.

In Marlin/src/pins/esp32/pins_MRR_ESPE.h:

#define BOARD_INFO_NAME      "MRR ESPE"
#define BOARD_WEBSITE_URL    "github.com/maplerainresearch/MRR_ESPE"
#define DEFAULT_MACHINE_NAME BOARD_INFO_NAME

#define BOARD_PREINIT() { \
  OUT_WRITE(33, LOW); \
}

//
// Limit Switches
//
#define X_STOP_PIN                            32
#define Y_STOP_PIN                            35
#define Z_STOP_PIN                            34

Discussion

Maybe a few words on my thought process here...

Firstly, the larger capacitor on the EN should have fixed the USB auto bootloader issue for me, except what appeared to happen was the ESP32 would hang (or got stuck in a boot loop, I didn't investigate thoroughly) with all the heaters on if not disconnected. I'm guessing the delay on EN from the capacitor may have prolonged the startup delay of the voltage supervisor IC. Whatever was going on, it just seemed to me using a dedicated output rather than the voltage supervisor to enable IO after boot had the advantages of 1. not relying on a potentially sensitive time delay, 2. in the event of a boot failure the heaters wouldn't turn on, and 3. in serial bootloader mode the heaters won't turn on.

The only problem is there are no spare IO on the ESP32. IO34 is connect to B-THERM2 and since I have a stock heated bed I figured it was expendable. There are also some LCD IO that I could have used but I thought that was a more likely upgrade for me. Since IO34 is an input only, I connected this to Z-STOP to free IO33.

Other firmware modifications

Swapping axes

I also swapped my X and Y axes and put home (0, 0) at the front left corner of my bed. This isn't necessary but seems to be a convention and makes working with Marlin and most slicers easier. These are the relevant settings in Marlin/Configuration.h:

#define USE_XMIN_PLUG
//#define USE_XMAX_PLUG

#define INVERT_Y_DIR false

#define X_HOME_DIR -1

And in Marlin/src/pins/esp32/pins_MRR_ESPE.h:

#define X_STOP_PIN                            32
#define Y_STOP_PIN                            35

#define X_STEP_PIN                           132
#define X_DIR_PIN                            133

#define Y_STEP_PIN                           129
#define Y_DIR_PIN                            130

Home offsets

To align the print area more closely with that of the stock machine and the centre of the bed, I added a 3mm offset in Marlin/Configuration.h (assuming X/Y configured as above):

#define X_MIN_POS -3
#define Y_MIN_POS -3

Resources

tfespcpuv1_r2_schematic

I forked Marlin on GitHub and created a branch for my modified TinyFab version: https://github.com/richcarni/MarlinCetus3D. The original TinyFab version is tagged tinyfab_original.