Feature Request: Add Klipper as gcode flavor/fw option #3452
Comments
|
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". |
|
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 ***@***.***> 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
<#3452?email_source=notifications&email_token=AEHSR3KUFSTJMH2YKJYP73LRDB7V3A5CNFSM4KCPIJQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL32BMY#issuecomment-586653875>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHSR3MJX4EHPMHYMY2JN63RDB7V3ANCNFSM4KCPIJQQ>
.
|
|
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.) |
|
I generate gcode from Prusa Slicer that I use directly in Klipper, no change needed. |
|
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 |
|
Dedicated 'Klipper' gcode flavor can be useful in another way: to completely disable implicit autogenerated startup g-code see #2420 #5345 |
|
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. |
Can you please provide a decent workaround? I still get this error |
|
Check out the Klipper documentation related to macros and gcode overrides. |
|
If it is really an import feature to anybody, it is included in SuperSlicer, which is a fork of PrusaSlicer. |
|
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. |
|
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) |
|
Klipper uploading is supported: Just select OctoPrint target. |
That's unintuitive. I assume it's also well documented? |
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? |
|
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
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 |
This issue is full of examples #2420 |
|
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". |
|
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." |
|
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;
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. |
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. |
I just checked source code of SuperSlicer and the acceleration and velocity related G-Codes seem to be exactly the same as PrusaSlicer's
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.
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. |
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 Back on target -- 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.
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 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 Firmware Retraction is controlled by specific commands, Progress and Messages are supported via 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, I appreciate your time. |
|
@codefaux 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 Now to your post:
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.
It does: https://www.klipper3d.org/G-Codes.html. They support
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?
I believe you mean
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?
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.
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.
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.
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 |
Thanks for the dive and explanation, that helps me come to about the same place as you;
. (re: Smoothie flavor)
Thank you for confirming and expounding. .
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)
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... .
Yes. Cold fingers, tired mind, take your pick lol .
I was providing .
Klipper and at least a few other firmwares support modifying Firmware Retract data via gcode. .
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. .
I absolutely understand and support that. There is a very clear difference. I understand where you're coming from with the 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;
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. .
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. |
|
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. |
|
@codefaux
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.
I see. The retract data you mention are not used when "firmware retraction" is set. In that case, only the
While I understand your point, the purpose of PrusaSlicer is not to make tweaking and prototyping firmware as easy as possible.
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.
This is off-topic and shall be discussed in #4352. Short answer: no, PrusaSlicer does not emit
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. |
Read my previous comment, you have my example that is causing a bad bed level. |
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 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. |
|
Please, check out PrusaSlicer 2.6.0-alpha6. Feedback appreciated. |
|
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; 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. |
|
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 |
|
Picked one of my printers configs that was using So far all good, GCode created and correctly uploaded to Fluidd. |
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. |
|
i got the mainsail fix, ty it worked fine. |
|
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. |
|
Thanks everyone for the feedback. Closing the feature request. |
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
The text was updated successfully, but these errors were encountered: