Hi Nikos — sorry for the slow reply, and those are not stupid questions at all: they're exactly the right ones. Both answers are yes, and they're actually why I went quiet for a few weeks: your feedback in ▎ this thread pushed the research further, and it has now landed in a proper repo. ▎ ▎ 1. Macros — yes. Everything is exposed as G-code: bounded feed/retract (LLL_JOG, LLL_RUN — every move has a firmware deadline, no unbounded orders exist), per-lane roles (LLL_ROLE active|parked|standby — a ▎ parked lane is guaranteed by firmware to never push), plus building blocks for load/unload sequences: runout/jam events you can hook from printer.cfg (event_gcode), filament identity, and a probe that ▎ detects which lane is physically loaded using only the buffer's arm sensors. Example macros (lane switching, Tn color change, an LCD menu, a small dashboard inside Mainsail) ship in the repo. ▎ ▎ 2. Multiple LLL Plus — yes, that's the core design. One USB cable per buffer, one [mcu] + one [lll_buffer] section each, every command multiplexed by LANE=. No interaction between buffers required — ▎ exactly your case, one buffer per feed. I run two lanes in production (through a passive splitter, that's the multicolor experiment), but N independent feeds is the same config. ▎ ▎ Here it is: https://github.com/Nitrooxyde/Mellow-LLL-Plus-Canonical — the auto-feed still runs entirely inside the MCU (halls → TMC2208, no USB round-trips), with the full host layer on top. Prebuilt ▎ binary (the exact one running on my two boards, checksums included), bilingual manual, and an honest Known limitations section — including the full story of the multicolor experiment: what worked, and what ▎ we had to withdraw because of missing hardware on my side (toolhead cutter, passive respoolers), not because of the concept. ▎ ▎ To stay honest about credit: the idea isn't mine — it grew out of reading this community, and the firmware itself is written by Claude (Anthropic's AI) working with me; I set the constraints and the ▎ resolutions, the AI is what makes it possible. Same transparency as my first post — it's all in the commit history. ▎ ▎ One caveat, plainly: we tested this as far as our own hardware allowed — no further. It's validated on one setup (two lanes, one printer). Anything beyond that is your experiment, at your own risk — no ▎ warranty, no responsibility on our side. ▎ ▎ Which is exactly why I'm posting: if anyone wants to try it — Nikos, @therm_virtual0y (thanks again for the signal boost), anyone — please do, and don't hesitate to report back, here or in the repo issues. ▎ Real feedback from other setups is precisely what will make this evolve; it's how the repo got here in the first place. ▎ ▎ @goofballtech — your I2C multi-buffer work remains the better fit for very high lane counts / toolchanger territory; this repo is the one-USB-per-board road. The two approaches complement each other ▎ nicely.

As long as you have enough room, I don't think it will matter. Unless you printed the enclosure out of PLA then things might get soft and move around to positions where they don't work well together anymore. I would say the PETG, ABS and ASA are good materials for inside the enclosure. PLA would work for outside only.

According to Copilot AI... The K1 Pro ceramic hotend uses a NTC 100k thermistor.

@McCosch When the temperature is negative, that is either a faulty thermistor or a bad wire connection to the thermistor. You checked the resistance across the thermistor, but have you metered the wires going to the thermistor? Is the continuity on both of the wires? You swapped out EBB, thermistor and hot end. This appears to be a cabling issue.

Hi, I’m just stuck here, and it’s really frustrating. I modified my Stealthburner and redesigned several parts. Since I was having printing issues, I swapped out the hotend (for a K1-Pro). Now I’m having trouble with the sensor; I’ve tried numerous settings in the `bigtreetech-ebb-sb-usb-v1.0.cfg` file, but nothing has worked. Here’s what I’ve tried: - 4 different sensor types - Swapped the EBB board - Swapped the hotend - Connected a different sensor - Checked the wiring and improved the cable routing - Measured the sensor resistance (it’s 90kΩ) I’ve run out of patience for troubleshooting this any further. It seems like a recurring issue—I had the same problem last December, but unfortunately, I can’t remember how I fixed it. I’ve already ruined several EBB boards from all the constant testing, installing, and uninstalling. Maybe someone else has an idea? config-20260706-170845.zip config-20260706-170903.zip klippy.log