Feature Request: Add Klipper as gcode flavor/fw option

[mental405]

Version

Any version

Operating system type + version

Any OS

3D printer brand / version + firmware version (if known)

Any printer running Klipper

Behavior

Klipper does not support Jerk limits (M205) and its behavior regarding accel limits and velocity limits is not the same as Marlin. These values are set in the config file for the FW and are mostly left unchanged during a print.

Marlin FW flavor adds accel, jerk and max velocities limits to gcode (M201-M205). When these gcodes are read and executed, Klipper throws a warning or tries to set the wrong values.

Smoothie can be used but it ignores these values in print time estimations.

The goal is to have more accurate print time estimations by allowing machine limits to be specified in printer settings so that they are taken into account in the print time estimations, but are not propagated to the gcode. Since Klipper is gaining popularity and handles gcode differently than marlin, it seems reasonable that it should be it's own FW choice.

Example: A printer is defined with max Acceleration at 1500mm/s with various feed rates set for each feature. The print time estimation uses these values. When the gcode is generated, only the feed rate values are added to the gcode in the style of Marlin.

Project File (.3MF) where problem occurs

Any

[codefaux]

Any chance anyone could pay attention to this one?

I'm also using Klipper, multi-extruder, multi-MCU (so it HAS TO BE Klipper) on a printer I've just prototyped from scratch and run into a roadblock -- apparently Wipe Tower only supports Repetier/Marlin/Reprap?

Why? If it's just acceleration settings, I don't care.

What g-codes are required but unsupported? With proper documentation I can add them to Klipper myself, it supports hand-definition of G-Code commands so I'm willing to bet I could write the commands into Klipper if required for things like position capture, restore, etc -- unfortunately all we get is "unsupported".

[mental405]

This might be a non-issue now that gcodes can be overridden in klipper to make them do whatever you want.

On Sat, Feb 15, 2020, 7:07 PM daninfuchs notifications@github.com wrote:

Any chance anyone could pay attention to this one?

I'm also using Klipper, multi-extruder, multi-MCU (so it HAS TO BE Klipper) on a printer I've just prototyped from scratch and run into a roadblock -- apparently Wipe Tower only supports Repetier/Marlin/Reprap?

Why? If it's just acceleration settings, I don't care.

What g-codes are required but unsupported? With proper documentation I can add them to Klipper myself, it supports hand-definition of G-Code commands so I'm willing to bet I could write the commands into Klipper if required for things like position capture, restore, etc -- unfortunately all we get is "unsupported".

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/3452?email_source=notifications&email_token=AEHSR3KUFSTJMH2YKJYP73LRDB7V3A5CNFSM4KCPIJQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL32BMY#issuecomment-586653875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEHSR3MJX4EHPMHYMY2JN63RDB7V3ANCNFSM4KCPIJQQ .

[codefaux]

I don't feel it's a non-issue at this time.

Implementing as such requires the user to do a ton of work to manually add/edit/change Klipper's G-Code macros system to support each G-Code required by the slicer, as well as needing to know which codes the slicer was intending to use for each variant, as well as the risk of needing to be able to implement things we can't with Klipper's templates and values system.

I think a more forward-facing system might be to have checkboxes/radioboxes for supported and/or similar commands rather than "I'm using X firmware flavor, but I'm not even going to tell you which version so new/old things might be utterly broken" but that sounds like a non-trivial system to implement despite its necessity. Firmwares implement new features sometimes - is Prusa Slicer going to assume I'm on the new firmware with the new feature or the old one with a bug in another feature that Prusa has added a workaround for which is no longer required? We just don't get to know, and they have to assume.

Just my two cents, but for anyone looking "RepRap/Sprinter" flavor works with Prime Tower on Klipper, with no modifications to G-Code other than manually adding the T0/T1/T2 toolchange commands which Prusa Slicer assumes exist universally. (FWIW I can't figure out how to get it to stop backing my filament out FAR greater of a distance than I'm asking for between toolchanges momentarily. Maybe I'll just go back to Cura, even though Cura is literally agony to tune settings from scratch with a three-extruder printer and I hate how it assumes it can get away with a bunch of stuff off the bat. Seriously, let's fix Prusa Slicer.)

[Nandox7]

I generate gcode from Prusa Slicer that I use directly in Klipper, no change needed. For the most common and normal setup it works correctly. For the rest as you said you can generate macros in Klipper.

[mental405]

This issue was opened originally for print time estimation compatibility and machine limits and not for gcode compatibility.

