klipper

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-09-01

Final complete day: 2026-09-01. Attention was 0.3% — this entity appeared in 44 of 17,943 analyzed posts/comments in the seven days ending that day (72 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-09-01 23:45 UTCPost

   Por qué me salen estos aros en mi impresión - Hola hace poco le cambié la boquilla a mi impresora 3D creality ender 3 V3 SE con klipper de la stock de 0.4mm a una de 0.2mm y me ha empezado a dar problemas a la hora de imprimir. me aparecen estos aros en las orillas de mi impresión. Con la boquilla anterior me imprimía bien. He hecho el cambio en la boquilla y altura de capa en orca slicer.

2. 2026-09-01 22:17 UTCPost

   Upgrade from bltouch to btt eddy2duo problems. - Greetings all gurus and printing wizards. Im hoping the collective wisdom here can help me determine what im missing. Before i continue, im looking for actual help, not a critique of my choice of upgrades, or the cost effectiveness of what ive done. Im fully aware that i could have purchased an brand new printer with far fewer problems and better overall performance than the upgraded machine ive managed to cobble together. Several years my wife bought me an ender 3 pro. I always had problems with reliability of the prints, enough so that even after basic upgrades like adding a bltouch and a couple of 3d printed parts didnt really help much. I ended up storing the thing for a long time. Other hobbies and needs have reignited my interest and need for 3d printing so ive pulled it back out and decided i would give it a genuine try again. Somehow my mind decided the large 1 lump of money needed to get the printer i wanted was not a wise choice as, what if i get another dud? So i figured id upgrade and learn all the tricks and skills needed. Combine that with a sunk cost fallicy along with it working for just long enough to keep me from giving up on it here i am. I am having a heck of a time getting my bed leveling sensors properly swapped out for it. Ive upgraded to an octopuspro v1.1 with a bigtreetech pi 1.2, an orbiter 2.5, smart sensor, orbitool O2S, and an eddy2duo all running klipper. Along with many other upgrades not likely to effect this setup any. Changing the config files for it has been a nightmare, chasing bugs all over. Currently trying to get the eddy2duo working. Ive manages to flash it with usb firmware and have it configured but it klipper keeps crashing stating that the "Probe virtual endstop only useful as endstop pin" ive checked all of my included configs, none of them still referwnce any of the bltouch pins or anythings. The bed mesh block calls the btt\_eddy probe used in the sample configs. Currently using the sample config for btt eddy2duo for homing and zoffset beta. I did discover at one point there was a stuck set of variables at the bottom of the printer.cgf that are autogenerated that was giving details about the bltouch.are there other places i should look for stuff like that?

3. 2026-09-01 22:08 UTCPost

   [PROJECT] Raise3D N2/N2 Plus Stock Hardware → Klipper (Keeping the Original Touchscreen) - Project: Bringing Klipper to the Raise3D N2/N2 Plus Using the Original Stock Hardware & Touchscreen Hi everyone, I'm starting this thread to document a project I've been working on with my Raise3D N2 Plus. The main goal is: Run Klipper on the Raise3D N2/N2 Plus while keeping as much of the ORIGINAL hardware as possible — especially the original touchscreen, LCD and ARM touchscreen controller. Most Klipper conversions I've seen involve adding a Raspberry Pi or another SBC and often replacing the original screen. Before doing that, I wanted to find out: Can we reuse the computer Raise3D already put inside these machines? My N2 Plus has the original Raise3D touchscreen controller based on an NXP i.MX6 ARM processor. It originally runs an embedded Poky/Yocto Linux system together with RaiseTouch. So far, I have already managed to: \- Boot Debian on the original Raise3D touchscreen controller \- Get SSH access \- Install Klipper on the original controller \- Flash/run Klipper on the printer's motion controller \- Inspect the original Raise3D bootloader and eMMC \- Boot the original Raise3D Yocto system \- Extract and inspect RaiseTouch firmware packages \- Identify the original touchscreen configuration and drivers So the original touchscreen computer is absolutely capable of running Linux and Klipper. However, I've hit an interesting problem. The original Yocto filesystem stored on my printer's eMMC is heavily corrupted. After examining it with e2fsck, I found filesystem corruption affecting system libraries including Qt, ICU and even parts of RaiseTouch itself. Because of this, I currently can't use my own original installation as a reliable reference for reverse engineering the touchscreen. That's where other N2/N2 Plus owners could help. THE NEXT GOAL I'm looking for owners of working Raise3D N2 or N2 Plus machines who are willing to help collect some information from their original touchscreen systems. Initially, NOTHING needs to be modified. No firmware flashing. No dd. No eMMC writing. No motion-controller changes. We only need SSH access and a few read-only commands. The first objective is to compare several working printers and determine: \- Yocto/Linux version \- Kernel version \- i.MX6 hardware revision \- eMMC partition layout \- ICU versions \- Qt versions \- RaiseTouch versions \- Touchscreen drivers \- Device Tree configuration \- Differences between N2 and N2 Plus systems Once we identify a compatible clean system, the next step would be to safely preserve the relevant original system files and potentially a clean eMMC image. WHY DO THIS? The N2/N2 Plus is old, but mechanically it's still a very capable machine. Instead of throwing away the original electronics and installing a Raspberry Pi + new touchscreen, I want to see how far we can take the original hardware. If successful, the end result could eventually become a documented community upgrade path: Raise3D N2/N2 Plus | v Original i.MX6 touchscreen computer | \+---- Debian/Linux | \+---- Klipper Host | \+---- Moonraker | \+---- Original LCD | \+---- Original Touchscreen | v Klipper Motion Controller Ideally, someone could take an old stock N2/N2 Plus and convert it to Klipper without buying another computer or touchscreen. LONG-TERM GOAL If we can understand and reproduce everything properly, I'd like to turn the work in this thread into an open community guide/project for: "Klipper on Raise3D N-Series Stock Hardware" Including: \- Installation instructions \- Boot files \- Device Tree configuration \- Touchscreen support \- Klipper configuration \- Raise3D hardware pin mappings \- Recovery instructions \- Known hardware revisions \- Community-tested configurations I will keep updating this thread as I make progress. CURRENT STATUS \[✓\] Debian boots on original touchscreen controller \[✓\] SSH working \[✓\] Klipper host installed \[✓\] Klipper running on motion controller \[✓\] Original eMMC identified and backed up \[✓\] Original Yocto system boots \[✓\] RaiseTouch firmware packages analyzed \[✓\] Original touchscreen configuration identified \[!\] Original eMMC filesystem is corrupted \[ \] Obtain clean N2/N2 Plus system reference \[ \] Compare touchscreen drivers/configuration \[ \] Get original touchscreen working under modern Linux \[ \] Integrate touchscreen UI with Klipper \[ \] Create reproducible installation procedure \[ \] Community testing HELP WANTED If you own a working Raise3D: \- N2 \- N2 Plus \- N1 and you're interested in helping, please reply here. N2/N2 Plus systems are the highest priority. Even if you're not comfortable with Linux, I can provide very simple step-by-step instructions. For the first test, we only need to enable SSH and run a few safe, read-only commands. If you're also upgrading an old Raise3D, experimenting with Klipper, embedded Linux, touchscreen drivers, i.MX6 hardware, or reverse engineering these machines, feel free to join the project. I'll post technical findings and updates below as the project progresses. Let's see how much life we can get out of these old Raise3D machines.

4. 2026-09-01 14:15 UTCComment

   Defective USB Key or SD Card, i guess. can´t you send via network or USB Cable . the machine runs Klipper and Obico..so using a Key or SD Card is somewhat strange

5. 2026-09-01 13:40 UTCPost

   [WIP] I reverse-engineered my SUNLU S2 and replaced its controller with an ESP32-S3 - I originally wanted a little more control over my SUNLU S2 filament dryer. That somehow turned into identifying an unmarked 8051-family MCU, dumping its firmware, tracing nearly the entire controller PCB, reconstructing its custom LCD and UI, writing replacement firmware, and adding an ESP32-S3 as a new main controller. The mystery MCU turned out to be a **Sonix SN8F5703A** with only 8 KiB of main flash. Identifying it was probably the biggest early rabbit hole: I measured pins, voltages, traces and behavior on the real board, and Codex was surprisingly good at combining those measurements with the sparse clues until we had a credible chip family and could confirm it through its `0x633D` chip ID. From there I backed up the complete stock main image and hidden boot/parameter area before changing anything. The stock 8 KiB image was then imported into Ghidra as 8051 code. We eventually recovered all 48 functions, the interrupt timing, temperature and humidity lookup tables, heater-control arithmetic, settings layout, four-button state machine, buzzer behavior, and the complete 26-byte frame for the dryer’s fixed custom LCD. Some fun discoveries: \- The apparent TX/RX pads are not a usable UART in the stock firmware. \- Two daisy-chained 74HC595s drive the 16 active-low LEDs around the display. \- The LCD is controlled by a TM1729 and uses a completely custom fixed glass. \- The heater command is active-low through an inverter, so safe startup order matters a lot. \- The original controller uses its own fixed-point PID-like law and a roughly half-second time-proportioning heater window. I first wrote a complete standalone replacement for the SN8 and tested it on the real dryer. After that, the project evolved again: the SN8 now acts as a fail-safe I/O executor, while an **ESP32-S3** owns the profiles, countdown, sensor conversion, Wi-Fi, OTA, Web UI and thermal control. The two processors exchange a CRC-protected 32-byte process image 50 times per second. The SN8 still independently blocks stale or unsafe heater commands, checks its local sensor, enforces fan/temperature interlocks, and shuts the heater down if the S3 disappears. During S3 OTA the link pins go high-impedance, which deliberately trips that same local fail-safe. The current Web UI has live temperature/humidity/heater graphs, profiles, delayed start, keep-dry and cooldown behavior, diagnostics and session history. The heater now uses feed-forward PI control with a learned holding-duty bias. That part is still being tuned—the screenshot is real hardware data, but the PI and automatic bias/autotune workflow are definitely still **WIP**. A huge credit goes to SN8Flash by silicagel777. It made reading, backing up, flashing and independently verifying this unusual MCU possible without buying a dedicated Sonix programmer. I used a second ESP32 with experimental bridge firmware plus a small self-made adapter PCB based on the SN8Flash documentation. The adapter/bridge is still very prototype-looking and its firmware needs cleanup much later, but it worked reliably enough to preserve every original byte before the first erase. Also, an honest AI disclosure: this was a collaborative project. I did the physical work—opening the dryer, measurements, continuity tracing, soldering, wiring, adapter hardware, flashing and supervising all real-heater tests. Codex helped analyse the evidence, identify the mystery MCU, reverse-engineer the firmware, write most of the replacement/controller code, build verification scripts and keep the increasingly ridiculous amount of documentation organized. The photos show the current prototype wiring rather than a polished product. It is working on the real dryer, but I’m deliberately calling it WIP: PI and autotune still need refinement, the hardware needs tidying, and Klipper plus Home Assistant/MQTT integration are high on the list. What began as “can I improve this dryer a little?” has become a much deeper project than expected—but seeing the stock LCD, touch controls, safety executor and new ESP32 dashboard all working together is extremely satisfying.