Klipper: Speed-dependent extrusion: can it be accounted for?

Created on 9 Mar 2020  路  61Comments  路  Source: KevinOConnor/klipper

In the past I noticed how printing at 8 mm鲁/s with my hot end caused thinner extrusion width than expected along long straight walls or infill. Now I find this video demonstrating scientifically the phenomenon.
https://youtu.be/0xRtypDjNvI

I have two questions:
1) can it be compensated in Klipper with a speed-dependent extrusion multiplier? As seen in the video, the calibration would be quite simple!
Also, the faster we print, the bigger the difference between high speed segments and low speed segments is, and the bigger the difference in the effective extrusion. A speed-dependent extrusion multiplier would improve quality by a significant amount.
2) since the pressure advance is calibrated using a tower which, as suggested, should be printed at relatively high speed, would the lack of correction affect the accuracy of the pressure advance calibration as well? Or in opposite way, would such a compensation improve the uniformity of the pressure advance compensation at different speeds?

inactive

All 61 comments

Hi @dewi-ny-je,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

I've wondered about this issue as well. It's not a minor difference, either - I've notice that the actual length of 100mm calibration extrusions varies by as much as 40mm depending on the extrusion speed.

Well the gear gripping the filament always has some degree of slipping. The more the counter pressure, the higher the slip.

While 40% seems a lot to me (maybe the filament is not squeezed tight enough by the driving gear and counter-bearing), correcting for this progressive slip would be welcome. It should be probably linked to the pressure in the nozzle already known to Klipper.

It would require an interested developer to implement this. It should only require Python host changes (not micro-controller code changes).

-Kevin

I'm going to close this as it looks like the original question was answered (it's possible but would require an interested developer to implement it).

-Kevin

But if it's closed, how will a developer see it? Isn't it better to leave it open for some months for better visibility?

I just learned that RepRapFirmware implemented this:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M592_Configure_nonlinear_extrusion

I just learned that RepRapFirmware implemented this:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M592_Configure_nonlinear_extrusion

I should note that this was implemented as an experimental feature to satisfy the curiosity of a particular user, and AFAIK, very few users actually use it. Instead, most people rely on Pressure Advance.

The two things are completely independent. Pressure advance compensates the delay that takes place when the extrusion speed is increased, because the filament compresses, the melting chamber expands a little, and so on.
Pressure advance is exactly useless when the extrusion is constant. That's why the pressure advance calibration is performed with sharp increase/decrease of extrusion speed, more specifically in corners.

This extrusion compensation instead corrects the fact that the gear teeth tend to slip more the faster you extrude.
It is effective also when the extrusion is constant, that's why the calibration is performed by extruding at constant speed!

Pressure advance improves basically corners and sharp changes of extrusion.
Slippage compensation allows any extruder to be useful in a wider range of speed.

Sure. But using observation of a printed part can lead to false conclusions regarding cause and effect.

Is the underextrusion a result of the top speed, or the acceleration that just took place?

IMO, the more obvious cases of underextrusion (and overextrusion) can be alleviated using PA. Any nonlinearity after that is basically not noticeable. Is it?

I checked the source code and I think I understand where it should be changed, but I have no idea how to do it.

Has any of the more experienced developers reading this thread an idea about the time needed for someone who knows python to implement this speed-dependent extrusion multiplier?
How many hours? I'm willing to sponsor it and if maybe some other users chip in, we could teach an amount which is surely insufficient based on the time required, but at least enough to show our interest and not only by asking for features.

200$ and I implement it :)

This needs to be implemented with the advice of @KevinOConnor, he surely has an idea where in the code he'd like to have it. The implementation could adhere to what is implemented in ReprapFirmware, it would be translating C to Python.

Without looking, there has to be a place in the code where Klipper computes the steps of the extruder for a move based on the step_distance config parameter. Here it would not just use the constant value from that config variable, but compute the value from a function. Then, there needs to be a GCode that sets that function (may I suggest M592? 馃榿).

