Posted 31 October 2025
Last night I was able to verify that ‘klippy.log’ contains the entire in-lined configuration, after all includes and before parsing at the top of each entry. This should go a long way toward effective troubleshooting of the ‘No LEDs’ problem. However, when I started the process of implementing the Grok-suggested changes, I discovered that my printer will no longer connect to nhk0 or nhk1. I get the dreaded “mcu ‘nhk1’: Unable to connect” and/or “mcu ‘nhk0’: Unable to connect” error(s). Since I haven’t made any hardware changes this is kinda hard to believe, and at least so far I’m convinced this is yet another software-induced issue.
So, I plan to go back to my 251025 configuration (251025_wt_dock_printer.cfg & 251003_T0-Nitehawk-Revo-LDO.cfg). Yep! this configuration setup worked perfectly – no errors, and the restart was very rapid (maybe 2-5 seconds). LEDs on T0 also worked.
01 November 2025 Update:
After spending way too much time chasing the issue with LEDs not working on the T1(red) toolhead, I think I’m back going again. Again I’m starting with the following single-toolhead configuration:
- 251025_wt_dock_printer.cfg (printer.cfg with ‘with dock’ contents below the SAVE_CONFIG line)
- 251003_T0-Nitehawk-Revo-LDO.cfg
I modified printer.cfg in MainSail to change the max_y value for QGL from 225 to 275, and then ran SAVE_CONFIG_MODE to copy the changes to the ‘config_wt_dock.cfg’. This gives QGL a wider range of positions and should result in better gantry levelling in the ‘with-dock’ configuration.
I rechecked the x & y parking values for T0 and then ran TEST_DOCKING. The docking test went very well – very smooth, no hitches at all. An interesting note about TEST_DOCKING; if a recent HOME_ALL/QGL hasn’t been accomplished, it does another set before actually doing the docking moves.
Per recommendation from Grok I also added ‘[gcode_macro STATUS_MSG]’ to the top of printer.cfg to implement dual-destination logging – both to the status line and to the console log so I can see the full range of activity. The full macro is:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[respond] default_type: echo #11/01/25 added to direct output to both the status line and the console [gcode_macro STATUS_MSG] description: LCD + instant console log (NO TIME - WORKS 100%) gcode: {% set msg = params.MSG|default("") %} {% set type = params.TYPE|default("echo") %} {% set tool = params.TOOL|default(printer.tool_probe_endstop.active_tool_number|int) %} {% set tool = (tool|int if tool != -1 else 0)|string %} {% if msg == "" %} { action_raise_error("STATUS_MSG: Missing MSG=") } {% endif %} M117 T{tool}: {msg} RESPOND TYPE={type} MSG="T{tool}: {msg}" |
and it gets called like this:
|
1 2 |
STATUS_MSG MSG="Heating T1" TYPE=echo # Green console STATUS_MSG MSG="ERROR: Timeout!" TYPE=error # Red `!! |
Note that to make outputs from a STATUS_MSG command immediately visible in the console window in, the standard console filter “Hide Temperatures” must be disabled, and a new filter added to suppress the status messages that are emitted by the ‘STATUS’ line at the end of the STATUS_MSG macro (the STATUS line is required to force a console window update). Interestingly, the ‘Hide Temperatures’ filter is supposed to suppress the 1-2 second period temp reports, but disabling this filter still doesn’t result in a blizzard of temp reports. From Grok:
|
1 2 3 4 |
Why No Automatic Temps in Console?Klipper Design: Klipper doesn't "spam" real-time temperature updates to the console tab (which is primarily for G-code commands/responses and explicit messages like RESPOND/M118). Instead:Periodic stats (including temps) are logged to klippy.log (every ~1 second when active, like during heating). Temps only appear in the console when explicitly queried (e.g., via M105) or during certain events (e.g., heating errors). UI Role: The Console tab in Fluidd/Mainsail shows interactive G-code output, not the full backend log. The "Hide Temperatures" filter only affects M105-like responses (hiding them to reduce clutter), but since no automatic reports are sent, disabling it won't "unlock" them. |
So I’m happy with the current setup; ‘Hide Temperatures’ filter OFF, ‘Hide Klipper State’ OFF, ‘STATUS’ line removed from STATUS_MSG macro.
02 November 2025 Update:
I saved the three files relevant to the STATUS_MGS macro adventure to a folder named
‘20251102-141756 STATUS_MSG Macro Files’ in the MissChanger/Config Files folder, so now I can start moving forward again toward dual-toolhead nirvana. I plan to do this as follows:
- Add [include 251029_T1-Nitehawk-Revo-LDO.cfg] to printer.cfg just before the SAVE_CONFIG section. this file in turn includes 251002_T1_stealthburner_leds.cfg
OK, this came up OK, And now both ‘T0’ and ‘T1’ are available in the ‘Extruder’ tab in the dashboard – yay! From Klippy.log I can see that the T0/T1 include files have been properly in-lined into printer.cfg, along with the T0/T1 neopixel LED files, with NO errors. It’s really nice being able to see the entire config chain in one file.
Looking at klippy.log, I see the following ‘parking’ positions for T0 & T1:
- T0: params_park_x = 69.00, params_park_y = 90.00, params_park_z = 250.0
- T1: params_park_x = 245.0, params_park_y = 91.50, params_park_z = 250.0
These values should be pretty close to correct for tool changes. I have already verified that T0 can be docked and undocked using TEST_DOCKING, but I still need to re-verify the values for T1.
03 November 2025 Update:
At the moment, neither toolhead has been selected, so I’m going to manually swap T0 out (docked), and T1 in (place it on the carrier), and then command a HOME_ALL (G28). This *should* cause T1 to be detected as the active toolhead. Yes!! T1 was detected as the active toolhead. Wow! I actually knew something!
OK, now I’m going to re-verify the parking positions using manual moves, and then I’m going to try TEST_DOCKING. WooHoo! Test Docking on T1 worked, and now I can even change toolheads under program control, as shown in the following short videos:
Now that I have tool changing working, I think we are about done with the hardware configuration aspects of the MissChanger mod. I think the next step is to get Prusa Slicer configured to handle dual extruders, and get some test prints going – woo hoo!
Went back through MissChanger’s Prusa Slicer settings, so I think I have this correct. Tried a T1 test print with ‘251103_T1_Strap tensioner optimized_v003.gcode’, but it failed with the error ‘Error evaluating ‘gcode_macro PRINT_START:gcode’: jinja2.exceptions.UndefinedError: ‘dict object’ has no attribute ‘BED‘
I’m thinking that this error is yet another instance of my old single-toolhead PRINT_START macro not being able to handle multiple toolheads.
Grok agreed, and proposed the following PRINT_START macro upgrade:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
[gcode_macro PRINT_START] description: Multi-tool start (heat active extruder + bed/chamber) gcode: {% set TOOL = printer.toolchanger.tool_number|int %} # Active tool {% set EXTRUDER = 'extruder' + (TOOL if TOOL > 0 else '') %} # 'extruder' (T0) or 'extruder1' (T1) {% set BED = params.BED|default(60)|int %} # Default 60 if missing {% set EXTRUDER_TEMP = params.EXTRUDER|default(200)|int %} # Default 200 {% set CHAMBER = params.CHAMBER|default(0)|int %} # Default 0 (off) STATUS_MSG MSG="PRINT_START: T{TOOL} Bed={BED} Extruder={EXTRUDER_TEMP} Chamber={CHAMBER}" TYPE=echo G28 # Home BED_MESH_CLEAR QUAD_GANTRY_LEVEL # Level # Heat Bed SET_HEATER_TEMPERATURE HEATER=heater_bed TARGET={BED} TEMPERATURE_WAIT SENSOR=heater_bed MINIMUM={BED-2} MAXIMUM={BED+2} # Heat Active Extruder SET_HEATER_TEMPERATURE HEATER={EXTRUDER} TARGET={EXTRUDER_TEMP} TEMPERATURE_WAIT SENSOR={EXTRUDER} MINIMUM={EXTRUDER_TEMP-2} MAXIMUM={EXTRUDER_TEMP+2} # Chamber (if >0) {% if CHAMBER > 0 %} STATUS_MSG MSG="Heating Chamber to {CHAMBER}" # Use chamber heater/fan logic (add your chamber macro if needed) M141 S{CHAMBER} # Or your chamber heat command TEMPERATURE_WAIT SENSOR=chamber MINIMUM={CHAMBER-2} MAXIMUM={CHAMBER+2} {% endif %} BED_MESH_CALIBRATE # Mesh G90 # Absolute STATUS_READY # LEDs ready! |
However, before implementing this change, I saved off the current config file set (printer.cfg, 251003_T0_Nitehawk-Revo-LDO.cfg, 250922_TO_stealthburner_leds.cfg, 251029_T1_Nitehawk-Revo-LDO.cfg, 251002_T1_stealthburner_leds.cfg) to config-20251103-113415.zip and put it in C:\Users\Frank\Documents\3D Projects\Voron Printer\MissChanger\Dock.
Then I replaced my PRINT_START with Grok’s version, saved, and restarted. I also reset (rolled-over) Klippy.log, which caused another save/restart. Then I tried the print again.
Side note: After starting the print, the console window started getting ‘spammed’ by temperature messages – the behavior that resulted in having a ‘hide temperatures’ filter. I activated the filter and the spam stopped (not sure if that affected my STATUS_MSG behavior or not).
Hmm, activating the ‘hide temperatures’ filter didn’t stop the temps span – uh oh!
Well, that went about as well as could be expected, meaning ‘not very well at all’ :(.
Grok used our STATUS_MSG macro:
|
1 |
STATUS_MSG MSG="PRINT_START: T{TOOL} Bed={BED} Extruder={EXTRUDER_TEMP} Chamber={CHAMBER}" TYPE=echo |
but the result was “T1: PRINT_START: T{TOOL} Bed={BED} Extruder={EXTRUDER_TEMP} Chamber={CHAMBER}”. In other words, none of the {} parameters were expanded properly. And to add insult to injury, even that much didn’t show up until I hit F5 (or disabled the ‘hide temperatures’ filter).
The extruder temperature went up to 200C and then stayed there, until eventually resulting in a “Extrude below min temperature”. I’m actually not even sure the T1 extruder ever got hot AT ALL – have to check.
Also got another error – “The value ‘sb_leds’ is not valid for LED”. This sounds like an issue with naming conventions in printer.cfg
The reason the ‘Extruder below temps’ error occurred was because the T0 extruder was being heated, but the desired T1 extruder was not. I confirmed I could manually set T1 to a temp at the printer KlipperScreen and T1’s extruder actually got hot. So, the number mixup may well be in PRINT_START or in the Gcode
07 November 2025 Update:
These last few days I have been working on getting the various stealthburner LED color/intensity combinations working on both T0 & T1 toolheads, and wound up with a totally different configuration than the ‘stock’ MissChanger. Instead of two complete sets of ‘STATUS_xxx’ LED-setting macros, Grok talked me through creating a single set of macro files called ‘251103_shared_stealthburner_leds.cfg’ containing all the macro code, and separate very small ‘251103_T0/T1_stealthburner_leds.cfg. All the T0/T1 files to is define the mcu pin number to be used. When a ‘STATUS_XXX’ macro is called, it first figures out which toolhead is active, and then passes a new ‘LED’ parameter to the appropriate led-setting macro (typically ‘_set_sb_leds_by_name’). This took a long while to work through all the hardware and software problems, but eventually (with a LOT of help from Grok), I got it figured out. All the status codes work now, with both T0 & T1. The related config files were all saved to the ‘C:\Users\Frank\Documents\3D Projects\Voron Printer\MissChanger\Config Files\251107_stealthburner_LED_config’ folder.
The saga continues in