**Paxx12 Firmware — Two Integration Questions: Spoolman Multi-Extruder Tracking + T0-T31 Fluidd Tool Panel**

U1 Toolchanger U1 Troubleshooting guides
1

Paxx12 Firmware — Two Integration Questions: Spoolman Multi-Extruder Tracking + T0-T31 Fluidd Tool Panel

Hey everyone — I’ve been building out a pretty comprehensive setup around my U1 with Paxx12 and running into two issues I’d love community input on. Posting here alongside Discord and Reddit to cast a wide net.

My Full Setup:

  • Snapmaker U1 — all 4 toolheads active, 0.4mm hardened steel nozzles on all toolheads
  • Paxx12 1.4.1 (paxx12-19) as firmware — Fluidd as web UI
  • Spoolman running in Docker on a dedicated local NUC (172.16.1.203:7913)
  • Moonraker connected to Spoolman via [spoolman] block in moonraker.conf
  • SimplyPrint connected for remote monitoring, webcam feeds, and print queue management
  • Tailscale VPN for secure remote access across all devices
  • 65 spools in active inventory — all entered and tracked in Spoolman
  • Creality Space Pi X4 filament dryer above the printer feeding via PTFE tubes

Issue 1 — T0-T31 Showing in Fluidd Tool Panel

The Tool section in Fluidd displays all 32 tools (T0-T31) instead of just my 4 physical toolheads. I researched this and found GitHub issue #344 which explains the extra tools are internal Paxx12 macros used for full spectrum color mixing and other firmware functions — so I understand the reason they exist.

My questions on this:

  1. Is there a safe way to hide T4-T31 from the Fluidd UI without deleting the underlying macros or breaking any Paxx12 functionality?
  2. Is editing fluidd.cfg to suppress the display of unused tools something that’s been done safely by other users?
  3. Or is this simply something we live with on Paxx12 for now?

Issue 2 — Spoolman Only Tracking Primary Extruder, Not All 4

This is the more important issue. Spoolman IS connected and working — filament usage tracks correctly in real time for the primary active spool. However after completing a 2-color PETG print tonight using two extruders simultaneously, only the spool assigned to the primary extruder showed gram deductions. The second extruder’s spool remained at 0g used despite definitely printing.

