Change Nozzles Without a Restart

[garethky]

GitHub - garethky/change-nozzle-klipper-extra: klipper extra that swaps...

These things have convinced me to actually swap nozzles on my printer. Currently klipper requires a config change and a restart for every nozzle change. But I figured it shouldn’t have to be that way. I couldn’t really make this work with a macro because I cant update the internal variables in extruder so for now its an extra. Hopefully it can be in klipper at some point in the future.

Now I have this in fluidd and I change nozzles with just a tap:

Some things you can do with this:

• Change nozzles without restarting the printer. Nozzle size is save in [save_variables] per-extruder and reset on startup.
• Set the PRESSURE_ADVANCE value from your slicer based on the size of the nozzle in the extruder at print time. (example in README)
• Check that the nozzle diameter required for a print is actually installed and stop the print if it isn’t (especially useful if you often re-run old gcode!)
• Write macros that customize the extrusion width based on the nozzle
• Keep your printer safe from large extrusion moves. My previous solution to all this was to configure the printer for the largest nozzle, which could lead to problems if a smaller nozzle gets swapped in. This makes doing the right thing easy.

[garethky]

Thanks to @pedrolamas, Fluidd already has one feature that integrates with this! It has an extruder stats panel that uses the nozzle_diameter, but since that doesn’t exist it on the extruder object it always defaults to 0.4mm. I was shocked when it just started doing live updates when I changed nozzles.

The estimation of the maximum volumetric flow rate is based on some math in Fluidd and not the actual setting in the guts of the extruder instance. I also exposed the max_extrude_cross_section which is used to limit the extrusion volume that klipper will enforce on extrusion moves. Its also settable when you call CHANGE_NOZZLE. We could update the math to use that value and put in a similar default for now.

[pedrolamas]

Hi @garethky, Fluidd should take into account the information from the currently selected extruder in Klipper, specifically the filament_diameter (defaults to 1.75) and nozzle_diameter (defaults to 0.4). if You have a configuration that is failing this, please do share it and I can see what we can do about it.

That information together with the selected extrusion speed (and assuming a layer height of 0.2), is enough for Fluidd to calculate an estimated max volumetric flow using the “stadium area” formula, the same that Prusa Slicer (and derivatives) use.

Bondtech and E3D also use the same formula!

[garethky]

Yes, that math is sound, I didn’t mean to make it sound like it wasn’t.

Kudos again on grabbing the value out of the printer. I’m hoping since you did that you might be interested in this extension or merging this functionality into klipper itself. I welcome your feedback.

I was trying to explain about the max_extruder_cross_section value. I’m adding that to the printer object as well and I think that has value in understanding how much your printer can extrude before it throws the “Move exceeds maximum extrusion” error. This is a solid explanation that has the math right

I was hoping that showing this calculation in Fluidd might help people understand what the enforced limits of the printer actually are. Maybe we could say something like one of these:

• The maximum line width of a 0.3mm layer is 2.1mm (0.64mm²)
• For a 10mm extrusion move the maximum extrusion length is 8.8mm (0.64mm²)
• To extrude at the estimated extrusion rate of 12mm³/s the toolhead must move faster than 18.75mm/s (0.64mm²)

They are all a bit alien vs how the slicer explains things but they are the real limits of the printer.

[pedrolamas]

That does sound like a interesting idea!!

I will have to check, but we might indeed be able to put this as part of that report!

[garethky]

How would people feel about making this work like the Filaments extra? Meaning:

• Each nozzle is a preset with a name
• You can store additional data values with the nozzle preset
• A “Nozzles” object on the printer will expose the set of available nozzles for front ends to display

I was thinking about my Rapido with the optional high flow setup. I could have one set of nozzles for normal flow and one set for high flow. The additional data could be used to store the purge volume for filament change macros which varies with the length of the melt zone.

Upside is I can share my nozzle config between Fluidd, Mainsail and Klipper Screen. Downside is it would be more complex than just assigning a nozzle diameter.

[MadD0c]

FYI there is a typo in the readme.

Under Config Reference it has [change-nozzle] but should be [change_nozzle].

Was scratching my head for ages why I kept getting an error when tryint to load it.

[garethky]

Thank you for the bug report, doc’s updated

[Florian]

Hi @garethky

I was wondering why you are using save_variables instead of a database to save filament specific data. This would reduce user error issues considerably.

I am working on firmware retraction and was thinking of implementing a filament database to move most filament data to the printer and away from the slicer.

I will probably implement gcode intercept and manipulation to get full firmware retract functionality. Hence, the filament data could be used to change temperatures, flow multiplier, pressure advance and retraction settings at runtime while printing. This would allow slicing a file once and basically run it on any printer with any filament provided the nozzle diameter matches the installed nozzle.

Are you interested in working on this together?

BTW, next step would be to incorporate filament tuning in the firmware…another goodie the community is waiting for =)

Cheers
Florian

[garethky]

Sent you a DM, this is a lot to unpack in this thread.

[Sineos]

@Florian

and was thinking of implementing a filament database to move most filament data to the printer and away from the slicer.

My 2ct: Moving existing features (Slicers already have more or less advanced filament database capabilities) down the process chain to the firmware is not the right approach.

The main focus of the firmware should be controlling the printer’s hardware and executing commands it either receives via a gcode file or via the webinteraces.

As such, I’d consider the slicer the right place to manage filament information. The second best place would probably be the Moonraker layer but this could be debated as well.

I’d recommend to align on such an idea with @koconnor first since from experience such features tend to be not accepted for main line.

[Florian]

Hi Sineos

Thanks for your thoughts. The process of calibrating filaments in place at the moment is honestly cumbersome. I also find the filament database solutions available in the slicers sub-optimal. Most of the issue comes from the slicers trying to be configurable for many printers and filaments. Especially for beginners, the learning curve is very steep. I think, having filament related settings stored in the firmware would greatly simplify the work flow. Meaning, instead of having to slice a model 5 times (either because you run 5 printers, 5 filaments or need 5 tries for a successful print) and having to develop your own file naming system in the process, wouldn’t it be great to slice once and, instead of worrying if you set the right printer and filament and sent to the intended printer, just choose whatever filament you want on the physical printer you intend to use?
Changed your printer by e.g. going direct drive? Well, happy reslicing. Want to try out a different slicer? Well, happy typing in settings… And so on. As added bonus, failure rate can be reduced or quality can be improved if you can enable/disable e.g. wiping at runtime.

Also, filament calibration is an art by itself. Especially for beginners, learning what calibration prints to do when, how to interpret the results and store then on the slicer, takes time to learn and comprehend. Many people give up because they can’t get past this hurdle. By locating calibration prints on the printer, making it a guided procedure with automatic storing of retrieved settings, the whole learning curve is reduced. Think of it as automatic calibration for less expensive printers compared to e.g. Bambu Labs.

I agree that experienced users will likely not see as much benefit (at first), but it would help beginners a ton to get into the hobby. At the end, it’s a matter of philosophy. As it stands now, slicers have the monopoly on setting storage and handling, resulting in a highly repetitive a tedious work flow. I assume this comes from how things developed in the past. Just like the QWERTY keyboard layout, past developments don’t necessarily pave the way into a better future. Firmwares in the past simply couldn’t include filament settings management… That doesn’t make it a bad idea.

I agree that ultimately, the core developers and maintainers need to make a decision if klipper should go there or not. Given klipper architecture, I believe that it is the only firmware that can add this functionality. Might be worth going for then. As for including this functionality in the UI, that’s doable too but would take away freedom from the user to choose the UI he wants if filament management should be dealt with locally. Anyways, I hope the idea is clearer now and makes more sense.

Cheers Florian

[Sineos]

• Developers come and go:
  • You implement this feature, adding potentially hundreds of lines of code and maybe even external dependencies (DB layer)
  • Who is going to maintain, fix, document, support, migrate the stuff in the future?
• Having multiple instances dealing / conflicting / overriding with the same values IS a nightmare, especially for beginners
  • Seen here on a daily basis: 1200 lines of macros in the cfg and not even a correct [mcu] setting
  • Especially beginners overload their install with every piece they can grab and later scratch their head when things get funky
  • “Hey, I sliced at 210°C and Klipper is using 480°C. This is a BUG. Fix your shit!”
• Where do you start and where do you end?
  • Filament tuning is a bit more than retraction and temperature. Quite some additional Slicer settings will mess with it, e.g. coasting, wiping, internal pressure advance, layer-time, cooling and you name it
• No standards
  • Easy to compare to a Bamboo with more or less closed ecosystem
  • Crumples to dust if you need to care for a completely unpredictable foundation in terms of hardware and used filaments
  • At least from my experience, even PLA is not PLA and I play a lot with different filaments, so my slicer’s database is easily around 50 different filaments

But in the end, you do not need to convince me.
As stated, I’d recommend to align first and then invest work unless you do not mind to do it purely as learning experience.

[garethky]

My plugins goal is to help with filament handling tasks, like load, unload and purge. Combined with the the nozzle change plugin is useful for running calibration prints.