Sure. But using observation of a printed part can lead to false conclusions regarding cause and effect.

Is the underextrusion a result of the top speed, or the acceleration that just took place?

IMO, the more obvious cases of underextrusion (and overextrusion) can be alleviated using PA. Any nonlinearity after that is basically not noticeable. Is it?

I noticed that in infill, printed at higher speed, there can be underextrusion, even if it's over long stretches where the PA cannot affect the results.
If you check th video I posted, it's shown how much it could affect extrusion.

This needs to be implemented with the advice of @KevinOConnor, he surely has an idea where in the code he'd like to have it. The implementation could adhere to what is implemented in ReprapFirmware, it would be translating C to Python.

Without looking, there has to be a place in the code where Klipper computes the steps of the extruder for a move based on the step_distance config parameter. Here it would not just use the constant value from that config variable, but compute the value from a function. Then, there needs to be a GCode that sets that function (may I suggest M592? ).

I'm on mobile now so I can't go around to find the spot, but my guess was actually the file of C code which does the iterative solving. That's where PA is also calculated, if I remember correctly

200$ and I implement it :)

That was also my guess, that's why we need another two-three people to chip in.
I can pay half of that, my absolute max.

I鈥檓 not used to seeing under extrusion based on speed alone. That type of issue would point to a mechanical issue: the drive gear is slipping. If that鈥檚 the case, would asking the gear to spin faster provide more grip?

I鈥檒l leave the discussion to more interested individuals. I just wanted to point out, because I think I was the source of this new point of discussion, that the functionality in RRF has not been conclusively proven useful. It鈥檚 barely been used. Most users have no clue how to tune it. Just FYI.

Alas, I don't have much advice to offer here, as it isn't something I've looking at. Part of the work that "an interested developer" would need to do is to propose an approach, try it out, document the results, etc.

FWIW, the developer documentation does have a section on how moves are processed - see: https://www.klipper3d.org/Code_Overview.html#code-flow-of-a-move-command . The key function for the extruder is in klippy/kinematics/extruder.py:move(), which takes the requested extrusion (its start position, start time, velocity, acceleration, etc.) and populates the extruder specific "trapezoidal motion queue".

-Kevin

Additional information for whoever willing to tackle the issue: in https://github.com/MarlinFirmware/Marlin/issues/9852 it is suggested to link the extrusion multiplication factor not to the instant extruder speed but to the back pressure calculated as part of the pressure advance algorithm. The way to calibrate doesn't change, it's still extrusion at multiple constant speed.

For the skeptics about the occurrence of the issue: in the same link it is said that everyone actually testing the issue confirmed it, so it's not theoretical...
Also this page show enlarged photo of the filament, providing an insight about the causes of the phenomenon.
http://www.extrudable.me/2013/04/18/exploring-extrusion-variability-and-limits/
TeethMarks
Basically the plastic itself deforms. It's not due to a bad extruder.

As said, I am willing to sponsor to some degree the development, but by myself it won't be enough.
I can also help with the math, maybe.

That photo points exactly to a problematic extruder. You should inspect filament from a modern, proven extruder like with bondtech dual drive gears. That article is from 2013 -- in the heart of the "DIY hobbed bolt" era.

Aren't variations on the idea of hobbed bolts still the main extruder type found on printers?
Also, on the marlin issue page they clearly state that the issue is still common in 2018.
And again, CNC kitchen (link at the beginning) used a dual gear, original Bondtech to confirm the issue still in 2020.
You may say it's a minor issue which does not happen when the extruder is not pushed to the limits, but it's definitely not due to problematic extruders.
I guess that you would experience the issue with your extruder too :)
Try extruding 50 mm filament at 2 mm鲁/s, 6 mm鲁/s and 12 mm鲁/s (whatever that means in linear filament speed for your printer). If you have a 0.4 mm nozzle, you'll see around 5% reduced extrusion.