Basically, having slicer allow you to provide machine limits and not providing jerk/accel settings

[Arcturuss]

Dedicated 'Klipper' gcode flavor can be useful in another way: to completely disable implicit autogenerated startup g-code

see https://github.com/prusa3d/PrusaSlicer/issues/2420 https://github.com/prusa3d/PrusaSlicer/issues/5345 also https://github.com/supermerill/SuperSlicer/issues/232

[lunatic1972]

Has anyone had any luck coding this into Prusa slicer at all, partial or otherwise? Is there still help needed? I would really love to see this feature implemented and I'm sure quite a few people that have klipper would too.

[guysoft]

This might be a non-issue now that gcodes can be overridden in klipper to make them do whatever you want.

Can you please provide a decent workaround? I still get this error

[mental405]

Check out the Klipper documentation related to macros and gcode overrides. https://www.klipper3d.org/Config_Reference.html#gcode_macro

[JdeV987]

If it is really an import feature to anybody, it is included in SuperSlicer, which is a fork of PrusaSlicer. I personally never had an issue with this and will stick with PrusaSlicer/Marlin gcode/Klipper.

[kaivalagi]

Is this ever going to be supported, given the lack of super slicer development nowadays why not take the hard work done on klipper gcode support in super slicer and make use of it in Prusa slicer? I am currently messing with gcode macros to map to marlon to deal with the lack of support but its not ideal for all the reasons above and due to unnecessary complexity. If there was organic supports in super slicer I'd still be using it which I think highlights where it sits in importance to me and likely many others.

[DatenThielt]

Adding my vote here, SuperSlicer development has pretty much halted and the developer has no time to work on it. I can forgo 90% of the features superslicer has and switch to Prusa with the exception of it not supporting Klipper (Or klipper uploading)

[bubnikv]

Klipper uploading is supported: Just select OctoPrint target. Klipper firmware is supported: Just select Marlin legacy firmware and follow Klipper manual.

[codefaux]

Klipper uploading is supported: Just select OctoPrint target. Klipper firmware is supported: Just select Marlin legacy firmware and follow Klipper manual.

That's unintuitive. I assume it's also well documented?

[Arcturuss]

Klipper firmware is supported: Just select Marlin legacy firmware and follow Klipper manual.

It's not the same. IIRC every gcode 'flavor' in prusaslicer has some implicit startup g-code, while 'klipper' option in superslicer doesn't.

[Nandox7]

Klipper firmware is supported: Just select Marlin legacy firmware and follow Klipper manual.

It's not the same. IIRC every gcode 'flavor' in prusaslicer has some implicit startup g-code, while 'klipper' option in superslicer doesn't.

Can you provide an example? I've been using Prusaslicer for long with Klipper without any issue or limitation.

[DatenThielt]

There are several places within the source (Lookup gcfMarlinLegacy within gcodeprocessor.cpp) Where the gcode is explicitly told to generate X gcode if the flavor is set to gcfMarlinLegacy , some of these may have unintended consequences

// Legacy Marlin does not have separate travel acceleration, it uses the 'extruding' value instead. const ConfigOptionFloats* machine_max_acceleration_travel = config.option<ConfigOptionFloats>(m_flavor == gcfMarlinLegacy ? "machine_max_acceleration_extruding" : "machine_max_acceleration_travel");

There are many examples of this but since its not documented I would rather have a Klipper Flavor that has expected behavior or at least reportable behavior, than selecting one that is changing the g-code based on a firmware that is classed as legacy

[Arcturuss]

Can you provide an example?

This issue is full of examples #2420

[mental405]

I think there is a lot of discourse over other issues that are not central to this issue. To summarize. There was never any question as to the compatibility of files from PS in Klipper. They work just fine. The issue is that it could be a better experience because Klipper is not "legacy marlin".

[kaivalagi]

Velocity and acceleration related g-codes available for marlin from Prusa Slicer are not compatible with Klipper though. We need implementations of g-code output for the equivalent klipper functionality for it to work "just fine", as per SuperSlicer.

[codefaux]

Velocity and acceleration related g-codes available for marlin from Prusa Slicer are not compatible with Klipper though. We need implementations of g-code output for the equivalent klipper functionality for it to work "just fine", as per SuperSlicer.

This. "It prints" doesn't mean the same thing as "it prints correctly." The things PrusaSlicer makes Kipper do are not the things PrusaSlicer wants the printer it is controlling to do. It operates, but it does so with some features not working properly without external work-arounds.