I’m a fan of the Marlin pressure advance tuner because its very quick to print. Someone converted it to Jinja so I can run it as a macro. Having the filament temperatures and a nozzle diameter means I can run a test print with no user input. Generally I only have to tweak the filament temp for the exact setting I’m going to use in the slicer, but that’s optional. Now that I have this set up I actually do take the time to calibrate Pressure Advance for my filaments.

I think this could be a lot better. There is a video about reading the PA setting with a camera and machine vision. Imagine syncing this data back to the slicer!

[Sineos]

I agree that helper functions to tune in some properties of the printer itself, filament etc, would be helpful.
@dmbutyugin already started out on such a journey here Extruder PA synchronization with input shaping - #2 by dmbutyugin and I find it extremely useful.

Still I believe this should rather go into Moonraker, e.g. as some sort of calibration plugin that generates appropriate gcode and executes it instead of overloading the “firmware aspect”.

In any case generating tuning gcodes and helpers is a different story to implementing a filament database into Klipper.

[Florian]

Hi Sineos

Thanks for your valuable input,which I’d like to comment as follows:

1. Developers come and go: that’s right. Hence, following this logic, developments of this open-source project are reserved to developers that have proven track record. This means, new joiners like me will never get a chance to contribute because they may not maintain their code in future. Sad and not really an argument to the matter as such.

2. having many instances screws things up: I read the posts about the discussion on jinja2 and how powerful macros should be. Initially, the sentiment was that extra functionality should be implemented in code rather than macros. I agree with that 100%, given that macros go out without quality control. This will ultimately backfire on klipper. Adding more macros for calibration prints just makes this mess worse.

3. Start and end: Coasting should be disabled if pressure advance is enabled. Wiping and internal pressure advance can be implemented in firmware. With Layer information available (and even without if the firmware reads gcode and detects layer changes) layer-time could also be handled fairly easily simply speeding a layer down, if needed. The corresponding gcode is already available. Cooling is indeed a tricky one but also doable. Hence, except for actually calculating move paths and very special settings, the bulk of settings could be handled/manipulated outside of the slicer to
   accommodate different printers/filaments.

4. No standards: I think we have several misunderstandings here. I mentioned BambuLab for their autocalibration of pressure advance (or whatever they call it). This accepts any filament and is open in this aspect. The closed part comes in when using their filament… Second misunderstanding we may have, by referring to a database, I don’t mean an actual database of filament settings to be shared on mainline. As you pointed out, there are way too many combinations of filaments and printers out there for this to be remotely feasible. Hence, what I meant by database is a way of safely storing whatever settings the user wants to store on the printer in a structured way without too much risk of messing things up by e.g. deleting a single character in a text file.

Lastly: Moonraker/mainsail as better place. This would take away the possibility of doing adjustments at runtime, assuming that we are talking some sort of pre-processing.

BTW, thanks for pointing to the PA calibration topic. Cool stuff.

Cheers
Florian

[mykepredko]

I’ve been following this conversation with interest and I just wanted to add a couple of comments.

Going back to the start of the original thread by @garethky , I’ve never seen any indication that many people swap out their nozzles for different sizes on a regular basis and that it really is an annoyance and a place where errors get inserted into the process. When it gets right down to it; if the printer can’t (electronically) read the nozzle parameters then there’s going to be human input which means there will be opportunities for error. Maybe this is a source of frustration for people with many hours/thousands of dollars of wasted printer time, but I haven’t seen any indication that this is the case.

@Florian turned the discussion to having a filament parameters database that the printer could access to have the (user defined) best operating configuration for the filament. It’s a good idea, but I don’t think it’s appropriate to have the printer access it - this seems to be more appropriately accessed by the slicer.

In my mind, the ideal would be a community maintained database for different filaments. When I say “community”, it would be users that determined the best printing parameters for specific filaments and would allow a user to share their parameters to the database and let others vote on whether or not these values should be included in the parameters provided to the slicer. Again, we’re talking “ideal” which means that the uploaded user values would be averaged into the existing values to get the best possible printing parameters.

The problem with this idea is that there aren’t any “standard printers” out there that could take these ideal values. There are huge variations in the operating conditions of the printers due to poor set up, sensor variation, ambient operating environment (including whether or not there is an enclosure and whether or not its heated) and so on. So the question becomes are there multiple database entries for specific printers and operating environments - not an insurmountable problem but adds to the complexity and work required to make sure the uploaded parameters are applied in the appropriate situation.

The big question that jumps out at my here is, how important would this database be for the average user? I’m not sure the vast majority of users work with any kind of variety of filaments - in my experience, just as @Sineos indicated, I have seen a lot of variation between brands of filaments (ie PLA from one company doesn’t print the same way as PLA from another) with little to no variation between lots within the same manufacturer’s product.