Let's put aside the reason for the lost motion (inadequate extruder).

How would speeding up the extrusion alleviate this issue? When your tires are spinning, or your clutch is slipping, or your automatic transmission is slipping, stomping on the gas doesn't exactly _help_ the situation.

This graph from the CNC Kitchen article says a lot:
extrusion215_underextrusion

Yes, he was able to observe a loss of extrusion at high flow rates. Let's do some quick math, though.

What is a typical print setting? 0.2 mm layer height, 0.4 mm extrusion width, 100 mm/s print speed? That equates to 8 mm^3/s.

If we see on that graph, at that extrusion speed, there is less than a 5% error. A 5% error just happens to be the step-accuracy of most stepper motors. [Edit: Though, stepper accuracy is non-cumulative, so 5% total is still more than expected] So, exactly almost in line with expected behaviour.

Beyond that? Well, certainly the under extrusion gets worse. Stepper motors can quietly lose position, especially if they are not being run near full current to begin with. The extruder stepper might have been skipping many steps, the filament could have been grinding away, many other possibilities exist which were not explicitly ruled out in the tests done by CNC kitchen.

The reason I seem so against changes like this is because they are unproven and clutter up not only a codebase, but the idea-sphere surrounding the methods of 3D printing. If you can show me evidence that increasing extrusion speed non-linearly improves _any_ situation, I'll gladly change my mind.

I'm a scientist by day and I understand your concerns about this. Can you think of an experimental setup to investigate this further? How can we prove the reason of the underextrusion?

I鈥檓 not a scientist, so I would ask your advice for this. My first thought is that someone who experiences this issue should try the free-air extrusion test with no nozzle and no heating of the filament at all. First we must establish if the extruder in question can accurately reproduce the same motion at different speeds in any condition.

I have an idea for an experimental setup to check if the filament deforms when grabbed by the extruder:

Use a Bondtech extruder in a bowden setup. Put a 3d printed part into its flange for the v6 hotend. That part has a window to observe the filament before it enters the bowden tube. Put a microscope camera (the new HQ pi cam with a microscope lens from pimeroni) in front of the window. Light the filament from the side with a small LED to cast shadows on dents in the filament. Bonus points for adding a ruler next to the filament for reference.

If the filament deforms, the dents should be spaced differently with higher extruder pressure.

Sorry somehow I'm not getting notification emails anymore.

I have a 1:1 macro lens for my DSLR so I could easily check down to few microns, but my printer is offline. I'd be happy to measure your samples, but sending by mail is not the easiest, especially if you are outside Europe.

"Only 5%" you say: we calibrate E steps accurately within 1% but CNC Kitchen gets more than that due to slipping already at 6 mm鲁/s! And he's using a Bondtech that is a top extruder.

Regarding the question "what's the point of pushing more if there's already slipping": you can see that in CNC's graph the extrusion error increases linearly between 3 and 12 mm鲁/s, then it explodes.
At 12 mm鲁/s he gets 5% error, right? That means that he's extruding in fact 120.95=11.4 mm鲁/s before slipping is out of control: until that value slipping increases *less than extrusion rate so it's controllable, from that point they increase together so no compensation is possible anymore.
In other words, whenever you want to extrude less than 11.4 mm鲁/s, you can obtain the desired extrusion by compensating the step rate.
So yes it's useful ;)

[...} he's using a Bondtech that is a top extruder.

The drive system is not the only factor. Nozzle, heater, methodology: these are all important factors. CNC kitchen does not address whether the filament was grinding, slipping, etc,. Tension needs to be set properly on any extruder, even if it uses "the best" components. Until I changed my custom bondtech setup to a fixed-distance idler, with no spring whatsoever, I was getting slipping of the filament on occasion.