I don't understand the resistance. Klipper is big, it's popular, it fills a functional niche for many, it's not going away, and this slicer ALMOST works properly with it. I say we fix it. Most of the arguments against directly adding proper, full, complete Klipper support stem from "it almost does the right thing normally and you can hack fixes manually" and that isn't the same as "it works properly."

[bubnikv]

Most likely we will implement Klipper support to PrusaSlicer 2.6

[codefaux]

Most likely we will implement Klipper support to PrusaSlicer 2.6

I'm very glad to hear that, but I believe we have some questions.

Respectfully;

• Do you plan to implement G/M-code support? Or will it use Klipper's gcodes aka SET_VELOCITY_LIMIT? Will you supply your own deceleration values or allow that to be tuned? "Default" half-rate deceleration is not desired in my setup.
• What specific things will be changed to allow for Klipper support?
• Will the Klipper community get to help shape that support? It seems to me you don't have a developer using Klipper (making an assumption, but that's just because it shouldn't have been so difficult to get to this point) -- how do you intend to understand the best outcome? I'd like to be a part of this discussion, if you're forming a public-facing group.

I know this isn't going to be immediate but I feel like the "firmware flavor" drop-down is not the right way to handle firmware flavors.

It doesn't actually indicate what changes where, it's a black box option that few people understand the full implications of.

If it changes start gcode, shouldn't we put that in the start gcode box so users know what's actually happening? If it changes which command structure is used for various functions, shouldn't that be at least visible if not also adjustable by the end user?

The are options which technically belong to firmware flavor (arc support, firmware retraction, remaining time support, etc) which exist separately already, because grouping them into firmware flavor is too much kludge without being able to override them.

Nobody knows what they DO. Should the differences at least be documented someplace?

I've had to write macros to enable work-arounds for several issues I was having, and I had to do it blind. Run some stuff, verify every code used by hand, write macros to disable or alter existing commands, test and try again... I don't even remember which firmware I'm lieing to PrusaSlicer to claim I have.

My suggestion would be an "expert" flavor, which does nothing it isn't told in start/end/toolchange/filament/etc gcode, and exposes selectable options which 'firmware flavor' normally fiddles behind the scenes, ie a radio-selection for which acceleration command format to use, etc.

[kaivalagi]

My suggestion would be an "expert" flavor, which does nothing it isn't told in start/end/toolchange/filament/etc gcode, and exposes selectable options which 'firmware flavor' normally fiddles behind the scenes, ie a radio-selection for which acceleration command format to use, etc.

Or expose the variations per flavor as file based settings, and allow for new settings to be added. Something maybe for a future change once klipper is in the flavors list.

I've just started looking at the code in more detail now, around the libslic3r area and the gcode related classes, so am still getting to grips which the structure and logic. I plan to look into more detail in the coming days/weeks to understand what could be done, and will help if at all possible. In my day job I'm a c# developer so could be of some use here, time permitting.

Maybe a dev could explain to me, I assume there was a default flavor for all the gcode originally? "RepRap" perhaps? And that the initial gcode generation established for this is what's determining the output? Maybe if the code were to be refactored, where there are variations across most/all flavors , to use a new library that retrieves required gcode through configuration settings rather than hard coded in cpp files, much better support for gcode variation would be possible?

Like I say I've just started looking at the code and may discover some road blocks to this etc but any direction from those who live and breathe this code would be gratefully received, and if I can help I will.

[lukasmatena]

@kaivalagi

Velocity and acceleration related g-codes available for marlin from Prusa Slicer are not compatible with Klipper though. We need implementations of g-code output for the equivalent klipper functionality for it to work "just fine", as per SuperSlicer.

I just checked source code of SuperSlicer and the acceleration and velocity related G-Codes seem to be exactly the same as PrusaSlicer's Marlin (legacy). In fact, there is not much Klipper-specific behavior in general. Can you please be more specific in what G-Codes exactly are not compatible? Thanks.

@codefaux

I've had to write macros to enable work-arounds for several issues I was having, and I had to do it blind. Run some stuff, verify every code used by hand, write macros to disable or alter existing commands, test and try again... I don't even remember which firmware I'm lieing to PrusaSlicer to claim I have.

The same applies. Could you please be more specific and share what were the issues? The reason I am asking is that official Klipper documentation recommends to set "Marlin" firmware flavor and states that it would work. And many people are using it that way. If you were able to list what you think needs changing, it would be appreciated. Thanks.

