Post Stastics
- This post has 2368 words.
- Estimated read time is 11.28 minute(s).
October 2026 · 3D Printing · Marlin · STM32 · Hardware Hacking
A practical account of installing a BLTouch-compatible probe, debugging a firmware that wouldn’t boot, and finally getting a good first layer across a 300 × 300 mm bed.
I bought a 3D Touch-style probe for my Longer LK5 Pro because I wanted something more dependable than constantly chasing the perfect adjustment with the bed-leveling wheels. I also wanted a better foundation for improving the printer’s dimensional accuracy. The LK5 Pro had been printing reasonably well, but subtle first-layer differences and an occasional elephant’s foot were still on my list of things to improve.
I expected the probe installation to be mostly mechanical work followed by a firmware build. Instead, the most interesting problem turned out to be the firmware file format. We eventually got everything working—including the original DWIN touchscreen, safe Z homing, a 36-point bed mesh, and a five-square first-layer test—but the route there is worth documenting.
This is the story of what we actually tested, what failed, and the details I wish I’d had at the beginning.
Compatibility warning: This article concerns a Longer LK5 Pro with the MKS Robin E3 V1.1 motherboard, STM32F103RCT6 microcontroller, and DWIN serial touchscreen. Other LK5 Pro production revisions exist. Do not flash this firmware onto an MKS Robin Nano, an AVR-based board, or a motherboard you have not positively identified. The probe wiring and X/Y offsets are likewise specific to the tested hardware and mount.
The hardware we were working with
My printer has a nominal 300 × 300 × 400 mm build volume. Once I checked the electronics, the relevant details were:
| Item | Tested setup |
|---|---|
| Printer | Longer LK5 Pro |
| Mainboard | MKS Robin E3 V1.1 |
| Microcontroller | STM32F103RCT6 |
| Display | Longer DWIN 4.3-inch serial touchscreen |
| Probe | Five-wire 3D Touch / BLTouch-compatible probe |
| Probe control | PB1, via J12 |
| Probe trigger | PC6 / Z-min, via J11 |
| Development machine | Ubuntu 24.04 |
| Build environment | PlatformIO, mks_robin_e3_maple |
| Serial terminal | CuteCom, 115200 baud |
The first lesson is simple: inspect the actual motherboard before downloading or compiling firmware. An LK5 Pro label on the outside of the printer does not tell you which electronics are inside.
I connected the probe’s three-wire power/control group to the appropriate J12 connection and the two-wire trigger group to J11, replacing the mechanical Z-min input for this installation. Do not assume that connector orientation or wire colors on another probe are identical. Verify ground, supply voltage, and signal assignments from the actual board silkscreen and the probe documentation, with the printer unplugged.
Finding a workable Marlin source tree
The firmware project I used is based on the work in the DreadedZombie LK5 Pro firmware repository. We now maintain the field-tested BLTouch changes and documentation in my Monotoba fork.
The project uses PlatformIO. On Ubuntu, the essential build steps are:
cd ~/projects/3d-printers/LK5Pro-BLTouch python3 -m venv .venv .venv/bin/pip install platformio .venv/bin/pio run -e mks_robin_e3_maple
The first two commands are setup steps; if you already have the virtual environment and PlatformIO installed, you only need the final build command. The environment name is mks_robin_e3_maple, not mks_e3_maple.
In Marlin/Configuration.h, we enabled the probe and configured the measured mount offsets:
#define WITH_Z_PROBE
#define NOZZLE_TO_PROBE_OFFSET { -45, -20, 0 }
#define PROBING_MARGIN 30
The X and Y numbers describe my mounting bracket: the probe sits 45 mm to the left of the nozzle and 20 mm toward the front. They are not universal LK5 Pro settings. The zero in the compiled Z offset was only a starting value; Z must be calibrated on the assembled printer. We also retained two measurements per point during Z homing and a 6 × 6 bilinear grid.
The build completed successfully. Unfortunately, a successful compilation was not the same thing as a successfully booting printer.
The firmware-format trap that cost us the most time
PlatformIO produced two files in:
.pio/build/mks_robin_e3_maple/
They were:
firmware.bin— the raw STM32 application binary.Robin_e3.bin— an MKS-format transformed output generated by the build script.
The original project’s flashing directions said to rename Robin_e3.bin to firmware.bin, put it on a microSD card, and let the bootloader update the board. That seemed reasonable. The update appeared to run, but the printer would not proceed beyond the LONGER splash screen.
We tried to work out whether the problem was the display firmware, the firmware’s flash address, or the image encoding. The crucial discovery was that the bootloader on this particular LK5 Pro accepted the raw, unencrypted firmware.bin. The transformed Robin_e3.bin did not boot when renamed and installed using the same method.
The linker script and the PlatformIO configuration used an application origin of:
0x08005000
That was correct for our working build. Changing the origin to 0x08007000 was not the fix. We restored the 0x08005000 configuration and used the raw binary generated directly by PlatformIO.
That worked. The printer booted into its normal DWIN interface, responded over USB serial, and ran the updated Marlin firmware.
For our tested board/bootloader, the SD-card procedure is:
- Build with
pio run -e mks_robin_e3_maple. - Copy
.pio/build/mks_robin_e3_maple/firmware.bin—not the renamedRobin_e3.bin—to the root of a FAT32 microSD card. - With the printer powered off, insert the card, switch on the printer, and allow the update to finish.
- Restart and verify that both the touchscreen and the serial interface work.
This is not a blanket rule for all MKS Robin boards. Different bootloaders expect different update formats. Identify your own hardware before borrowing these instructions.
For an additional check, the raw firmware from my successful installation was 183,404 bytes, with this SHA-256 checksum:
8bcd9056a9f443a084d66595dd692705597e65f49e43d6aa48ee658add2ae30e
The reset handler in that binary was at 0x080053A1, consistent with the 0x08005000 application placement. This checksum identifies the specific build I installed, not every future version of the fork.
We preserved a backup of that known-working image. I strongly recommend doing the same before experimenting with further firmware changes.
First boot: cleaning up the EEPROM
After the firmware finally started, Marlin complained that the saved EEPROM data did not match the new firmware’s expected layout. That is unsurprising when configuration options change; saved settings from the old build may no longer be compatible.
First, while the original settings are still readable, save the output of M503 somewhere safe. After the new firmware was running, we used:
M502 ; load compiled firmware defaults into RAM M500 ; save those defaults to EEPROM M503 ; report current settings for inspection
That cleared the EEPROM-layout error. Do not perform M502 casually: it can discard your existing calibrated offsets, steps/mm, PID tuning, and other printer-specific settings. Record the old values and restore anything that is still appropriate.
Testing the 3D Touch before trusting it with Z homing
A probe should be tested with plenty of clearance above the bed before you allow the Z axis to home. An incorrect trigger connection can drive a nozzle into the build plate.
Using CuteCom on Ubuntu, I connected to the printer at 115200 baud. On my machine, the USB serial port appeared as /dev/ttyUSB0 (the stable /dev/serial/by-id/ symlink is a better way to identify it than assuming that number is permanent).
Useful probe commands were:
M280 P0 S10 ; deploy the probe pin M280 P0 S90 ; retract the probe pin M280 P0 S160 ; clear a probe alarm, if supported M119 ; report the endstop/probe input state
With the probe deployed and untouched, the Z-min input read open. When the pin was triggered, it read TRIGGERED. We also verified that the probe could deploy and retract consistently. On one occasion the probe entered an alarm state after manual testing; resetting it and checking operation again resolved that problem.
Only after those checks did we perform controlled Z homing, keeping a hand close to the power switch. The nozzle moved to a safe central area, the probe measured the bed twice, and the toolhead lifted as expected.
On this installation, the probe was 45 mm left and 20 mm forward of the nozzle. For a probe measurement near bed center (X150 Y150), the nozzle therefore moved to approximately X195 Y170. Seeing the nozzle slightly away from bed center during safe Z homing was normal—it positioned the probe over the target point.
Calibrating the Z offset
The probe tells Marlin where the probe pin triggers. It does not inherently know how far the nozzle tip is above the bed at that moment. That difference is the Z probe offset.
We started with a paper test after homing, adjusting the nozzle position in small increments and looking for slight, repeatable drag on a sheet of ordinary printer paper. We carefully restored Z soft-endstop protection if it had been temporarily disabled for calibration.
My paper-based result was about -2.20 mm. After examining the first-layer prints, we used -2.22 mm as the final saved value:
M851 X-45 Y-20 Z-2.22 M211 S1 ; ensure software endstops are enabled M500 ; save the settings
The negative Z value is specific to this physical installation. Do not copy -2.22 to your printer without doing your own calibration. On this configuration, a more-negative offset moves the nozzle closer to the bed.
Letting the printer measure the bed
Once homing and the probe offset were working, we measured the bed using Marlin’s bilinear automatic bed leveling:
G28 ; home all axes G29 ; probe the bed and build a mesh M500 ; save settings and mesh M420 S1 ; enable leveling M420 V ; report leveling state and mesh
The printer collected 36 successful measurements on a 6 × 6 grid. The lowest point in the reported mesh was -0.162 mm and the highest was +0.208 mm, a total difference of 0.370 mm.
That is precisely why a probe is useful: the bed isn’t a mathematically perfect plane. With a mesh, Marlin can make small Z corrections as the nozzle traverses the first layers. It does not physically flatten the glass, and it is not a substitute for basic mechanical bed adjustment, but it can compensate for much of the remaining variation.
One line in Cura makes the saved mesh useful
There’s a subtle Marlin behavior that can undo all that careful calibration: homing with G28 normally disables bed leveling, unless the firmware has specifically been configured otherwise.
So merely running G29 once and saving the mesh is not sufficient. If the slicer’s Start G-code does not restore the saved mesh, printing may proceed without the intended compensation.
I edited Cura’s printer Start G-code so that these two lines appear together, with M420 after homing:
G28 ; home all axes M420 S1 Z4 ; enable saved bed mesh; fade corrections over 4 mm
The rest of my established heating, priming, and movement sequence was left in place. You could alternatively run G29 during each startup, but enabling a saved mesh is quicker when the bed geometry is stable.
The Z4 setting fades the mesh corrections out over the first four millimeters of the print.
Did it improve the first layer?
We printed a simple test: five 30 × 30 mm, single-layer squares, one near each corner of the 300 × 300 mm bed and one in the center. The intended thickness was 0.20 mm.
All five squares adhered. Their extrusion paths joined into continuous, flexible sheets when removed, and there were no major uncovered regions or evidence that the nozzle had gouged the glass. A couple of opposite outer corners appeared slightly more translucent, but my calipers only resolved about 0.1 to 0.2 mm for these very thin parts; that wasn’t precise enough to establish whether those areas were measurably thinner.
We resisted the temptation to keep turning bed wheels or chasing the Z offset by hundredths of a millimeter based on appearance alone. At -2.22 mm, the first layer was good enough to move forward. Further work on elephant’s foot, extrusion behavior, and X/Y/Z dimensional accuracy is a separate calibration problem, not proof that the 3D Touch installation failed.
What I would do differently next time
The entire experience produced a useful checklist:
- Identify the exact board and MCU before even selecting a firmware repository.
- Save the current settings and a proven recovery image before flashing anything.
- Inspect both the PlatformIO build outputs and the bootloader requirements; don’t assume the file with the manufacturer’s name is the correct one.
- Test deployment and trigger reporting with
M280andM119before allowing the printer to home Z. - Measure your own X/Y offsets and calibrate Z on the actual machine. Do not treat someone else’s
M851values as universal. - Store the mesh and reenable it after
G28in your slicer Start G-code. - Judge the result by a real first-layer print, not just by whether
G29completes successfully.
Project files and further reading
I’ve made the working firmware project and documentation available for anyone with the matching controller who wants to inspect the configuration or build their own image:
- Monotoba LK5 Pro firmware fork — source, tested configuration, and field notes.
- 3D Touch installation guide (Markdown) — technical procedure and recovery notes.
- Original DreadedZombie LK5 Pro firmware project — upstream work on which this fork is based.
- Marlin: Bilinear Bed Leveling (
G29) — how probe-based bed meshes work. - Marlin: Bed Leveling State (
M420) — enabling a saved mesh and configuring fade height. - Marlin G-code reference — documentation for
M119,M280,M500,M502,M503,M851, and other commands. - PlatformIO documentation — build environment and command-line reference.
A PDF installation manual is also linked from the fork’s README; check that it has been uploaded to the repository before relying on its direct link.
Final thoughts
The 3D Touch is now working on my LK5 Pro. We verified the pin controls, the Z-min trigger, double-probing during homing, the full 6 × 6 mesh, EEPROM persistence, Cura integration, and an actual first-layer print across the bed.
The real surprise was not the probe—it was the difference between a firmware image that a bootloader appears to accept and one that the printer can actually execute. That distinction cost us time, but documenting it should make the next installation much easier.
For me, that’s half the fun of working with open firmware and repairable hardware: when a project fights back, understanding why is often as useful as the upgrade itself.