Bug: Voron as presets but Klipper don't know G2, G3

Hey, that’s not how we will become friends…
You are slicing the G-Code with G2, G3, G17…

But that is not supported by Klipper. If it is good or not, that Klipper don’t know Cycle interpolation… Don’t know. But if you take Vorons as presets, you should speak Klipper with them.

1 Like

BTW:

Yes, a workaround is the config of klipper and

[gcode_arcs]
#resolution: 1.0
#   An arc will be split into segments. Each segment's length will
#   equal the resolution in mm set above. Lower values will produce a
#   finer arc, but also more work for your machine. Arcs smaller than
#   the configured value will become straight lines. The default is
#   1mm.

But still, if you offer the support, it should work with the default printer.

test this folk with full klipper support:

1 Like

Thats not the point or just another workaround.

It would be the same, that Prusa release a version of PS with X1C listing and not supporting the features.
If you release something, it should be Alpha and Beta tested and proven for the mass.
If not, fix it.

If you know what is wrong, why you don’t share the corrected g-code and create a pull - request?
this is open Source and everyone can work on it.
not only demand something…
… and I don’t think klipper support is on prio1 for Bambu itself.

I think they should just add a tooltip to inform you that arc support needs to be enabled on your Klipper firmware.

Short explanation how projects are staffed.
You have Sales Persons, Finance Persons, Project Managers, Mechanical Engineers, Electrical Engineers, Software Engineers, Industrialization, Test and Validation and so on and so on.

Most of them don’t know about the how to do of the other. The Software expect the CPU to run at the right clock time. And the electrical guy expect the PCB to fit into the chassis.

But they all are able to see if the work of the other department was not properly done. They report, that this won’t work. But the Sales guy don’t need to know how to write code.

So bug reporting is nothing demanding. Neither need anybody who do so, be able to fix it.

And if I have an Alpha or Beta… no issue. Report - fine. Nobody knows if that feature will make it to the RC.
In a RC - ooooh, the features should work!
But here we have a released 1.4.0.18

And they released that feature. It is Bambulab that want to become the major player and head to head with Prusa.
So must their attention to details. (At least that is my expectation.) You won’t find any PrusaSlicer release and not even a Release Canidate, that is not tested intensively on the new (as well old) features.

Instead of putting Voron (and with that Klipper as main OS for Vorons) on the list to make a new “ohhh, look, they open up the platform”, they should have tested the features or skip it till that is done.

And no, having fork a for feature fix 1 and fork b for fix 2 running - no.

Maybe a solution. I don’t know how the P1P is handling it. But in the Voron G-Code they also start the spaghetti detective M981.

It would at least technical provide a print. But, and I don’t understand currently why, small feature like the interpretation of “What Filament” is used isn’t done by Klipper. Even if that information is in the G-Code. At the beginning and SuSl and PS put it at the end. But…

Another Solution… because it is in the Software: Just have it deactivated by default for the Voron profiles…
Unbenannt