Spoolman integration: multiple extruders/spools

[fweber3]

Is your feature request related to a problem? Please describe

The combination of Fluidd/Moonraker/Klipper/Spoolman works really fine for me (Thanks everybody!).

However they currently only work with printers with a single extruder. I would like to use multi-extruder printers with the same ease.

Describe the solution you'd like

1. I would like to see the current spool selection widget extended, so that I can select at least 2 spools at the same time, for the same print, one for each extruder. (This is my current personal need, although 10+ -extruder machines obviously exist). I would select spools A and B just like the current single selection, physically load both spools into the printer, and start the print.

2a. I already have gcode macros "T0"/"T1" for performing the extruder switch. These macros would be extended by a command "Now use filament A", "Now use filament B" .... referencing the previously /selected/ spools (and notably /not/ the backend's spool ID).

2b. For a test: a command to change spools is already available (at the Moonraker level, IIRC) but it requires an actual, hardcoded spool ID. It worked beautifully from an "envisioned" workflow perspective, but hardcoded spool-IDs in gcode will nevertheless not be my way forward ;-)

Describe alternatives you've considered

I had considered using the slicer (currently PrusaSlicer) for my spool management. However:

• I do not wish to duplicate spool mangement between spoolman /and/ the slicer. This is not feasible for >30 colors and several spools each.
• I usually pre-slice each model once, than print it many times with any/all of the 30 filaments(colors). Pre-Slicing lots of models to >30 files each just so that these include spool information is ... also not feasible. Even worse, the actual spool IDs sliced into the file keep changing quickly.
• In my workflow, slicing always implies a good check of the result. Slicing right before every print (to get a known spool) instead of pre-slicing would dramatically multiply the time spent on checks.

Therefore, the whole "Use the slicer" line of thinking seems a nogo for me due to matters of scale.

Additional information

I am not really sure how my request would integrate with QR-code scanning. Along with the spool presented, the system would suddenly need information about which extruder the spool should belong to - which is a per-print attribute, not a per-spool attribute. Perhaps showing an additional "extruder number" QR-code /before/ the spool is an option? On single-extruder machines, the whole complication is superfluous and must be suppressed.

[matmen]

Thanks for your feature request. The solution I'm thinking of looks like this:

• The T0..Tn macros will need to have an additional variable_spool_id (or similar, needs to be standardized across the frontends), defaulting to None
• The Tn macros will also need to call the SET_ACTIVE_SPOOL macro (or call the remote method directly)
• fluidd already detects the Tn macros, so we can show a spool selection modal with a tab for each tool
  • Selecting the toolhead via a QR code would be possible, but we will need to come up with a standardized QR code content for that
• After confirming the selection, fluidd can issue the following console commands for each selected tool:
  • SET_GCODE_VARIABLE MACRO=T0 VARIABLE=spool_id VALUE=123 to set the tools associated spool id
  • SET_GCODE_VARIABLE MACRO=T0 VARIABLE=color VALUE='"ffffff"' (optional, to show the filament color in the toolhead controls)
  • I'm not sure there's a better way to do this that doesn't involve sending console commands, maybe a Moonraker endpoint that can set gcode_macro variables directly?
  • The variables of the gcode macros can be read back by fluidd using the printer['gcode_macro Tn'] object, preserving the state after a reload

refs: https://github.com/Donkie/Spoolman/issues/277 https://github.com/Donkie/Spoolman/issues/239 https://github.com/mainsail-crew/mainsail/issues/1732

[matmen]

I have a working prototype which looks like this:

The only changes to the macros needed for this are:

• registering the SET_ACTIVE_SPOOL macro
• adding a variable_spool_id: None to the Tn macros
• adding SET_ACTIVE_SPOOL ID={ printer['gcode_macro Tn'].spool_id } in an appropriate place in the macros gcode section

The spool color will automatically be inferred from the macros spool ID variable. I think it makes sense for fluidd to also emit a SAVE_VARIABLE command when a [save_variables] section is detected in the config.

[matmen]

I'm not too familiar with toolchanger setups - for testing the linked implementation I've just created a bunch of shell [gcode_macro Tn]s to mimick what I think the behavior would be:

[gcode_macro T0]
variable_spool_id: None
variable_active: False
gcode:
    SET_ACTIVE_SPOOL ID={ printer['gcode_macro T0'].spool_id }
    SET_GCODE_VARIABLE MACRO=T0 VARIABLE=active VALUE=True
    SET_GCODE_VARIABLE MACRO=T1 VARIABLE=active VALUE=False

I've noticed that, instead of creating Tn commands, KTCC registers KTCC_Tn commands. Is the user meant to reference them in their own toolchange macros (hence the Tn macro name)?

[fweber3]

Hi Mathis

Sorry for my late reply, life interfered. To summarize:

• Storing the extruder-specific spool-id in a variable of the Txx macros (which can be read/set by any UI), then using that variable in a call to the existing
  SET_ACTIVE_SPOOL sounds absolutely workable to me - and very scalable.

• Having the filament color in a second, optional variable also sounds useful (and trivial) ... e.g. for gcode visualization?

• I cannot imagine the user side being made much easier than that, even with deeper changes to the code. I can, however, not offer any insights into the weighing of other solutions' feasibility vs. coding risk.

• The prototype already looks very polished to me :-)

• The integration steps look downright easy ("but documentation" blablabla g)

• Your testing macro is pretty much what my own macros do (see below), just without the hardware specifics

• I'm sorry to say I had never heard of KTCC until you mentioned it. Interesting project, though. Without diving into it: you're probably right. All slicers I know of will call the Tn macros, that cannot be disabled (... of course, if there is no such macro ...). Whereas the KTCC_Tn macro would need to be called either explicitly from a "standard" Tn macro OR more likely from a slicer-specific "before filament/after filament" section. I'd guess that the latter setup is more of a single-specific-printer thing that one eventually grows out of?

With best regards, and looking forward :-) , Florian Weber

---

My extruder switch macro. I removed some superfluous stuff. For me, the current extruder is not stored locally but in a variable of my own CONFIGS macro. But that should work exactly the same as your test setup (I think?). Your proposed code is marked with "NEW" or "MATHIS"

[gcode_macro T0]

NEW variable_spool_id: None

NEW variable_spool_color: #ABCDEF

gcode:

Catch the "change to same extruder" case

{% if printer["gcode_macro CONFIGS"].active_extruder != 0 %}
    RETRACT_ACTIVE_FILAMENT_TO_PARKED

    #------------------
    # Switch movement (and movement only) to extruder 0

    # Activate stepper in "extruder"
    SYNC_EXTRUDER_MOTION EXTRUDER=extruder MOTION_QUEUE=extruder
    # Deactivate stepper in "secondary_extruder"
    SYNC_EXTRUDER_MOTION EXTRUDER=secondary_extruder MOTION_QUEUE=
    # Remember current extruder
    SET_GCODE_VARIABLE MACRO=CONFIGS VARIABLE=active_extruder VALUE=0

    #MATHIS SET_GCODE_VARIABLE MACRO=T0 VARIABLE=active VALUE=True
    #MATHIS SET_GCODE_VARIABLE MACRO=T1 VARIABLE=active VALUE=False
    #------------------

    # NEW SET_ACTIVE_SPOOL ID={ printer['gcode_macro T0'].spool_id }

    UNPARK_ACTIVE_FILAMENT_TO_PRINTING

    RESPOND MSG="Current extruder now T0"
{% else %}
    RESPOND MSG="Current extruder now T0 (nothing changed)"
{% endif %}

-- Mit besten Grüßen, Florian Weber

PGP Key ID: 0x722D7E278C769B59 PGP Keyserver: hkp://keys.openpgp.net , hkp://keys.mailvelope.com

[matmen]

@fweber3 Hi Florian, thanks for your feedback.

The current implementation is ready for a first test I think. I've updated the docs to reflect those changes.

For now, I'm not sure there's a point in having Fluidd update the macros color variable, so I have removed that functionality for now. I mentioned it in https://github.com/fluidd-core/fluidd/issues/1269#issuecomment-1904768060 as a way to display the toolhead's associated filament color in the UI, but I think overriding the usual color icon with a colored spool icon (as shown in the screenshot above) looks much cleaner.

Any chance you're able to test out my branch? Any feedback would be much appreciated.

[fweber3]

Hi Mathis

I'd be happy to do a test run! However, my dev-tool skills have very much been rotting since pre-GitHub. My install is with KIAUH and I totally failed at a working deployment of your branch :-( , while official releases were not problem. If you can give me a hint (or a drop-in zip/tar?) I'll be right at it.

The documentation looks fine to me.

I agree with you concerning the color variable - knowing what to do when it actually is needed should probably be enough for now.

Am Samstag, 27. Januar 2024, 00:06:44 CET schrieb Mathis Mensing:

@fweber3 Hi Florian, thanks for your feedback.

The current implementation is ready for a first test I think. I've updated the docs to reflect those changes.

For now, I'm not sure there's a point in having Fluidd update the macros color variable, so I have removed that functionality for now. I mentioned it in https://github.com/fluidd-core/fluidd/issues/1269#issuecomment-1904768060 as a way to display the toolhead's associated filament color in the UI, but I think overriding the usual color icon with a colored spool icon (as shown in the screenshot above) looks much cleaner.

Any chance you're able to test out my branch? Any feedback would be much appreciated.

-- Mit besten Grüßen, Florian Weber

PGP Key ID: 0x722D7E278C769B59 PGP Keyserver: hkp://keys.openpgp.net , hkp://keys.mailvelope.com

[matmen]

Hi Florian,

no worries, I've built the latest commit for you: fluidd-spoolman-toolchange.zip To test this out, you'll need some sort of HTTP server. I personally use http-server for static files, but any alternative should be fine here.

I've also gone ahead and added functionality that updates the actively tracked spool when a new spool is selected for an active macro,

[pedrolamas]

FWIW, builds from PRs have the code build ready to download and test! 🙂

https://github.com/fluidd-core/fluidd/actions/runs/7681482706?pr=1324

As for execution, as long as you have NodeJS installed, you can download the files, extract, and then run npx serve . and get the static files served!

[fweber3]

Thanks for the build, and thanks for the hint @pedrolamas !

Unfortunately, neither version seems to work for me: When replacing the existing "fluidd/" directory (v1.27.1) at the filesystem level, the UI stops for a moment (as it should) and then comes back unchanged. Both builds worked exactly as before the swap, including the Spoolman widget only offering selection of a single spool and the Toolhead (transl.?) widget not showing any color info or spool icon on its "T0/T1" buttons.

I triple-checked that neither server-side nor client-side caching were in place. I think my T0/T1 macros are OK (see below, excerpted from printer.cfg), as compared to the docs linked above. The webserver is nginx 1.14.2. File permissions are identical to the working, official version.

Is there anything I missed or borked? I'll happily run tests, provide complete config/logs, or whatever it takes :-)

---

[gcode_macro T0] variable_spool_id: None description: Switch active extruder to E0. Do nothing if already there. gcode:

This if catches the "change to same extruder" case

{% if printer["gcode_macro CONFIGS"].active_extruder != 0 %}
    RETRACT_ACTIVE_FILAMENT_TO_PARKED
    # Switch movement (and movement only) to "extruder"
    SYNC_EXTRUDER_MOTION EXTRUDER=extruder MOTION_QUEUE=extruder
    # Deactivate stepper in "secondary_extruder"
    SYNC_EXTRUDER_MOTION EXTRUDER=secondary_extruder MOTION_QUEUE=
    # Remember current extruder
    SET_GCODE_VARIABLE MACRO=CONFIGS VARIABLE=active_extruder VALUE=0        
    UNPARK_ACTIVE_FILAMENT_TO_PRINTING

    SET_ACTIVE_SPOOL ID={ printer[ 'gcode_macro T0' ].spool_id }
    RESPOND MSG="Current extruder now T0"
{% else %}
    RESPOND MSG="Current extruder now T0 (nothing changed)"
{% endif %}

[matmen]

Hmm, not sure what happened there. The macro looks fine, and overwriting the files should work fine, too.