My suggestion would be an "expert" flavor, which does nothing it isn't told in start/end/toolchange/filament/etc gcode, and exposes selectable options which 'firmware flavor' normally fiddles behind the scenes, ie a radio-selection for which acceleration command format to use, etc.

We are not planning to do that. Most people expect PrusaSlicer to "just work", and don't appreciate being able to configure everything imaginable. In general, we are against adding a knob just because it can be added. There are forks made by people who feel it differently.

[codefaux]

what were the issues?

OK, sorry this took a bit - wanted to dedicate the proper time, which turned out to be about two hours. I apologize if I sound longwinded, I'm trying to be thorough with reasoning as well as route so we understand each other. Apparenty I come off as aggressive sometimes, I don't intend to.

So, my main workaround to date has been switching to the Smoothie flavor, but I don't know if I'm missing out on anything by using that. Marlin (Legacy) uses several g-code commands which are unsupported in Klipper. Marlin2 seems to output near(?) identical gcode, at least in this tiny case. I also didn't look through the UI settings within PrusaSlicer to see if anything was disabled/changed wording/etc between Smoothie/Marlin/Marlin2/etc -- I'm not sure if I even caught everything. I don't know what all changes, with that option -- are any Settings selections changed/enabled/disabled when G-Code flavor is switched, or is it all in the gcode processing?

Back on target -- Marlin (Legacy)

M201 X9000 Y9000 Z500 E10000 ; sets maximum accelerations, mm/sec^2
M203 X500 Y500 Z12 E120 ; sets maximum feedrates, mm / sec
<M204 works>
M205 X15.00 Y15.00 Z0.50 E5.00 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

For reference, that entire section is omitted in Smoothie flavor.

