This was a batch job to print custom designed sorting bin rails in 0.6mm. Using 0.6 cut the time of the print job from ~7 hours to 3:40. There are 24 print jobs to make the set. I ran them over the course of about a week consuming 5 spools of filament. (plus extras and prototypes!)
I’ve used the 0.6 for several plant pots. The other day I used it to knock out a quick template to punch holes in specific locations in sheet metal. The whole thing from idea to part in my hand was less than 30 minutes.
Prusa Slicer has profiles for each nozzle size. I just switch profiles. Super Slicer is the same thing.
You said it! Long term I think this is where we are headed. Right now Prusa is driving most of the slicer development and their machines don’t have Wifi by default, which seems like a per-requisite for this. Give them another 24 months to deploy a fleet of MK4’s and I think we will see this happen. Most Klipper machines have wifi now. It would be better if we did it first so we could have some say in the protocol.
Short term I would be happy if the machine stopped me from printing if I had the wrong type of filament loaded or the wrong nozzle installed for the print. These are simple things to check but its currently not implemented (front ends do check nozzle size, but its against the value in the config, because the extruder doesn’t expose the “live” value without my plugin).
Some random comments (in no particular order). Take them all “with a grain of salt”.
The only thing Klipper uses the nozzle_diameter for is to calibrate a sanity check on extrusion lengths. Perhaps we should rename the config to maximum_nozzle_diameter so users know to just configure the maximum size instead of the current size.
I suspect this is not a feasible goal. And I would caution against building lots of complexity in pursuit of it.
For what it is worth, an alternative goal would be to improve the user interface between slicer and firmware software, such that most users can just “upload a CAD file to their printer and click print”. Said another way, build a system such that “g-code files” aren’t user facing. Such a system would certainly be a lot of work, but I think it is both an attainable goal and would have a much bigger quality of life improvement for users.
Not scaring away developers is certainly a concern of mine! One way to encourage more developers, though, is to allow them to pursue their own code reviews, code release schedule, and deployment. That’s why we designed the Klipper API Server ( API server - Klipper documentation ). Great code is still great code even if it isn’t stored directly in the Klipper repository.
To be clear, I’m not saying that such future flexibility should not be directly in Klipper. (I haven’t looked at it enough to say one way or another.) It is something to think about though.
Certainly an intriguing idea. For what it is worth, I fear it may have a “chicken and egg” problem - I suspect it would require a lot of developer work to launch such a community database and it’s unclear if users would find a benefit unless many other users have contributed results, and thus it may be hard to get developers to work on it and hard to get users to contribute their results to it…
I agree. I have often cautioned against “programming in the config file”, and we are clearly seeing macros containing complex programs today. G-Code is a terrible “language” and some of the macros out there are incredible complicated.
For what it is worth, though, I think there are two really important (and unexpected to me) benefits of macros:
They’ve demonstrated that developers can utilize the functionality to build real-world features without going through the Klipper review, documentation, and merge complexity. That is, for some tasks developers have been able to effectively parallelize and scale their work using macros.
In many cases, it’s easier for a user to specify that an action should be accomplished by taking “step 1, 2, and then 3” as opposed to having to find and configure dozens of config options to accomplish those steps. As an example, I suspect building a “multi-toolhead module” would be dramatically more complex (for both users and developers) than defining T0 and T1 macros. Said another way, I suspect some actions really are best defined as macros, while some actions really are best defined with imperative code.
Hi,
I landed on this thread while searching for a solution to update the nozzle diameter live through some abstraction (with or without firmware restart).
I use klipper for 4 machines 2 of them being prusa MK3s, one trident and one switchwire. Both of those voron printers are equipped with revos and i frequently have to swap those nozzles as some material requires >0.5 mm nozzles or i wish to speed up prototyping etc…
For now i found myself in between two uncomfortable spots, wanting to reduce the amount and complexity of macros for those printers, and adding useful features through plugin development or klipper modification directly.
I set up some tooling that allows the spoolman filament database to be coherent with the orca-slicer profiles and run a lot of pre-print checks on those. Currently i check if the nozzle diameter in the [extruder] section matches the one i export from the slicer and exit on error when not. This is the primary reason behind my need to swap nozzles through mainsail (macro or natively).
The other topic regarding the filament db also rings a bell for me because i allready encountered some limitations regarding how things are done as of now… I run all my filaments through a calibration process (temp, pa, flow …) and keep track of those values through the orca-slicer profiles that are conveniently synchronized to the spoolman db. But, as pointed out here PA varies from nozzle to nozzle, from printer to printer and it is thus not optimal at all having one PA value for the filament (the one found at that time with that specific printer and specific nozzle).
I was going to try and launch some discussion on orca-slicer’s side to see if objects could be reorganized for a filament to have PA values specific to machines (by extension nozzle as i have to create a new machine for each nozzle size).
No real question here, just wanted to share my experience of the subject.
It is a complete mystery to me why everyone is so dogmatically attached to this nozzle size setting.
Kevin’s following statement makes it clear and it has been communicated countless times in this context:
The only “drawback” when you set it to, e.g. 0.8 mm, then a potential warning on too high extrusion will come a little later.
With the typical reasons like misplaced M83 this will not change a thing since it will overflow anyway.
I understand that klipper does nothing more than that with it. I read through this discussion prior to posting. I use it as a safeguard in order to avoid a print with a wrong nozzle to be launched. I just wanted to share my experience and the reasons why this could have been beneficial to me. I understand no such feature seems to be planned nor envisioned.
This will give you a nozzle variable that you can set without restarting and which is saved to disk and read at printer startup. Don’t forget to set [save_variables] properly in your config.
You could also omit __STORE_NOZZLE and only work with the printer object. Just as you like.
