both extruder_colour and filament_colour are preprocessed

[dpeart]

I'm using super slicer.

Start G-code: MMU_START_SETUP INITIAL_TOOL={initial_tool} REFERENCED_TOOLS=!referenced_tools! TOOL_TEMPS=!temperatures! TOOL_MATERIALS=!materials! PURGE_VOLUMES=!purge_volumes! TOOL_COLORS=!colors!

Exported G-Code before Pre-Processing: MMU_START_SETUP INITIAL_TOOL=1 REFERENCED_TOOLS=!referenced_tools! TOOL_TEMPS=!temperatures! TOOL_MATERIALS=!materials! PURGE_VOLUMES=!purge_volumes! TOOL_COLORS=!colors!

Pre-Processed Gcode (errors): MMU_START_SETUP INITIAL_TOOL=1 REFERENCED_TOOLS=1 TOOL_TEMPS=250,250,250,210,210,210,210,210 TOOL_MATERIALS=ABS,ABS,ABS,PLA,PLA,PLA,PLA,PLA PURGE_VOLUMES=0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0,140,140,140,140,140,140,140,140,0 TOOL_COLORS=000000,FF0000,,,,,,,707070,707070,707070,707070,707070,707070,707070,707070

Additional settings from gcode file: ; extruder_colour = #000000;#FF0000;;;;;; ; filament_colour = #707070;#707070;#707070;#707070;#707070;#707070;#707070;#707070

it is including both, then HH fails to run. I have to edit the processed Gcodes to remove the filament_colour.

why are both included?

[ningpj]

extruder_colour and filament_colour would appear to be being merged into TOOL_COLORS.

• what version of superslicer, HH and moonraker?
• is this a single colour print as !referenced tools! only mentions a single tool?
• presume you have 8 extruders defined in superslicer to match your ercf configuration
• can you please attach an example unprocessed gcode file exported directly from super slicer that has this issue
• can you also please attach the moonraker.log section showing preprocessing details of the gcode file as its loaded

Does it make a difference if you explicitly specify a colour for each extruder in superslicer?

e.g

[dpeart]

Moonraker.log from processing file: `2024-05-09 14:22:01,266 [application.py:post()] - Processing Uploaded File: FromSS.gcode 2024-05-09 14:22:01,485 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Running MMU enhanced version of metadata

2024-05-09 14:22:01,492 [shell_command.py:pipe_data_received()] - INFO:metadata:Object Processing is enabled

2024-05-09 14:22:01,510 [shell_command.py:pipe_data_received()] - INFO:metadata:File 'FromSS.gcode' currently supports cancellation, processing aborted

2024-05-09 14:22:01,610 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Pre-processing file: /home/voron/printer_data/gcodes/ERCRFv2/FromSS.gcode

2024-05-09 14:22:02,027 [shell_command.py:pipe_data_received()] - INFO:metadata:Reading placeholders took 0.41s. Detected gcode by slicer: superslicer

2024-05-09 14:22:02,359 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Writing MMU placeholders,Inserting next position to tool changes took 0.33s

2024-05-09 14:22:02,425 [shell_command.py:_check_proc_success()] - Command (/home/voron/moonraker-env/bin/python /home/voron/moonraker/moonraker/components/mmu_server.py -m -n -p /home/voron/printer_data/gcodes -f "ERCRFv2/FromSS.gcode" --check-objects) successfully finished 2024-05-09 14:22:02,435 [application.py:log_request()] - 201 POST /server/files/upload (192.168.1.118) [_TRUSTEDUSER] 1250.31ms`

AfterProcessed.zip FromSS.zip

[dpeart]

I don't know where to find HH version, but I installed it a couple days ago. Hopefully it hasn't changed much.

git branch --show-current main

SS version is in the GCODE. HH unfortunately isn't.

[ningpj]

Issue reproduced. Quick work around until its fixed is to define a colour for all extruders in slicer to ensure extruder_colour has no null/blank entries in your super slicer config. I edited the generated gcode and set ; extruder_colour = #000000;#FF0000;#000000;#000000;#000000;#000000;#000000;#000000 and it expanded correctly - TOOL_COLORS=000000,FF0000,000000,000000,000000,000000,000000,000000.