This entire block does not work in Klipper and causes errors, which (it's been a while) I believe cause Octoprint to still ping a notification in-browser and to all supported notification agents, with each line. The printer itself will abort prints if it's configured to abort on gcode errors. Apologies for the image paste, it won't text-copy for some reason. I ran these by hand, as I don't want to deal with a full dry run.

• M201 -- Maximum accelerations are handled by SET_VELOCITY_LIMIT
• M203 -- No Klipper equivalent
• M204 -- Klipper documentation doesn't indicate if it supports P/R/T parameters. I actually don't have an immediate answer; I'm sure it's in an Issue somewhere, I can dig if desired but a direct ping @ Klipper's dev might do better. It specifies S alone. P/R/T is used during initial setup, before Custom gcode block.
• M205 -- Klipper does not use Jerk, it uses Square Corner Velocity, their calculations are available but (I think) unimportant to the slicer -- that's a user/machine-configured parameter. SET_VELOCITY_LIMIT [VELOCITY=<value>] [ACCEL=<value>] [ACCEL_TO_DECEL=<value>] [SQUARE_CORNER_VELOCITY=<value>] is the command for per-parameter control and M204 S<value> for acceleration. I'm uncertain how it handles deceleration in that command. My understanding is it follows the standard "decel=accel*0.5" formula, which I find produces worse prints. I prefer direct deceleration control, so I've written a macro to translate the M204 S<value> to ..actually I use a velocity-based conditional with some other stuff but that's in the weeds.

For some reason PrusaSlicer (all re: v2.5.0) sends a different acceleration command than Smoothie, as well. When talking to Smoothie, sent command is M204 S3500 ; adjust acceleration which does as expected with stock Klipper. When sliced using Marlin (Legacy) flavor, PrusaSlicer sends M204 S1500 ; adjust acceleration in the same spots throughout the print (consistently).

Those are the "probably affects everyone using Klipper" gripes that I found in a single test instance. I'll upload the two/three G-Code files for diffing.

I also manually set SQUARE_CORNER_VELOCITY using the SET_VELOCITY_LIMIT command, per filament, via PrusaSlicer's custom gcode sections. I've found print quality is effected by said setting per-filament, so having SQV re-adjusted mid-print by the slicer is undesired. SET_VELOCITY_LIMIT for start-up, M205 S<v> during prints for either travel or print acceleration control.

Firmware Retraction is controlled by specific commands, SET_RETRACTION to be exact. I override firmware retraction per-filament using custom g-code, but proper Klipper support would see PrusaSlicer issue SET_RETRACTION based on Printer Settings > Extruder <n> and Filament Settings > Filament Overrides per user config.

Progress and Messages are supported via M117 and M73 P<percent> -- it appears behind-the-scenes that with Smoothie, start-up sends M73 P0 R1 where in Marlin it sends M73 P0 R0 -- I'm not sure what the difference there represents.

Volumetric E is not directly supported, to my understanding.

Another thing is transparency of the gcode flavor setting. It's not made clear what switching the G-Code Flavor to Marlin (Legacy) vs Marlin 2 vs Smoothie vs TeaCup even changes without a dive into the code, to literally anyone that I've managed to reach. If we better understood what changed, it might be easier for the community to provide more specific feedback on what proper support looks like. If you can instruct me where to look or what to look for, I'll dive through the code to see which things are handled differently, and report back with what the Klipper way appears to be.

I'm eager to provide further feedback. This was literally a single layer print of a basic object I designed as a print test, so please request additional specifics where you need them, and/or test cases you'd like me to run.

Ignore the unfamiliar instructions in the start-up and end sequences, those are my personal macros, SimpleCalShape.txt SimpleCalShape-marlin.txt SimpleCalShape-marlin2.txt

I appreciate your time.

[lukasmatena]

@codefaux Thanks a lot for your response.

Intro: I did some git archaeology to check how we got to current state. Slic3r originally supported Marlin. Smoothie was added in 2016, but the behavior was the same as Marlin. When we implemented time estimator for Marlin (2018), we created the "Machine limits" table in Printer Settings, which exported the acceleration limits (using the M201, M203, M204 and M205 commands). This was used for Marlin only, later it was made optional after feedback received in #1202 and #1212 (2020). The whole situation was made worse by the famous decision on the side of Marlin to switch from M204 Sprint Tretract to M204 Pprint Rretract Ttravel. Because the meaning of T changed, this eventually forced us to split Marlin into two (#1089, year 2021).

Now to your post:

So, my main workaround to date has been switching to the Smoothie flavor

In fact, it is not that bad workaround. The behavior is the same as for Marlin, except the machine limits table is never emitted. Selecting "Marlin (legacy)" AND disabling "Printer Settings->Machine limits->Machine limits usage" should do you the same service.

Klipper documentation doesn't indicate if it supports P/R/T parameters

It does: https://www.klipper3d.org/G-Codes.html. They support M204 S (hence the advise to lie about having MarlinLegacy, not Marlin2). They also support M204 P T, but the meaning is different from Marlin and I personally consider it an abomination that should be avoided.

For some reason PrusaSlicer (all re: v2.5.0) sends a different acceleration command than Smoothie, as well.

This is also caused by the Machine Limits table. When it is set to be emitted into GCode, the values from the table clamp the feature-specific acceleration. So the value of 3500 from Print Settings is clamped by the 1500 from the table (for Marlin, not for Smoothie).

So, this much for the M201-M205 commands. After we separate Klipper flavor, the Machine limits will be available for time estimates, but it will not be allowed to emit them into gcode (so the user does not have to know that it must be disabled). Do you agree that this would fix the problem?

SET_VELOCITY_LIMIT for start-up, M205 S during prints for either travel or print acceleration control.

I believe you mean M204 S, correct? I'm not sure I understand the problem, though. Acceleration control is available in "Print Settings->Speed->Acceleration Control", and it can be disabled. What is missing is separate acceleration for travel. That will be added along with the Klipper flavor and in case the selected firmware flavor supports it (Marlin2, RRF), the acceleration will be set separately for travels and prints. If this does not answer your note, please expand.

Firmware Retraction is controlled by specific commands, SET_RETRACTION to be exact. I override firmware retraction per-filament using custom g-code, but proper Klipper support would see PrusaSlicer issue SET_RETRACTION based on Printer Settings > Extruder and Filament Settings > Filament Overrides per user config.

I believe that selecting "Printer Settings->General->Use firmware retraction" should give you "G10/G11" pairs, which should be supported by Klipper according to https://www.klipper3d.org/G-Codes.html#firmware_retraction Is that not correct?

Progress and Messages are supported via M117 and M73 P -- it appears behind-the-scenes that with Smoothie, start-up sends M73 P0 R1 where in Marlin it sends M73 P0 R0 -- I'm not sure what the difference there represents.

That is easy. The difference is again the machine limits table, which means different input data for the time estimator. The time estimates for your gcodes are 56s for Marlin and 1m0s for Smoothie.

Volumetric E is not directly supported, to my understanding.

This means that "Printer Settings->General->Use volumetric E" must not be enabled in the user profile, which is the case for almost all flavors.

Another thing is transparency of the gcode flavor setting. It's not made clear what switching the G-Code Flavor to Marlin (Legacy) vs Marlin 2 vs Smoothie vs TeaCup even changes without a dive into the code, to literally anyone that I've managed to reach.

I don't think it was ever supposed to be transparent. The purpose of the option is that the users selects which firmware they use, and PrusaSlicer will emit G-Code that can be consumed by that firmware. Vast majority of our users does not want or need anything else.

If you can instruct me where to look or what to look for, I'll dive through the code to see which things are handled differently, and report back with what the Klipper way appears to be.

I think I should state one thing straight. We are not planning to implement "the Klipper way". We want to emit something that Klipper understands. I feel there is a difference. So if it e.g. understands G10, we will not implement SET_RETRACTION which it also understands and someone thinks it is "better". We do not have resources to grant wishes to anyone who comes up with an alternative to an existing G-Code or creates a different way of doing something that is already possible. I believe that Klipper has macros for exactly these purposes, and PrusaSlicer G-Code Substitutions might also help anyone who wants to have the G-Code "his way". I know it may sound arrogant, but we have different things to do.

[codefaux]

did some git archaeology

Thanks for the dive and explanation, that helps me come to about the same place as you;

I personally consider it an abomination

.

(re: Smoothie flavor)

it is not that bad workaround

Thank you for confirming and expounding.

.

Klipper documentation doesn't indicate if it supports P/R/T parameters

It does: https://www.klipper3d.org/G-Codes.html.

I literally spent the entire time with https://github.com/Klipper3d/klipper/blob/master/docs/G-Codes.md open and missed that same note. I have no explanation, lol.

.

(re: accel value clamping)

This is also caused by the Machine Limits table. When it is set to be emitted into GCode, the values from the table clamp the feature-specific acceleration [...]

Oh, that's also nice to know. I didn't even notice the Machine Limits section toggling when I switched gcode flavors. I wonder how many people use Marlin flavor without understanding how many things it does weirdly...

.

I believe you mean M204 S

Yes. Cold fingers, tired mind, take your pick lol

.

I'm not sure I understand the problem, though. Acceleration control is available in "Print Settings->Speed->Acceleration Control", and it can be disabled. What is missing is separate acceleration for travel. That will be added along with the Klipper flavor and in case the selected firmware flavor supports it (Marlin2, RRF), the acceleration will be set separately for travels and prints. If this does not answer your note, please expand.

I was providing SET_VELOCITY_LIMIT as a stand-in for the M-commands sent based upon the Machine Limits block, assuming you intended to implement similar feature-level support for Klipper. It isn't necessary for function, but Maximum Acceleration, Maximum Feedrate, and Square Corner Velocity aka the analogue for Jerk Limit can be emitted via GCode SET_VELOCITY_LIMIT on an all-axes basis rather than independant axes. If you wish to provide the same support for Klipper, that data can be sent via GCode. I say this honestly, not with intended sarcasm etc -- I assumed "Supporting Klipper" meant the same feature level of support provided to Marlin, but partial support is good enough for me and probably most Klipper users -- we're clearly accustomed to hacking things together. One would argue that's kind of the point, even, lol.

.

I believe that selecting "Printer Settings->General->Use firmware retraction" should give you "G10/G11" pairs, which should be supported by Klipper according to https://www.klipper3d.org/G-Codes.html#firmware_retraction Is that not correct?

Klipper and at least a few other firmwares support modifying Firmware Retract data via gcode. SET_RETRACTION is the command to do this. I assumed Marlin and PrusaSlicer both also supported these overrides working as a gcode emit, so I was providing the means of doing so. I assume by your tone that I was incorrect.

.

I don't think it was ever supposed to be transparent.

Fair and understood. I would argue that without it being transparent, not even firmware maintainers know when you're treating their flavor incorrectly, so adding/modifying support becomes pretty guess-and-check/back-and-forth intensive with regular users as much as developers. Food for thought, I'm not asking for/expecting change.

.

We are not planning to implement "the Klipper way". We want to emit something that Klipper understands. I feel there is a difference.

I absolutely understand and support that. There is a very clear difference. I understand where you're coming from with the SET_RETRACTION example, I'll let my explanation a few paragraphs back handle that. I support and agree with the remainder of your statements.

You asked me, essentially, "tell us where it breaks" -- and as a coder you know we can't test every scenario. As a coder, you know not every condition is encountered in any single environment. I'm not asking for knobs on every random feature I/we can come up with, or explicit additional support for Klipper-only items. I'm asking to see what knobs you have already, so I can advise on wether or not they need to be adjusted to emit functional Klipper gcode. I expect no further changes cause undesired-but-still-operational action, but I don't know. It feels like you're saying "if you can't tell you're sick, you aren't sick" and if that's your target, I can accept it, I'm simply trying to explain my apparently excessively thorough approach.

.

How about Arc handling? (Does PrusaSlicer even do that?) Klipper can. Marlin can, but not on Delta printers. Smoothie can. Repetier can. Reportedly, Prusa firmware can. (Literally just looking at https://reprap.org/wiki/G-code for Prusa firmware, I've never used it.) Not all of them have it compiled in by default, maybe none do, and likely some of them added it partway through. I don't see a checkbox (seems that would be the best implementation) so I have to either ask, look at the code, or assume. I know to ask with arcs. What don't I know to ask about? I do not intend to be snarky, just clarifying why I wanted to understand where the relevant code is.

.

To my knowledge there isn't anything we've missed. Except this;

PrusaSlicer G-Code Substitutions might also help anyone who wants to have the G-Code "his way".

I've tried using G-Code substitutions. They don't work for many operations, because the substitutions are apparently run before a lot of the gcode is fully filled in. I've tried to replace some commands, block others, and extract information on used filament projections emitted into gcode on several separate instances, and it's VERY hit-or-miss. That's a separate issue (literally, I remember, aside from my own, seeing references in three separate git Issues, some closed, but I don't have them in front of me) but I agree that the "own way" people summarily need properly fully functional G-Code Substitutions that act on the entire emitted gcode file. The closest solution provided to the one issue I raised was a community suggestion to "write a post-processing script" and that's not easy to streamline into a multi-OS multi-target setup like mine.

.

I know it may sound arrogant, but we have different things to do.

It only sounds arrogant if I presume my goals should be your goals. This is rarely the case, and I understand and accept firm stances. This is not my project. I merely provide feedback in the event it brings our goals closer together. As the developers, your decision is the action and I'm not going to try to piss you off by arguing with you.

Thank you so much for giving me/us so much of your time. We value it, and I'm consistently giddy to see what new toys we get to play with, at every update. Ideally my passion does not come across negatively.

EDIT FOR FORMATTING. Apologies, I need to remember to look at the preview before posting, ffs.

[mental405]

I think Klipper has a large enough user base that it probably deserves a look. All these arguments are just about how to change a bunch of different settings to make the software sort of compatible vs choosing it from a drop down. Not everyone is going to know or care to know how to make those changes, now more than ever since more manufacturers are releasing printers powered by Klipper.

I opened this issue originally not because I didn't know how to do it, but because it probably needed to be done at some point.

[lukasmatena]

@codefaux Thanks for the answer. I will try to shortly reply to each of the points:

I was providing SET_VELOCITY_LIMIT as a stand-in for the M-commands sent based upon the Machine Limits block, assuming you intended to implement similar feature-level support for Klipper.

Ok, I understand now. We are currently not planning to allow exporting the machine limits into G-Code for Klipper. In fact, we believe that most people would not want to use it anyway.

Klipper and at least a few other firmwares support modifying Firmware Retract data via gcode. SET_RETRACTION is the command to do this. I assumed Marlin and PrusaSlicer both also supported these overrides working as a gcode emit, so I was providing the means of doing so. I assume by your tone that I was incorrect.

I see. The retract data you mention are not used when "firmware retraction" is set. In that case, only the G10/G11 pairs are emitted, but no configuration. That holds for all firmwares including Marlin (where the relevant G-Code is M207).

not even firmware maintainers know when you're treating their flavor incorrectly, so adding/modifying support becomes pretty guess-and-check/back-and-forth intensive with regular users as much as developers.

While I understand your point, the purpose of PrusaSlicer is not to make tweaking and prototyping firmware as easy as possible.

It feels like you're saying "if you can't tell you're sick, you aren't sick" and if that's your target, I can accept it

That's a good way of saying what I wanted to say. I am looking for things that Klipper people must get. Not for the list of things they would like to get.

How about Arc handling? (Does PrusaSlicer even do that?)

This is off-topic and shall be discussed in #4352. Short answer: no, PrusaSlicer does not emit G2 and G3 G-Codes as of 2.6.0-alpha5.

G-Code substitutions. They don't work for many operations, because the substitutions are apparently run before a lot of the gcode is fully filled in.

It runs before the whole G-Code is finalized, but most of it is already in place. You are right that you cannot do everything, but you should be able to do a lot.

I will let you know when we have a prototype Klipper-supporting PrusaSlicer ready for testing.

[shawe]

Klipper firmware is supported: Just select Marlin legacy firmware and follow Klipper manual.

It's not the same. IIRC every gcode 'flavor' in prusaslicer has some implicit startup g-code, while 'klipper' option in superslicer doesn't.

Can you provide an example? I've been using Prusaslicer for long with Klipper without any issue or limitation.

Read my previous comment, you have my example that is causing a bad bed level.

[strayr]

official Klipper documentation recommends to set "Marlin" firmware flavor and states that it would work. And many people are using it that way

I think the docs were written before anyone noticed marlin 2 behaviour had diverged. A change has been suggested, see above.

A klipper gcode flavour where it's clearly indicated what settings just aren't emitted, aren't implemented in klipper, or aren't currently emitted in a way klipper understands is immensely more helpful than expecting users to dig through gcode and to RTFM.

It would also be very cool if the machine limits behaviour was changed so gcode beyond the machine limits was not generated, currently this appears to not be the case in "use only for time estimates" but "emit to gcode" does, so a fix might be to not emit the limits to gcode, but still check for acceleration beyond the limits. Klipper does honour a max speed set with SET_VELOCITY_LIMIT but treats M204 Snnn as a new absolute acceleration limit.

I really don't like the way prusaslicer handles smoothieware, I like the safety net of machine limits. SuperSlicer's option to use them as safeguards but not emit might be better behaviour for when a firmware flavour can't handle the limits.

[lukasmatena]

Please, check out PrusaSlicer 2.6.0-alpha6. Feedback appreciated.

[codefaux]

Early tests seem great. I've fed a through things through it, nothing seems funky. I appreciate the handling and output, nothing noteworthy there.

I'm not really certain how to calculate Jerk as opposed to the Square Corner Velocity we're used to with Klipper, but that's a very minor influence in time simulation only so I doubt it's significant enough to merit action.

Unrelated to this discussion; Love the add-in of disabling heater commands, that works great with my staged preheat/presoak macro and now I don't technically have to override the M104/109/140/190 commands anymore, that's really nice.

Really appreciating the extra placeholders for filament consumption. I know that's not a big one for this discussion specifically, but that lets me write in-firmware filament spool tracking.

Thanks so much for all of everyone's great work. Will report back with other observations of note, if there are any.

EDIT: In light of others' comments, I'm adding; I'm using Octoprint for my success story. I have not tested mainsail nor fluidd as my setup predates them and I've no impetus to make the change yet.

[sjorge]

My test cube at least printed succesfully, I did have to pick octoprint for the connection type. Using mainsail/fluidd give me a 404

[treyd3]

My test cube at least printed succesfully, I did have to pick octoprint for the connection type. Using mainsail/fluidd give me a 404

When I try to create a Klipper Physical Printer and test the connection, either it gives error "Internal error: (1): expected value" or PS completely crashes. I'm running the Mac Universal Binary on an M1 MB Air.

[bitingsock]

My test cube at least printed succesfully, I did have to pick octoprint for the connection type. Using mainsail/fluidd give me a 404

When I try to create a Klipper Physical Printer and test the connection, either it gives error "Internal error: (1): expected value" or PS completely crashes. I'm running the Mac Universal Binary on an M1 MB Air.

Same happens to me on windows

[Nandox7]

Picked one of my printers configs that was using Octoprint+ Marlin and converted to Mainsail/Fluidd+Klipper.

So far all good, GCode created and correctly uploaded to Fluidd. Now up to do some more test prints.

[Ehmc130]

My test cube at least printed succesfully, I did have to pick octoprint for the connection type. Using mainsail/fluidd give me a 404

When I try to create a Klipper Physical Printer and test the connection, either it gives error "Internal error: (1): expected value" or PS completely crashes. I'm running the Mac Universal Binary on an M1 MB Air.

If you're relying on DNS to resolve the IP address, remove it. Enter the physical IP address of your printer. I noticed this issue as well and I typically use the server's name when adding a physical printer but it appears to be broken in 2.6.0alpha6. Alternatively, you can setup your physical printer in the current revision of PrusaSlicer (2.5.2), test the connection, then it should be available in the alpha.

[DaVinci-10]

i got the mainsail fix, ty it worked fine. PrusaSlicer-2.6.0-alpha6+1-lm-mailsail-fix-win64-g9346cf119-202304030833.zip

[codefaux]

Just an update to my prior report, still using Octoprint and no issues after around 50 printjobs. For what it's worth, I'm personally satisfied that w/ the Mainsail fix, Klipper support is solved.

[lukasmatena]

Thanks everyone for the feedback. Closing the feature request.