Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

both extruder_colour and filament_colour are preprocessed #290

Open
dpeart opened this issue May 9, 2024 · 15 comments
Open

both extruder_colour and filament_colour are preprocessed #290

dpeart opened this issue May 9, 2024 · 15 comments
Labels
believe fixed The bug is believed fixed in latest release Resolved Resolution suggested

Comments

@dpeart
Copy link

dpeart commented May 9, 2024

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
Copy link
Contributor

ningpj commented May 9, 2024

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
image

@dpeart
Copy link
Author

dpeart commented May 9, 2024

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) [TRUSTED_USER] 1250.31ms`

AfterProcessed.zip
FromSS.zip

@dpeart
Copy link
Author

dpeart commented May 9, 2024

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
Copy link
Contributor

ningpj commented May 9, 2024

Issue reproduced. Quick work around until its fixed is to define a colour for all extruders 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
Copy link
Owner

moggieuk commented May 15, 2024

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
Copy link
Contributor

ningpj commented May 16, 2024

@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
Copy link
Owner

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
Copy link
Owner

moggieuk commented May 22, 2024

@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
Copy link
Owner

moggieuk commented May 22, 2024

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
Copy link
Owner

moggieuk commented May 22, 2024

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
Copy link
Contributor

ningpj commented May 22, 2024

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
Copy link
Owner

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

@ningpj
Copy link
Contributor

ningpj commented May 24, 2024

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
Copy link
Author

dpeart commented May 24, 2024

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

thanks

@moggieuk
Copy link
Owner

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

@moggieuk moggieuk added believe fixed The bug is believed fixed in latest release Resolved Resolution suggested and removed Fix in Custom Branch labels May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
believe fixed The bug is believed fixed in latest release Resolved Resolution suggested
Projects
None yet
Development

No branches or pull requests

3 participants