Does it look OK to merge?

Will this be merged ?

Dear @SoftFever, could you take a look, please?

Dear @Felix14-v2, could you review this PR too, please? It's a major regression for some Anycubic printers; see the linked issues

ANYCUBIC-3D/Klipper-go#13
jbatonnet/Rinkhals#407

I think you should ask developers directly in Discord. I'm just a regular user (and a translator and tester at the same time), so I don't have influence on the project. But I added this regression to the tracking issue. If you know any other confirmed regressions, please, mention them there as well.

@Felixoid please test with #11586

@robertbaker, not quite sure what you exactly mean. I don't have this printer.

You suggest cherry-picking/rebasing my PR on top of yours?

You can simply generate G-code from your branch, and then remove sed -i '/; filament_colour_type/d' $GCODE_FILE line.

It will be the same result.

Or, you can git fetch origin d3d6aa4686c2793ac347a78093360b7304722e6c && git cherry-pick d3d6aa4686c2793ac347a78093360b7304722e6c to your branch. It will allow testing if it's necessary to fix the issue with remote printing.

would be great to merge this, myself and other ppl are suffering from this issue, only fix, for me, is to go back to OrcaSlicer v2.3.1 Official Release

In discord, I got feedback that this fix is undesirable.

The workaround would be changing the format of the setting to the following:

; filament_color_type: ["1", "1", "1", "1"]

But I am not sure if it even works for the orca parser.

My personal easy-fix is adding the following line to a Process -> Others -> Post-processing Scripts

sed -i '/^. filament_colour_type = /d';

The problem solved, and probably it's a temporary fix until the gklib is patched.

My personal easy-fix is adding the following line to a Process -> Others -> Post-processing Scripts

sed -i '/^. filament_colour_type = /d';

I think that's not an option for Windows users

For Win, it should be a dedicated PowerShell script

@echo off
powershell -Command "(Get-Content '%1') | Where-Object { $_ -notmatch '^; filament_colour_type = ' } | Set-Content '%1'"

The script should then be added to the Process -> Others -> Post-processing Scripts

Can you verify if it works?

it's a temporary fix until the gklib is patched.

THIS is undesirable....
having a new official firmware update right now (to fix gklib) would probably break Rinkhals CFW, which is the main reason I use Orca on my Kobra 3v2 in the first place. Since jbatonnet (the Rinkhals creator) has decided to pause his work, it will be a long time before we can regain control of our printers.

PLEASE keep this in mind before upgrading your printer...

We need @SoftFever opinion here

@Felixoid my comment was just a warning against hastily installing new firmware if you, as a power user, care about Rinkhals!

You did a great job identifying the cause of the regression, among a multitude of commits. You really deserve a cold beer.

I've already mentioned that in Discord, but it worth mentioning there as well that this is not the only printer which firmware has issues with parsing slicer metadata. PrusaSlicer has a build-in post-processing features (like replacing/removing all the desired strings) for cases like that, but implementing it would be harder than just adding an option to the printer profile settings to not write the metadata to gcode files.

This would greatly improve compatibility with some end-of-life printers. The only disadvantage there is that this uncommon feature requires some space in the UI for yet another option. But I think that this can be easily solved by marking it as a developer-level option, especially since it is necessary only for profile makers. So it will be hidden by default and only visible after enabling developer mode.

Implementing such a complex feature (post-processing) is beyond my current capabilities.

I can probably try to add an option filter out all metadata, since it would be generally useful for every user.

For Win, it should be a dedicated PowerShell script

@echo off
powershell -Command "(Get-Content '%1') | Where-Object { $_ -notmatch '^; filament_colour_type = ' } | Set-Content '%1'"

The script should then be added to the Process -> Others -> Post-processing Scripts

Can you verify if it works?

I could not get that powershell script to work, so I reworked it to python alternative and added to my postprocessing script

I pushed another change. Under the Advanced option, Other -> G-code output -> Skip G-code config block

Workaround for Windows users (OrcaSlicer 2.3.2)

Root cause: OrcaSlicer 2.3.2 generates ; filament_colour_type = 1
in the G-code config block. The Anycubic gklib parser tries to split
this value by comma expecting 3+ elements, but only finds 1, causing
a Go panic:
panic: runtime error: slice bounds out of range [:3] with length 1
gcode_parser.go:520 → getCodeInfo()

Why some files work: Files where filament_colour_type = ""
(empty string) don't trigger the crash — only files with a numeric
value like = 1 crash gklib.

Fix for Windows (OrcaSlicer post-processing script)

1. Create fix_gklib.bat:

@echo off
set TMPFILE=%~1.tmp
findstr /v /c:"; filament_colour_type" "%~1" > "%TMPFILE%"
move /y "%TMPFILE%" "%~1"

In OrcaSlicer go to: Process → Others → Post-processing Scripts Add the full path to the .bat file
⚠️ Test from CMD (not PowerShell) when testing manually

I tested this PR recently, and skipping the config metadata completely fixed the problem with G28 triggering at the end of the print (Picaso firmware tries to execute all Gcode commands found in the config block).

@Felixoid huge thanks for the solution! The only issue I found is that (in my opinion) the setting should be placed in the printer profile settings (Basic information > Advanced, under the firmware type setting) instead of the process settings, because the entire printer is incompatible with the configuration block, not just the process profile.

@SoftFever could you consider this PR as a compatibility improvement candidate for the 2.4.0 release?

Sounds good, to the Machine G-code tab?

Or Basic information to the Advanced section?

I see, it's right there

I'll replace screenshot after the binary is rebuilt locally

Done, the PR is ready to review and merge