Regarding the question "what's the point of pushing more if there's already slipping": you can see that in CNC's graph the extrusion error increases linearly between 3 and 12 mm鲁/s, then it explodes.
At 12 mm鲁/s he gets 5% error, right? That means that he's extruding in fact 12*0.95=11.4 mm鲁/s before slipping is out of control: until that value slipping increases _less_ than extrusion rate so it's controllable, from that point they increase together so no compensation is possible anymore.
In other words, whenever you want to extrude less than 11.4 mm鲁/s, you can obtain the desired extrusion by compensating the step rate.
So yes it's useful ;)

Experimentation is the only way to determine if it is useful or not. The facility is already available in RRF. It should be easy to test out.

If you or @yschroeder need any help with CAD for these tests, I'd be more than happy to help.

Experimentation is the only way to determine if it is useful or not. The facility is already available in RRF. It should be easy to test out.

What is RRF?

Sorry, it means RepRapFirmware.

https://github.com/KevinOConnor/klipper/issues/2610#issuecomment-653906245 :

I just learned that RepRapFirmware implemented this:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M592_Configure_nonlinear_extrusion

Another option would be to design a filament speed sensor and to adjust the flow % based on its output. This would at the same time provide immediate E steps calibration and speed-dependent adjustment.

If there is interest in the implementation I could design the part.
In fact, the principle is the same of the diameter sensor, but it would need to be read continuously and bit once a second,band it would need to be applied immediately and not with a delay equivalent to the length of the Bowden tube.

Which I just realized it's basically impossible with good enough resolution.

What if a set of digital calipers (micrometers), or a dial indicator, were modified to be attached to a ~1.75 mm rod that could be fed through the extruder? Then we could measure precisely how much feeding has taken place for a given move, up to the max travel of the measurement device.

The mass and the force needed to pull the caliper may increase drag and slippage.

This is true. However, filament spools on spool holders provide quite a bit of resistance already. It seems to be about a fair comparison. Perhaps that itself is the root of the problem.

It may be actually faster to implement the correction in klipper or to install the Repetier firmware and see how it behaves.

The drive system is not the only factor. Nozzle, heater, methodology: these are all important factors. CNC kitchen does not address whether the filament was grinding, slipping, etc,.

Grinding is the step following slipping.
Anyway, he kept all the parameters identical except speed. It still seems to me that the correction can bring back the actual extrusion to the expected value.

The user-reports I have read about the feature in RRF (not repetier, FYI), seem to indicate that the underextrusion is still present after enabling the feature, and overextrusion was simply introduced as well at slower speeds.

Search the Duet forums for 'M592' to see more discussion.

There is one user who seems to be doing recent tests with it. I would get in contact with them and see if they can help.

I was reading the m592 thread on the Marlin repo and I found this post: https://github.com/MarlinFirmware/Marlin/issues/9852#issuecomment-463467359
Even a small multiplier factor based on speed would bring an improvement.

A simpler option may be the implementation of the Duet filament sensor (connected to the R-Pi directly) to get a direct measurement of filament feed, to implement a sort of closed loop filament advancement (taken into account the delays and the lower resolution of the sensor).
https://duet3d.dozuki.com/Wiki/Duet3dFilamentMonitor_LaserVersion
Maybe a separate ticket could be opened to make everyone able to code aware of this idea.

That filament sensor looks very similar to the one Prusa ditched from their printers with the last update. Some very glossy PETG filaments were not detected by their sensor. Do you know if the Duet sensor has the same problems? Maybe it works better (in both cases) when using the sensor after the extruder (when the filament got its dents from the gears).

I have an old Prusa sensor lying around. Does anyone know how to interface it?

I didn't notice that the link was to the (now deprecated, I think) laser version of their sensor. They have a rotating magnet sensor that, IIRC, is currently supported: https://duet3d.dozuki.com/Wiki/Duet3dFilamentMonitor_RotatingMagnetVersion

I would suggest to not implement the duet sensor as they use a somewhat crude timing based protocol to send the angle value to the main board.

