Request: multi-head printing?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 32/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- computer-graphics
Research direction
The issue describes separate multi-head filament-change support and a more complex layer-batching optimization, but names no files, tests, or entry points. Start by clarifying whether the simple request should be split from the optimization work and how the proposed behavior should be specified. Done would require an agreed scope and acceptance criteria for the selected feature.
Written by the indexing model from the issue text.
Description
Hello,
I have a 2 tiered feature request- one is very simple, and one is more complex. I can separate them into two issues if needed.
-
support multi-head filament changes.
This means that some printers (like the snapmaker u1) can have 4 filaments ready to load at once. What I'm requesting is a mode where I can set it up such that I only need to swap the filaments once every 4 changes. This support is the simple feature: make it so I can set it so that I have N-printer heads, and only stop after printing N different colors to swap filaments. -
More complexly, this means that with N filaments, you can 'batch' layers.
Say the color order Red-White-Pink-Grey would represent a pixel1extremely well. This is good for us. but not all pixels are the same color as1. some pixels, maybe a pixel2, would be better represented by the order Red-Grey-Pink-White. With 4 filament heads this is extremely simple for a user to do, and is 100% automatic. so given that for every filamentTd < N * Layer_height, the number of unique shades and hues that can be made with N printer heads in N layers is N^N (256 for 4-heads, 3,125 for 5 heads, etc), and the only cost is the time it takes to do N * (N - 1) tools switches (ie tool_heads * layer_count-1), which is automatic.
I'd like to formally request both, but I understand that the optimization algorithm for #2 is.. well, a big challenge, as this means that every group of N layers can be shuffled, and even repeated/omitted if preferable. I'd be happy to lend a hand in programming either of these if contributions are open.
- Dominant language
- TypeScript
- Stars
- 290
- Forks
- 32
- Avg merge
- 6h 2m
- Merged PRs (30d)
- 7
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from vycdev/Kromacut
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Experimental WebAssembly acceleration for compute-heavy algorithmsMay be free again @vycdev claimed this 80 days ago, and no pull request is open. Openenhancement
-
enhancement good first issue help wanted
Difficulty 5/5 Over a week Newbie friendliness 55/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 42/100
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 70/100
siyuan-note/siyuan#20517 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
NaturalIntelligence/fast-xml-parser#890 · 1 comment ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
zsviczian/obsidian-excalidraw-plugin#3000 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
pnpm/get.pnpm.io#68 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
nuxt-modules/better-auth#578 · 2 comments ·
Maintainers usually reply within 1 day