gcode-preview icon indicating copy to clipboard operation
gcode-preview copied to clipboard

Multi color support for multi color printer

Open orangeagain opened this issue 11 months ago • 8 comments

consider incorporating this functionality? To support multi-color models, assign different colors to each segment by detecting color-change commands, such as detecting a segment of G-code comment text like:

 ;change filament time 1
G1 xxx
;change filament time 2
G1 xxx

This represents a model with two colors. Then, using a JavaScript UI, specify the colors for these two filament segments, and the final rendering can be achieved, as illustrated below: image

orangeagain avatar Mar 07 '24 20:03 orangeagain

This is kind of similar but not exactly like https://github.com/remcoder/gcode-preview/issues/120

It may be a bit more challenging to have a good unified interface than it seems. The feature is quite simple in terms of explaining the desired outcome. But let's list down some different ways color changes are done to find the right approach to this.

Filament changes are done in multiple ways and not all of them have a "color index" if you will.

Marlin's M600 is a manual change directly in the gcode sequence. Unless there's a standardized comment syntax, there's no way of knowing if a 2nd filament change is a new color or the initial one. Cycling a list of default/param colors is probably acceptable, but is this the best API to support on the long term?

Printers with a single extruder, like the BambuLab's equipped with an AMS have custom gcode for color changes. It's probably easier to calculate the right color index to use. But if the user wants specific colors, they'll have to provide them in the right order and number. The approach may be similar with multitool printers like the Prusa XL. (Just ordered mine! So excited!)

What's proposed in #120 (at the end of the conversation) is to give via API some params to the user. They can parse and analyze the gcode themselves, to then apply the coloring the way they want. I'm not a fan of dumping all the responsibility on the user of the library, but I love the flexibility it provides when the desired features don't exist.

It's optimistic to support all kinds of color changes, but there is certainly a good starting point. M600 is probably the easiest to do first, alternating between two colors as a first implementation. It's also the most logical step, as the information that a filament change happened is explicit in the gcode.

sophiedeziel avatar Mar 08 '24 03:03 sophiedeziel

@orangeagain can you provide us with an example gcode file that shows the color change? (preferably not too big) It would help us with inventorizing the different flavors of multi-color printing.

The timing is great bc I was thinking to do a simple test implementation today. I wasn't thinking about M600 (change filament) but rather T1,T2,..Tx (switch toolhead) which tells you the number of the color (technically tool index). I think both are needed for a minimum level of support.

In the end we'll have to make a choice as to what we can support. But currently we don't even have an overview of what types/methods of multi-color are out there. So let's start there. I want to collect different gcode examples in ticket #123 .

remcoder avatar Mar 08 '24 07:03 remcoder

At a minimum we should support:

  • M600 (change filament)
  • T1,T2,....Tx (change tool)

Anything else?

I can check what gcode Bambulabs produces.

For now, let's say out-of-scope are mixing extruders but the api design should make that direction difficult.

remcoder avatar Mar 08 '24 12:03 remcoder

OK, I checked the gcode that Bambulabs generates and while they inject quite a lot of gcode to do a filament change, they use T1,T2,T2,T4 to select a color. So no different from Prusa's MMU.

remcoder avatar Mar 09 '24 20:03 remcoder

Created a POC for this feature. https://github.com/remcoder/gcode-preview/tree/poc/multi-color image

It mostly works but:

  • supports only T0,T1,T2,T3 tool changes (not even T4, etc)
  • some tests are failing
  • no API yet, so the colors are hardcoded
  • unsure about the state handling yet

At least we've got something to build on :D

I'd say the next step could be supporting M600. To see how that would work and wether it bites the current implementation.

remcoder avatar Mar 09 '24 21:03 remcoder

Come to think of it. M600 is actually quite different from color changing in a true multi-color scenario. What I mean is that if the printer can switch colors itself (MMU, XL, AMS) it should use T1,...Tx. It would even work with color mixing with Y-shaped nozzles when they use virtual tools (M164 - save mix as virtual tool).

What I'm saying is.. what about scoping this to just T1,...Tx and open a new ticket for M600? cc @sophiedeziel thoughts?

remcoder avatar Mar 10 '24 08:03 remcoder

Let's have two different tickets

sophiedeziel avatar Mar 11 '24 14:03 sophiedeziel

should be fixed in #125

remcoder avatar Mar 15 '24 23:03 remcoder