There are cheap breakout boards with an AS5600 available. That sensor can be configured via I2C and read via an analog voltage, which is easily done by klipper.

The hardware design with the hobbed bolt seems valid though.

That filament sensor looks very similar to the one Prusa ditched from their printers with the last update. Some very glossy PETG filaments were not detected by their sensor. Do you know if the Duet sensor has the same problems? Maybe it works better (in both cases) when using the sensor after the extruder (when the filament got its dents from the gears).

I have an old Prusa sensor lying around. Does anyone know how to interface it?

Actually my idea was to place the sensor after the extruder, somehow, so that the marks due to the extruder make even the darkest or smoothest filament easy to detect.

Indeed the magnetic sensor is also interesting, however it has a resolution of 1024/rotation, which is we estimate roughly 3 mm radius, means 18 microns resolution.
That won't be enough for any accurate closed loop extrusion: the minimum (and therefore not reliable) data from the sensor would be equivalent to about half millimetre line (0.2 mm thickness, 0.45 mm line width). To get accurate enough data you need to average at least 10 of them.

I don't think closed loop extrusion is viable, as the changes to extrusion feedrate happen very fast.

I think for investigation of this topic such a magnetic sensor is more than sufficient. Also I have an idea for a CAD design...

I don't think closed loop extrusion is viable, as the changes to extrusion feedrate happen very fast.

I think for investigation of this topic such a magnetic sensor is more than sufficient. Also I have an idea for a CAD design...

Closed loop does not need to be realtime, it just means using feedback from a sensor to correct parameters.

What I meant is that the sensor could send a pulse every 3-10 microns depending on the sensor, and every 5 pulses Klipper could adjust the extrusion multiplier based on the expected Vs measured data. 100 microns filament through the extruder is equivalent to about 2 mm of extrusion on the bed. It's still fast enough to correct both for small and slow perimeters and for faster infill.

Is there a way to have Klipper output the current filament position to the serial terminal upon trigger of a pin on the MCU?
This way we could experiment with these sensors and ideas.
In fact, at that point we could even have an external script reading the filament position and sensor data to adjust the extrusion multiplier (which I may be able to do), before implementing it in Klipper (which is beyond my skills).

I made a design for a filament sensor:
https://a360.co/3h4Ul7A

It requires this type of AS5600 PCB with a 6mm magnet:
https://www.aliexpress.com/item/4001216030876.html

The bearings are 623ZZ to have a rather small diameter (higher resolution at the sensor). The footprint is that of a NEMA17 stepper, so it can be bolted to the frame of a printer with standard brackets. I am still waiting for the PCB to be delivered (ordered from Poland to Germany so it should arrive reasonably fast). Everything is put together with M3 bolts.

The idler is spring loaded with a 3d printed spring integrated into the design. I still have to figure which material thickness gives a good amount of pressure.

Nice design, some remarks:
Analog limits the resolution to 10 bits and reading time to the sampling time, while a digital sensor would be more straightforward. However you can use that sensor in PWM mode, it's also an option.
The pyramidal support you used for the sensor is very close to the filament path. Maybe make it taller and leave a hole for the filament in it?
Why not metallic spring mounted on a bridge? Springs are easily available and cut (each spring pen has one).
I don't understand where you get the hobbed bolt which should grip the filament. Without teeth PLA will definitely slip.

The support close to the filament will probably change. Maybe the design gets some bowden tube attachment points. I wanted to avoid springs as there are a lot of different ones available and it might be hard to source the correct one for the design. With the plastic spring there is no need to source the part. If that plastic spring does not work out, it will be changed to a metal one.

I think a hobbed bolt is not needed, as the torque that needs to be produced by the filament is rather small. The white part is also 3d printed and has a groove with 1,75mm diameter. the filament will touch it with a large surface. The idler should be able to produce enough pressure so that the filament reliably turns the magnet. Again, if it turns out that this does not work, we have to figure something out that possibly involves a (clone) BMG gear or similar.

