My printer doubles as a CNC mill (not a particular good one, but it does not matter here). For that purpose, I have written a couple of Klippy modules which are exclusively useful for milling operations. My question is now, are such features wanted in Klipper? If yes, I would invest some time to make the modules ready for integration.
I have mainly two modules which will be of general interest, and which are working closely together:
Probing in X/Y direction, to find edges of the workpart
A high-level workpart edge touch module which uses the X/Y probing results to set the origin and rotate the coordinate system (around the Z axis) to match the workpart.
Both features are in my eyes essential for slightly more complex milling operations, e.g. if you need to re-position the workpart in between milling operations.
If such features are wanted in Klipper, I would first go into details here in this forum topic to clarify how the implementation should finally look like (e.g. whether X/Y probing shall actually be an independent module or shall be part of the ordinary probing module).
It is usable, I am using it for quite some time now, but I do not yet consider it ready for integration - it’s more like a proof-of-concept.
Additionally, we might want to talk about the meaning of the G0 command. Klipper treats it as an alias for G1, but in the milling world G0 means to go as fast as possible while G1 respects the given feed rate. Treating both commands equal is a big problem, since feed rates may be really slow, so the movements intended to be fast will be equally slow, which may cost a lot of unnecessary extra time.
I can think of toolchanger printers that use XY probes based on nozzle contact, so this could help 3D printers as well. Your point about G0 and G1 is interesting. I’m curious if any modern slicer still uses G0 (AFAIK Orca doesn’t) or if they only use G1. If they only use G1 repurposing G0 could be more feasible. Although couldn’t you replicate G0 with a macro? Just read out the current velocity limits, pass to G1, then reset feedrate after?
Good point. That probably calls also for a deeper integration, since they might also do that with a loadcall probe I guess? We should maybe generally foresee a probing direction (well, the Eddy current probe is probably restricted to Z probing, but it could throw an error if something else is requested).
That still leaves a decision about the second part, which sets not only the GCode origin but also a rotation. I am pretty sure no 3D printer will ever really need that It would be nice to hear some general statement from the Klipper maintainers about milling-only features… I could understand if they want to keep Klipper a print-only firmware, although there are up-to-date commercial machines like the Snapmaker Artisan which combine 3D printing and CNC milling (my machine was also sold like that but that was 10 yeras ago ;-)).
I didn’t try that. Currently, I have implemented this in another module, which does more task special to my setup (like starting/stopping the spindle and setting the inverter frequency). While I think I could probably replace most of these things with macros, I am not sure if a macro can override an existing command. I will try. Nevertheless, if CNC mills are an “official” use case for Klipper, we might want to find a better solution. AFAIK every CNC milling tool path generator will use G0 for the rapid motion, which is also the official meaning of the G0 command. Even the Marlin firmware documentation claims that G0 might do a rapid non-linear move on non-Cartesian printers.
In my opinion there should be no harm in always executing G0 with maximum speed, but I have to admit that such change would be too big to really judge the full impact… Maybe a configuration option could help?
It’s always challenging to give advice on what future features will be merged. It’s really only possible to judge a PR after reviewing it.
That said, I can give a handful of some of my high-level thoughts. Please don’t take these too seriously though.
I think it would be great if the general Klipper ecosystem could handle typical “CNC features”. However, I suspect we’d need to merge in some kind of “official extension” support to Klipper first. That is, it seems unlikely that a single Klipper code repository could reasonably handle all of the wide ranging requirements for CNC and 3d printers.
Probing XY position seems generally useful, even on 3d printers. It also seems like that may be a good candidate for the Klipper “core” (as opposed to an “extension”).
In regard to the G0 command - if you want my “2 cents”, it is not a good idea to redefine the meaning of these old style g-code commands. That is, we want to define that Klipper will handle G0 exactly as Klipper handles G0 today. The concern with saying M123.4 really means X is that there is always some other group of people that will say, “No, M123.4really means Y”. A better solution is to introduce new MOVE_AT_FASTEST_SPEED type commands. That is, we want to be the ones who define the meaning of each command, and we want to avoid trying to react to some nebulous “real meaning” of each command. Also, FWIW, in my limited experience CNC machines are particularly bad at command standardization and the industry is filled with “post processors” that emit machine specific g-code.
Of course. The question was meant more strategically, and you answered it perfectly. Thanks
Good point. Is there already some ongoing effort for such extension support, or should we trigger a (separate) discussion about this maybe?
Good, so I will start with refactoring that code. I might come back with more specific questions first here in this thread - our would you rather discuss details already in a PR on Github instead?
I perfectly understand, just changing the meaning of G0 in Klipper is not a good idea. However, I am not sure if it is a good idea to invent a completely new name for this either. G0 is a lot older than Klipper or any 3D printing firmware, and as far as I know it has always meant a fast (possibly less precise) movement, as opposed to G1 which is a coordinated movement. Most 3D printing firmware gets this kind of wrong, because nobody cares about this in the 3D printing world. It is my impression that tool path generators for CNC milling may not always have the option to change a G0 command into something else by means of an integrated post processor. Also it will be very unlikely to convince manufacturers like Autodesk to put in a post processor for Klipper. That would leave users with the only option to run a post processing script manually, which is super annoying. This will already affect users which are just using very basic functionality.
My proposal would be to find a good compromise which works for both 3D printing and milling. The simplest would probably to add a configuration option which decides whether G0 moves at maximum speed or is a mere alias of G1, with the second option (alias) being the default.
I agree with you in this point very much for other commands, especially the “M” commands. Just G0 and G1 are very well defined, with G0 being neglected in the 3D printing world.
You can search the Discourse here for the past threads. I’m not aware of any active development over the last couple of months.
Here is fine.
My understanding of G0 is that it means: travel to the destination coordinate, but it is not necessary to move in a straight line to that destination. It was, as I understand it, a mechanism for simplifying machine movement for “non-cutting” moves. That is, machines with specialized kinematics might be able to relocate to a new position faster/easier/simpler if they are not constrained to move in a direct cartesian line. Thus one could optimize those moves where the toolhead isn’t interacting with the “print”.
Unfortunately, that description specifies a relaxed condition (no need for direct movement) not an actual description of the actions to take. If you need some kind of interesting toolhead movement, I think it would help if you could detail that movement mechanism. FWIW, I’m confident that whatever mechanism you come up with will not be compatible with existing G0 users (at least in 3d printing).
G0 is emitted by common 3d slicers - if it wasn’t emitted I wouldn’t have added support for it in Klipper. These 3d print slicers basically use G0 to mean: move to the destination coordinate and it is not necessary to move in a straight line if you are okay with horrific failures.
I assure you, neither of those commands are well defined. As a recent example you can look at the havoc with M82 and M83, wrt G90 and G91, and how it impacts G0 and G1. There’s also no consensus on movement buffering (lookahead queue), movement acceleration, which moves use acceleration, intra-move cornering velocity, etc. . All of these are important to get successful results.
As mentioned above, it’s already possible to override the behavior of existing commands using a gcode_macro.
Ah, looking at this a little closer, I guess you’re looking for the RS274NGC v3 usage of G0 (“Rapid Linear Motion”) which seems to basically say “it’s a G1 command but always at the ‘traverse’ speed”. I’m not sure if that interpretation differs from its v1/v2 specs (which called G0 “rapid positioning”) or if RepRap just went out on its own with “possibly not a linear move” (eg, G-code - RepRap ).
In any case, if you want G0 to not follow the F speeds, I think it would be simple to do that in a macro. The current code doesn’t support anything similar to the RS274NGC syntax (eg, inferring G1 on lines that just specify X1 or similar) so it seems odd that would be the only issue.
Perhaps something like the following (totally untested):
Yes, you are right, I was oversimplifying things. What I meant: If I search online for the meaning of G0 and G1, I get pretty much always the explanation that G0 means rapid movement while G1 means precise linear movement. “Nobody” (not even the Klipper documentation I think) really mentions that G0 is just an alias for G1. All CNC code path generators I have used so far (Fusion 360, FreeCAD, FlatCAM etc.) have used these commands in exactly that meaning. For all practical considerations, this seems to be a consensus in the CNC milling world. Maybe, even 3D printing slicers use it that way. I have not seen slicers issuing G0 for an extrusion, only for travel moves.
Anyway, if those 5 lines of config code are sufficient (which I will try soon), I am perfectly fine with that. It should be probably documented somewhere, maybe a new documentation section/page for milling would be good in the long run.
