[ghzserg]

Description

Adds an Auto-map button to the AFC lane assignment dialog shown on print start.

On click, each tool used by the file is mapped to the best matching lane with filament loaded:

1. lanes whose material matches the file's filament_type are preferred (same check as the existing material mismatch warning);
2. among those, the lane with the closest color is chosen (CIE Lab ΔE between filament_colors and the lane color).

Each lane is assigned at most once, so the generated SET_MAP sequence gives the expected result regardless of order, also with AFC's swap semantics. Only mappings that actually change are sent, the same way as a manual lane selection in the dialog. The tool rows update from lane.map as usual.

The button sits on the left of the dialog footer, following the existing pattern in SpoolSelectionDialog (secondary action on the left, Cancel/Print on the right).

No new dependencies: color parsing uses @ctrl/tinycolor, which is already in the project.

Testing

• Multi-color file with lanes loaded in a different order than the slicer tools: Auto-map assigns each tool to the lane with the matching color/material, Print starts the job with the new mapping.
• Lanes without filament loaded are never selected.
• When the current mapping already matches, no G-code is sent.
• pnpm run lint and pnpm run type-check pass.

[github-actions]

Bundle size report (gzip)

Chunk	Base	Head	Δ
assets/index-*.js	170.7 kB	171.9 kB	+1.2 kB
assets/en-*.js	15.8 kB	15.8 kB	+60 B
sw.js	11.2 kB	11.2 kB	-5 B
assets/Dashboard-*.js	63.1 kB	63.1 kB	+4 B
assets/Tune-*.js	3.5 kB	3.5 kB	-3 B
assets/Diagnostics-*.js	15.9 kB	15.9 kB	+2 B
assets/DiskUsageCard-*.js	3.2 kB	3.2 kB	+2 B
assets/Timelapse-*.js	1.9 kB	1.9 kB	+2 B
assets/AppBtnCollapseGroup-*.js	638 B	639 B	+1 B
assets/AppColorPicker-*.js	13.0 kB	13.0 kB	+1 B
assets/AppNamedSlider-*.js	1.8 kB	1.8 kB	-1 B
assets/Console-*.js	368 B	369 B	+1 B
assets/ConsoleCard-*.js	2.0 kB	2.0 kB	+1 B
assets/FullscreenCamera-*.js	427 B	428 B	+1 B
assets/GcodePreviewCard-*.js	14.0 kB	14.0 kB	+1 B
assets/History-*.js	4.5 kB	4.5 kB	+1 B
assets/JobHistoryItemStatus-*.js	1.2 kB	1.3 kB	+1 B
assets/JobQueueCard-*.js	4.5 kB	4.5 kB	+1 B
assets/MacroCategorySettings-*.js	2.0 kB	2.0 kB	+1 B
assets/NotFound-*.js	439 B	440 B	+1 B
assets/Settings-*.js	23.7 kB	23.7 kB	+1 B
assets/System-*.js	2.4 kB	2.4 kB	-1 B
assets/TimelapseRenderSettingsDialog-*.js	1.8 kB	1.8 kB	+1 B
Total	2.9 MB	2.9 MB	+1.3 kB

_{120 chunks compared, 23 changed. Sizes are gzip, matching what nginx serves.}

[Lexapskov]

I need that too

[borec8719]

[thijstriemstra]

This branch is out-of-date with the base branch

[ghzserg]

This branch is out-of-date with the base branch

Updated

[pedrolamas]

@jimmyjon711 can I get you to take a look at this please?

[jimmyjon711]

@pedrolamas Seems like a good addition to me, thanks again @ghzserg for this addition.

20261107-1759-13.5479727.mp4

[Copilot]

Note

Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.

🟡 Changes recommended

The change needs revision because a moderate issue was found where the auto-map logic can silently skip tools or loaded lanes lacking a filament color entry, potentially making the action a no-op even when material-only matches are still possible.

1 open issue

• Auto-map skips usable lanes and tools without color data · New

What changed in this PR

Adds an Auto-map button to the AFC print-start lane assignment dialog, automatically mapping file tools to loaded lanes by preferring material matches and then selecting the closest filament color match, emitting SET_MAP only for actual changes.

Changes:

• Add an Auto-map secondary action to the AFC print-start dialog footer.
• Implement auto-mapping logic (material preference + color distance) and send mapping updates via SET_MAP only when needed.
• Add the English i18n label for the new button.

Review comments to address:

• Disable Auto-map until currentFile metadata (and optionally tool list) is available to avoid a “does nothing” UX.
• Align material mismatch handling with existing logic, especially when filament_type is unknown (e.g., "--"), and validate/normalize color strings before conversion.
• Avoid no-op behavior when colors are missing: fall back to material-only matching instead of skipping tools/lanes.
• Current greedy assignment may be non-optimal when tools compete for lanes; this conflicts with “best matching” expectations.