Current confirmed state:

  • [spoolman] block active and confirmed in moonraker.conf (server: http://172.16.1.203:7913)
  • 3 spools assigned to printer slots #1, #2, #4 in Spoolman with correct locations
  • Primary extruder tracking: :white_check_mark: working perfectly, real-time gram deduction confirmed
  • Secondary extruder tracking: :cross_mark: 0g recorded after multi-color print
  • Fluidd Extruder dropdown in Tool panel does not appear to affect Spoolman assignment

My questions on this:

  1. Is multi-extruder Spoolman tracking actually implemented in Paxx12 / Moonraker for the U1?
  2. Is there a specific Moonraker configuration needed to enable per-extruder spool tracking across all 4 toolheads?
  3. Has anyone successfully got all 4 extruders reporting usage to Spoolman independently?
  4. Or is this a current Moonraker limitation for multi-toolhead setups that isn’t yet implemented?

I’m happy to share my moonraker.conf [spoolman] block or any other config details if it helps diagnose. Thanks in advance — this community has been invaluable getting this setup dialed in.

Screenshot 2026-06-17 221003
Screenshot 2026-06-17 2210031261×2376 218 KB

Screenshot 2026-06-17 220653
Screenshot 2026-06-17 2206532552×897 115 KB

Screenshot 2026-06-17 220531
Screenshot 2026-06-17 2205311920×2079 432 KB

2

What a great post. This is definitely the best place to document it, please back-port any feedback you get elsewhere.

3

So I believe the answer is this, which came from u/n0_n4m3_666 over in the r/SnapmakerU1 Reddit group.

Apparently, I am just a blind ass noob. I totally did not see that at all. I followed the readme, and that is it. I did not know there was this how-to. I was hoping it was a simple fix, and of course it is. Well, nothing like being a noob to this party. But it’s great having the best community out there to help out. Thanks again u/n0_n4m3_666. Appreciate it. I am going to try this once the U1 finishes printing its current job.

Reddit reply:
Did you follow the HowTo at U1-Spoolman-Multitool/spoolmanGitHub?

To answer your question:

Do I need additional Moonraker config to enable per-extruder tracking for all 4 slots?

Yes, you do. After that you can select which spool is on which extruder.

4

I’ll second this being a great post - thanks for all the details. I’ve been using Paxx12, but am more of a newbie than you are based on what you’ve managed to set up so far. I’ve been looking at the different options for integrating filament management, remote viewing/control, etc into the Paxx12/plain Orca Slicer workflow. Also, interested in printing error detection. I may well try to imitate much of your system above, and if so, will likely have a few questions.

5

**UPDATE — FIX FOUND** :white_check_mark:

After a lot of troubleshooting, we found the root cause and fixed it. Posting this so anyone else who hits the same wall doesn’t have to go through the same pain. Thanks again to u/n0_n4m3_666 for the intial link to try and for u/n19htmare for sharing me his other option as a plan B and for u/Logical-Rip-9661 u/Illustrious-Ad-1396 information as well. Thanks to a great community. Also or u/2wDragon initial workaround and information on how to get it to work, wanted to tag you in case you wanted to update the cfg file in your repo.

**The Problem:**

The `spoolman_multi_tool.cfg` file has a bug on line 64 that causes Klipper to crash with `!! Internal error on command:“SAVE_VARIABLE”` immediately after bed leveling on every print attempt.

The stack trace from klippy.log reveals the exact cause:

```

File “/home/lava/klipper/klippy/extras/save_variables.py”, line 41, in cmd_SAVE_VARIABLE

value = ast.literal_eval(value)

SyntaxError: unexpected character after line continuation character

```

Klipper’s `ast.literal_eval()` cannot parse the escaped quotes `\“\”` that the cfg uses when saving an empty spool value. It receives `\\` which is invalid Python syntax and crashes hard.

**The Fix:**

In `custom/spoolman_multi_tool.cfg`, find line 64:

```

SAVE_VARIABLE VARIABLE={vname} VALUE=\“\”

```

Change it to:

```

SAVE_VARIABLE VARIABLE={vname} VALUE=“‘’”

```

That passes an empty string in a format that `ast.literal_eval()` can actually parse.

**Result:** Multiple toolchanges completing successfully with no crashes. T0, T1, T2, T3 all assignable independently in Spoolman via Fluidd. Multi-toolhead spool tracking is fully working on Paxx12 1.4.1.

Hope this saves someone else a day of debugging! :folded_hands:

6

The old escape-code stripping problem so tricky when passing strings through a variety of languages! I’m sure that has saved more than a day.

7

I had Spoolman running on my U1 but only showed 1 spool. Didn’t have the multi tool head macros installed. I will be trying it again with the code from GitHub.

8

Thank you for posting the fix @blackops. I did spend a day troubleshooting that error but got it now and see the correct spools when using the T0, T1, T2, T3 macros without errors.

However, I did my first print and noticed that the active spool isn’t changing when slicer-generated tool swaps occur. The active spool is wanting to default to T3 even though T0, T1 were being used.

I noticed when the file is running, the console is reporting “pick extruder3” instead of a T3 macro callout.

Is there something else you had to do to get the active spool to update when running a file, not just manually swapping tool heads?

Edit: I have added some additional code to the spoolman_multi_tool.cfg and Snap Orcaslicer that appears to be working i.e. it sets the correct active_spool in Fluidd/Spoolman during printing.

I want to test it a bit more before releasing it but I’m also curious if y’all are getting it to run with only the “”“” fix above.

9

Hi, you can check out my modifications. For my FilaMan https://www.filaman.app, I’ve created both a Moonraker component and a fluidd widget that supports all U1 toolheads. It can track consumption for each toolhead, you can use spools from FilaMan via fluidd, and used spools are automatically sent back to the U1 upon printer restart, ensuring they are correctly displayed on the screen and in Orca.

I’m currently preparing a PR for the paxx firmware, but you can also install it manually and test it right now.

10

Full spoolman consumption tracking and auto switch to selected tool etc is coming as part of new release in extended firmware.

keep an eye out for pre release schedule to be out before end of this week.

11

On the active spool defaulting to the wrong tool: there is a trap in how the U1 resolves T codes. Any Spoolman style macro that assumes T<n> means physical head n will attribute usage to the wrong spool.

A bare T0 to T3 does not select the physical head with that number. It goes through cmd_SWITCH_EXTRUDER_ADVANCED, where the A parameter defaults to 1. Anything other than 0 there means “resolve through the colour map”: it takes the number out of its own gcode id, calls get_extruder_map_index() on it and switches to whatever physical extruder that returns. T0 A0 is the one that addresses head 0 itself. T4 to T31 are macros over SWITCH_OF_EXTENDED_EXTRUDER, which looks the index up in the same map and then forces A=0. So with any non identity extruder_map_table, T1 can legitimately end up on head 3.

The map is readable, so a macro does not have to guess. Over Moonraker:

GET /printer/objects/query?print_task_config&toolhead

print_task_config.extruder_map_table is 32 entries of 0 to 3, logical colour to physical head. The head that is actually active is in toolhead.extruder plus extruder*.extruder_index. Reading those two beats inferring the head from the T code.

Second thing that will save someone a day: per tool consumption is not in printer state at all. The firmware does keep filament_used_g and filament_used_mm per logical colour, 32 entries each, but they live in a second dict that get_status never returns, so no Moonraker client can see them. Those numbers are also pushed in by the slicer with SET_PRINT_TASK_PARAMETERS FILAMENT_USED_G=... rather than measured by the printer. If you want per spool grams, the honest sources are the sliced file’s own per filament weights, which Moonraker already parses into file metadata. Failing that, your own accounting on tool changes.

What is exposed, plus what I would match spools on: filament_detect.info[i] carries the raw NFC reading per slot, including SKU, WEIGHT, DRYING_TEMP and the card UID, while print_task_config carries filament_vendor, filament_type, filament_sub_type, filament_color_rgba, filament_official and filament_sku per slot. For a Snapmaker spool the SKU is a much better key than the colour.

All of the above is stock firmware with no mods. I traced every field to a line in Snapmaker’s own U1-Klipper or U1-Moonraker while writing a Home Assistant integration for the U1, which also ships a fake Klippy that the real Moonraker fork runs on top of, so an integration like yours can be developed without tying up the printer. It is on GitHub as zkasuran/u1-companion, with the field by field citations in docs/PROTOCOL.md.