I look forward testing it while at the same time logging the step/dir pulses sent to the driver.

Is it really needed to log step/dir? Could we get a simulated output from Klipper for a G-code file and correlate it with the measurements from the filament sensor afterwards?

Is it really needed to log step/dir? Could we get a simulated output from Klipper for a G-code file and correlate it with the measurements from the filament sensor afterwards?

Logging the step/dir does not require coding or patching Klipper. From my point of view is easier. Getting the output from Klipper directly would be surely a good option if you know how to do it.

Regarding plastic springs: I fear that if you use plastic as spring you end up in the range of stresses which cause creep over months of use, resulting in a decrease of the force applied.
Springs are easily available on AliExpress. While I like the idea of a built-in spring, the time it takes you to find the proper material/thickness/endurance is surely bigger than the time to have springs shipped from China with the medium-price delivery service (two-three weeks, less than 5 euro).

I assembled the plastic parts and found them being much too weak/flimsy.

But I have a new idea: I will design a part that looks like a NEMA17 stepper motor. You can then mount it to any extruder you have lying around (in my case the original extruder from my Ender 3). The filament will go through the additional extruder and turn the shaft of the filament sensor (M5 screw mimicking the shaft of a stepper motor).

I would design it to be mounted before the main extruder, to keep the Bowden short.
You are doing the work so I don't tell you what to do, also because except for the spring your design was already usable, but since you mentioned "any extruder lying around", what about using this MK8?
https://a.aliexpress.com/_BUqlJZ
I have one around, it has a toothed gear and an idler and costs only 2 euro. The only parts to add are a sensor and a make-up stepper motor which only acts as shaft for the toothed gear.
I think the provided toothed gear has very small radius too! Maybe smaller than what you were going to achieve with your design, so better resolution.
If it's about 6 mm radius, that translates to 10 microns resolution (12 bit sensor, as you linked, read by PWM timing).

Anyway are you in Europe? when you have one working, make a copy and I'll gladly do experiments too :)

http://reprap.org/wiki/Drive-gear to find a ready made one, as alternative to the already good idea of a V slot idler.

That MK8 should be perfectly fine. It is basically the same design as the Ender-3 one but metal instead of plastic. If you want to go for a very high resolution a BMG clone would be perfect. It has a 5:1 reduction when using it as an extruder which means that the sensor would turn 5 times as often when used the other way around. However, it might introduce some play due to the gears...

I live in Germany. I publish the files once I got it working (Thingiverse), then you can print your own :-)

The BMG uses the gear as reduction, you are saying to use them as multiplier.
The gear multiplier doesn't work because you increase significantly the drag and therefore at the end you worsen the resolution, not to mention inertia on retracts.

I'll print it then, after all my printer is now offline but I have no use for the sensor until the printer will be working again.

Yes the additional drag in the BMG might be problematic. But you never know until you try...

For testing the sensor I would suggest taking 1 meter of filament feed it half way through the sensor, then pull and push it really fast back and forth to simulate heavy retractions. Afterwards pull it all the way through. The readout should add up to exactly one meter in this case.

Before, you should push the meter of filament very slowly through the sensor for calibration.

I finished the design for the stepper-style filament sensor:
https://a360.co/3jlrhuv

The thread of the M5 screw if filed away on one side by hand.

Will you upload it to Thingiverse, including .f3d or .step files? I think that's from Inventor and Fusion 360 non-commercial cannot open or import Inventor files (anymore).

Yes, as I said: once I am happy with the design, I'll upload it to thingiverse.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

KevinOConnor picture KevinOConnor  路  6Comments

smokez89 picture smokez89  路  4Comments

speendo picture speendo  路  3Comments

aegelsky picture aegelsky  路  3Comments

krpepe picture krpepe  路  5Comments