File	Summary
src/​locales/​en.yaml	Adds the AutoMap translation string used by the new UI button.
src/​components/​widgets/​afc/​dialogs/​AfcPrintStartDialog.vue	Adds the Auto-map button and implements lane selection + SET_MAP emission logic based on material preference and color matching.

This pull request requires changes.

_{Review effort: Balanced}

[pedrolamas]

Hi @ghzserg, thank you for opening this Pull Request.

Can I ask that you please check the copilot findings?

[ghzserg]

Hi @pedrolamas, thanks for taking a look.

The Copilot finding is addressed in 94fe3e6: tools without a file color and loaded lanes without a lane color now take part in auto-map. When color is missing on either side the pair is ranked by material only, and on equal score the lane the tool is already mapped to wins, so the result stays deterministic and doesn't overwrite a mapping the user already chose.

3eabdd0 additionally treats invalid color strings (AFC's SET_COLOR doesn't validate input) as missing instead of comparing them as black.

lint and type-check pass. Happy to squash if you prefer a single commit.

[Copilot]

Note

Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.

🟡 Changes recommended

The change still has a moderate unresolved defect in AfcPrintStartDialog.vue where unnormalized filament color hex strings can make TinyColor parsing fail and break the intended color-matching behavior.

1 open issue

• Raw hex filament colors break TinyColor matching · New

1 resolved since last review

• Auto-map skips usable lanes and tools without color data

_{Review effort: Balanced}

[Copilot]

Note

Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.

🟡 Changes recommended

A moderate active finding flags that the dialog’s greedy one-pass lane assignment can yield non-optimal tool→lane matches under the “each lane used once” constraint, undermining the stated guarantee that every tool gets its best available lane and warranting a more optimal matching approach.

1 open issue

• Greedy lane matching can miss the optimal per-tool assignment · New

1 resolved since last review

• Raw hex filament colors break TinyColor matching

_{Review effort: Balanced}

[pedrolamas]

Cursor review of the auto-map matcher.

The button, the footer, and the SET_MAP batch look right. AFC's cmd_SET_MAP swaps with the lane that currently owns the tool, and emitting each lane once (skipping lanes that already have the target) stays correct under that swap. Invalid colors are dropped, and missing colors lose to any real ΔE.

Two matcher issues should be fixed before this matches the PR description:

1. The greedy pass can leave a tool on a much worse lane.
2. A tool with no filament_type is ranked as a material match for every lane, which is not what isFilamentTypeValid does.

Recommendation: change the matcher. The SET_MAP wiring can stay.

[pedrolamas]

@ghzserg got a few comments more from my AI agents, please do take a look when you have the chance (hopefuly this is the last bit) and thank you for your help and patience!

[ghzserg]

Thanks @pedrolamas — all four points addressed in 8055c8a: the matcher is now a separate util with a minimum-cost assignment and specs, material and weight follow the row warnings, and a click without changes shows a message. lint, type-check and the new unit tests pass.

[ghzserg]

@pedrolamas Thanks for the review! While working on this dialog, an idea crossed my mind.
With so many new printers coming out with highly specific parameters, users need more control at print start. In my fork (z-mod), I’ve already added custom checkboxes to this window to toggle bed leveling, timelapse, and PA tuning.
To avoid bloat and hardcoding, I propose dynamically generating UI controls (checkboxes/inputs) in the print dialog directly from Klipper's start macro variables. This way, any specific options can be easily exposed via printer.cfg.
I want to make this a universal solution for both Fluidd and Mainsail. Could you advise where the best place is to discuss such cross-interface architectural proposals? Should I open a thread in the Discussions tab, or is there a shared space for these kinds of discussions?

[pedrolamas]

Thanks @ghzserg, really appreciate the quick turnaround on all the review comments! I'm happy with where this is now, so I'll approve and merge it as-is.

The start-macro idea is interesting, but it's a bigger change than this PR, so I would leave it as a follow-up if you are ok with that?

While there is no "official" cross-interface channel for Fluidd and Mainsail, if you post something on this Discord channel and tag me on it, we can start a discussion there.

[ghzserg]

Discord is blocked in my country, so I cannot post anything there or even register an account.
It would be better to open a discussion here:
https://github.com/fluidd-core/fluidd/discussions
Or here:
https://github.com/fluidd-core/fluidd/issues

[pedrolamas]

Fair enough, please open a new issue here then and we can follow up there.

As discussed, I will now merge and close this PR.