The following worked for me:

• Download the build artifact (https://github.com/fluidd-core/fluidd/actions/runs/7686212959/artifacts/1200646311)
• Upload it to your host computer to ~/fluidd/fluidd.zip
• run cd ~/fluidd/ && unzip fluidd.zip via SSH
• reload the UI using CTRL+F5

I don't think GitHub lets you download the artifacts from the command line directly, so you'll have to download it onto your PC first and then re-upload it to your host computer.

[fweber3]

That's more or less what I had done before, except that this time I overwrote where I had replaced. Still no success.

Summarising (since I'm at wits' end): I now have replaced and/or overwritten my known-good installation with three not-very-different(?) builds and according to three differently-sourced instruction sets (which basically all say the same anyway). To verify that the correct directory was actually being served I identically modified the version number in files fluidd/release_info.json and fluidd/.version. Afterwards, I restarted the webserver nginx, moonraker (required to pick up changed version number) and klipper (for good measure). After a final F5 in the browser, the changed version number was visible in the "Settings" tab.

I assume that at this point the update process itself was successful, from a file-download-and-webserver-reload perspective - moreso since the result was identical on all tries. I am then able to print as before, and I see no way but that I am doing so with the sent/downloaded improved code. Unfortunately, the Spoolman and Toolhead Widgets in the browser have not acquired their new capabilities.

I see two avenues two continue: either the code I tried did not contain the changes (unlikely, but could I check somehow?), or for whatever reason the new features are not active in my setup (again, could I check?). From my experience, a difference between "development" and "production" systems seems like the most plausible culprit now?

[matmen]

What's the commit hash shown at the bottom right of the page next to the version number?

Can you also share your klippy.log and moonraker.log?

[fweber3]

My "known-good" hash is 2056453, which is official v1.27.1 downloaded from GituHub. This is identical to your build https://github.com/fluidd-core/fluidd/files/14073992/fluidd-spoolman-toolchange.zip from yesterday.

The file fluidd-c54578fd47ec58ff30b4bfdf818aaa28de06a292.zip (as downloaded from your newest link https://github.com/fluidd-core/fluidd/actions/runs/7686212959/artifacts/1200646311 ) has the hash c54578f.

The download provided by pedrolamas (see above) has hash 266021b.

All values as displayed on the main fluidd page after appropriate refreshing. I could not grep "a6a62738" in any of the above. As that looks significant (to me), I'm temporarily holding back on the logs.

[matmen]

The https://github.com/fluidd-core/fluidd/files/14073992/fluidd-spoolman-toolchange.zip download should have hash a6a62738, and it shows up in the extracted contents (index-KXf4VOCe.js):

If it's showing https://github.com/fluidd-core/fluidd/commit/205645306d8af4692abdf3a408b94cae391f977b as the hash, I assume something went wrong unpacking the ZIP or the old content was still cached.

[fweber3]

Indeed - your file was zipped with its toplevel directory (which I actually prefer), where the others all were not. That threw me off - of course on the one file where it counted eyeroll. I now can confirm the hash a6a62738 in-browser and in file index-KXf4VOCe.js. I'll be using this version from hereon. Still no multi-spool anywhere.

See attached for both logfiles. I took the freedom of restarting both services and cutting the logs before the restart point. If you need more/longer, the full files are available. You will see the printer disappearing - I switched it off manually, it's loud.

moonraker.log klippy.log

[matmen]

Thanks for the logs. The setup seems fine to me, I'll take a closer look and get back to you.

[matmen]

I've tested both https://github.com/fluidd-core/fluidd/commit/a6a6273873e4de14daf402a60ebff17eda1fd385 and the latest commit on the branch, and they both seem to work on my end with your configuration. Any chance there's any errors reported in the browser console (F12 -> Console)?

[fweber3]

Nothing at all in loglevels "Error" to "Debug", sorry.

CSS yields ~20 of either "Error processing value for" (mostly geometry stuff?) or "Unknown pseudo class or element"

[fweber3]

PS: Frontend: Firefox 115.7.0esr on up-to-date Debian 11.8 (x86 Laptop) Backend: nginx 1.14.2 on up-to-date Debian 10.13 (Raspberry Pi 3B+)

[matmen]

Honestly, I'm not sure what's happening here. I've tried reproducing the issue in multiple ways (my own config, your config adapted to work on my machine, on my physical setup and in a virtualized one) but I can't seem to reproduce it.

If not even the "Change Spool" button changes to a dropdown, that makes me think something isn't reporting macros or macro variables properly. Can you share the output of http://<moonraker host>:7125/printer/objects/query?gcode_macro%20T0?

[fweber3]

If not even the "Change Spool" button changes to a dropdown

That is what I see, yes.

The browser response to http://<moonraker-host>:7125/printer/objects/query?gcode_macro%20T0 is:

{"result": {"eventtime": 170291.755343736, "status": {"gcode_macro T0": {"spool_id": null}}}}

The answer uses a lowercase null while the config file contains an uppercase Null, but I guess that's not the point. If I change the configfile value to e.g. 42, the browser output shows 42 instead of null. [Edit: after a restart, obviously]

I tried moving the fluidd/ folder to a totally different machine (also Raspi 3B+) not previously connected to 3d printing at all and served it with a quickly installed lighttpd-1.4.59. The experience was mostly[^1] trivial. Multi-Spool-UI did not show up, though.

[^1]: I ran into a short confusion with CORS. The very impressive UI design in the "New Printer" dialog probably saved me hours!

[matmen]

Yeah, the output looks fine to me. I'm out of ideas here then. @pedrolamas Have you had a chance to test #1324 yet, and if so have you had any issues getting it to work?

[matmen]

@fweber3 We've decided to ship the feature as-is for now, as we cannot reproduce the issues you're describing. We'll wait for other users feedback, until then I'm afraid there's not much we can do here.

[fweber3]

Frustrating as that obviously is right now: I do know the feeling from both sides, so thank you for the time you took trying to help me out. The things you showed definitely do justify closing my feature request, even if it doesn't work for me personally yet.

I'll wait for the feature to become available through official channels. I see a certain chance that this might help me. I'll also keep trying "other things" on-and-off on my end to get it running ... I want that feature, and it obviously can work. If anything resolves my problem, I'll definitely report it back here to help out others.

Public data dump, latest news of my trials:

• serving with nginx, lighttpd or Apache 2 doesn't make a difference
• browsing with Firefox 115.7.0esr (Linux Desktop), Firefox mobile 122.0 (Android) and Konqueror 20.12.0 (Linux Desktop) doesn't make a difference
• using a barebones printer.cfg+moonraker.cfg instead of my usual set doesn't make a difference
• despite being clueless, I can't get rid of the gut feeling that it's some backend tool's version somehow :roll_eyes:

[matmen]

@fweber3 Thanks, I think I figured out what's going on here. When a macro is edited via the UI it saves a copy of it in the database, which is then used to override some default settings. It looks like this also overrides the macros variables, so they will never change as far as the UI is concerned. I'll PR a fix soon, and this should be fixed with the next release.

[fweber3]

I can confirm that I usually edit my config files via the UI. Looking forward to the release, will report back.

[matmen]

@fweber3 FYI we just released v1.28.1 which should fix this issue

[fweber3]

I am extremely happy to report that 1.28.1 finally works for me, too! :partying_face: Thanks a lot for this great feature, which closes a big convenience gap for me. And thanks for the debugging which - I'm sure - was no fun.

I have not actually done a dual-color print so far, TBH. But since hardcoded "manual" spool changes already worked flawlessly, I presume that this part of the backend will be OK.

[fweber3]

Oh, one observation, don't know if that's a bug? (I'll gladly open one)

After setting T0 and T1, I can in addition select a third spool for the "Active Spool". This seems a little inconsistent - but it doesn't seem to change anything. As soon as T0/T1 is selected, the previously hand-selected "Active Spool" is overwritten with the one from T0/T1.

[matmen]

This is intentional, but I agree there isn't a huge use case for it. The idea is that you can still manually set an actively tracked spool, for example when there's no spools assigned to your toolheads.