Im not the HH maintainer but will have a look at this over the weekend. Presume filament_colour should take precedence should both tags be present in the gcode being parsed. Moggieuk might need to confirm this.

[moggieuk]

I'm back! filament_colour and extruder_colour mean different things. One is what the filament color really is and the other is what the slicer uses in its display. I forget which is which. @ningpj let me know what you find but I was sure HH was picking the correct one... worth checking though.

[ningpj]

@moggieuk because extruder_colour contains nulls (#000000;#FF0000;;;;;;) when the list is expanded, all(len(c) > 0 for c in colors) always returns false so the next match is processed and ; filament_colour... appended (expand) to the colors list. Should we parse and merge the list when values are null?

[moggieuk]

Ah, I see. So I think the correct code would be to have the correct size list but only set values for the non-null items. Let me look at this...

[moggieuk]

@ningpj would you mind running a test for me...

Change this line in mmu_server.py and restart moonraker: found_colors = all(len(c) > 0 for c in colors) to found_colors = any(len(c) > 0 for c in colors)

Then try your problematic test case. I think this is what I meant but don't have SuperSlicer to test.

[moggieuk]

Actually, I'm not sure this is correct either... Comparing to what I see in Prusa Slicer...

filament color is the array of colors for each of the defined filament. extruder_color is the array of colors that are rendered in the GUI.

I think that the logic should be:

For each tool:
   if extruder_colour is defined, use that, else use filament_colour

Does that make sense? I've never understood why the slicer needs the two colors..?

I think that filament color will always be set but you could reuse a filament definition for different colors in multiple extruders, hence the need for extruder_colour to override.

Does this thinking make sense? If so I can code that..

[moggieuk]

Ok. I created a fix based on my last comment. It's available in the issue290 branch until it's verified. To switch to this: ./install.sh -b issue290 Restart moonraker!!. Then test...

To jump back to main branch: ./install.sh -b main

Please can you let me know if this works. I does make the assumption that extruder_colours appears before filament_colours in the gocde file and it seems that all the slicers insert this annotation in alphabetical order so this works.

[ningpj]

need to correct a small python syntax error - should be colors = [n if o == '' else o for o,n in zip(colors,colors_csv)] not colors = [n if o is '' else o for o,n in zip(colors,colors_csv)] I havent printed any updated gcode as yet as printer is down while I finish off can/umbilical updates but looks like its expanded the colour list correctly using filament_colour to fill in the nulls.

[moggieuk]

Thanks. I tested in a separate program and the code was is None. Thanks for catching that. I'll fix in the branch.

[ningpj]

It was likely working ok but was triggering new syntax checks introduced in the python 3.8+ compiler (https://docs.python.org/3.8/library/exceptions.html#SyntaxWarning) when identity checks (is and is not) are used with certain types of literals (e.g. strings, numbers).

Tidies up the moonraker.log though so /home/pi/moonraker/moonraker/components/mmu_server.py:151: SyntaxWarning: "is" with a literal. Did you mean "=="?) warnings arent logged.

[dpeart]

I had a print fail, so I installed the patch and it worked.

thanks

[moggieuk]

Awesome! I'll push it to the "main" branch. You will need to reset back to that...

[moggieuk]

Ok The issue290 branch has been deleted because this is merged into the main branch

[miguelangel-nubla]

Seems there is a regression and filament_colour is no longer being checked in SS or PS. https://github.com/moggieuk/Happy-Hare/blob/62c6416d51a562a595dbe56dcab4f943411cfca6/components/mmu_server.py#L720-L724

[fluetke]

can confirm, tested with PrusaSlicer 2.8.0 on Mac, and current HappyHare version from head (commit cff405a7fd1d657aeb045e1fe0718a3fc8054731)

[github-actions[bot]]

This issue is stale because it has been open for over 30 days with no activity. It will be closed in 14 days automatically unless there is activity.