From what I can see, the vast majority of users use the same brand of filament and spend some time getting it dialed in to get good quality prints and stick with that because its work and they don’t have a good process for optimizing print parameters for a filament. This database would be of great use to them starting out, but once when they have something that works, its value becomes marginal.

Personally, I’m somewhat adventurous when it comes to filaments as I will get different manufacturer’s products that I read about to try out. Currently, I’m trying out Igus I151/I180 filaments because of their self lubricating properties and I would have loved some more precise printing parameters that somebody else had done the work on instead of the days I’ve spent dialing it in.

https://www.igus.com/product/700?artNr=I180-PF-0175-0750

As a generic comment: DON’T ADD ANY MACROS TO THE SYSTEM. Too many people see a macro that they think need and add them blindly, only to discover they cause problems with the printer’s operation. Macros are one of the greatest features of Klipper and one of its greatest problems (especially for new users).

The support discussion is something of a red herring; if the functionality is well thought out and it is used by people, it will be maintained going forwards. The pull request process seems to work very well when it comes to Klipper and if it’s used then somebody will be making sure it works.

It seems to me that the ideas put forward in this thread are individuals wish list items. If there’s a conclusion that I can make here on what’s needed it is some kind of process for gauging users pain and coming up with a prioritized list of issues.

[garethky]

@mykepredko

I’ve never seen any indication that many people swap out their nozzles for different sizes on a regular basis and that it really is an annoyance and a place where errors get inserted into the process.

This feels dismissive, but I think I understand where you are coming from. I didn’t swap nozzles until I got a Mosquito and then a Revo hot end. That changed my view on the whole topic. So this is due to new/better hardware that makes this easy. Not everyone has hardware like that yet.

What I found myself doing was swapping nozzles, running into the extrusion limits, then going into the config and maxing out the nozzle size so I didn’t hit that wall again. This disables a safety feature but otherwise works “perfectly”. So my sense is that people who swap nozzles don’t update their config when they do, but they should. This is now more work than the nozzle swap itself.

Further the extruder doesn’t expose the nozzle diameter to allow macros to use that value. I’m now using that value in my PA tuning macro.

Anything that causes a user to have to edit the printer’s config during the normal operation of their printer seems like a source of error and a nuisance.

I treat my klipper printer like an appliance. If it’s not at least as easy to use as other printers I own I see that as an opportunity for improvement.

[Sineos]

I also agree that nozzle swapping has its merits, although I have to admit that I seldom do so.
I also just set the nozzle diameter to 0.6 and left it there ever since but I have to say that I find changing the nozzle by far more annoying than I would changing my config.
Maybe due to the fact that I always apply some boronitrite paste on the nozzle’s thread. This means removing the old nozzle. Cleaning the residues, applying new paste to the thread and reassembling. Something I find highly annoying.

[mykepredko]

Apologies if I came across as dismissive -that wasn’t my intent.

@garethky

What I found myself doing was swapping nozzles, running into the extrusion limits, then going into the config and maxing out the nozzle size so I didn’t hit that wall again. This disables a safety feature but otherwise works “perfectly”. So my sense is that people who swap nozzles don’t update their config when they do, but they should. This is now more work than the nozzle swap itself.

Can I ask why you’re changing nozzle sizes? I’m curious as I’ve seen the comment from other people who have gotten Revos and I’m not sure what happens when you have that ability. Over the years I’ve experimented with different nozzle sizes but I’ve never gone away thinking “Damn, I wish this was easier”. There are times when a larger than standard (0.4mm) nozzle would speed up models and sometimes I want smaller X/Y features but as I have multiple printers (which many people do and it sounds like you do as well) if it was a recurring requirement, I would probably convert one to the nonstandard nozzle size and work that way.

I’m also not sure how you escape the slicer issues - in Cura the nozzle diameter is part of the slicer’s printer configuration, so this has to be part of the equation as well.

I honestly think you’re looking for a complete solution that integrates the printer with its firmware with the slicer; when you install a new nozzle, a new gcode file is generated for that nozzle. Anything less than this you’re going to be tweaking something.

Anything that causes a user to have to edit the printer’s config during the normal operation of their printer seems like a source of error and a nuisance.

This is something I don’t know if agree with - by changing the nozzle size you are changing a fundamental part of the printer’s config.

I treat my klipper printer like an appliance. If it’s not at least as easy to use as other printers I own I see that as an opportunity for improvement.

I absolutely agree with this sentiment and I understand where you’re coming from regarding this discussion. As I said above, I’ve been following this thread with interest.