Speed-dependent extrusion: can it be accounted for?

[dewi-ny-je]

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?

[klipper-gitissuebot]

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.

[alfrix]

More info:
https://reprap.org/wiki/G-code#M592:_Configure_nonlinear_extrusion
https://forum.duet3d.com/topic/5588/non-linear-extrusion
First implementation of this:
Duet3D/RepRapFirmware@1ecf339

[GarthSnyder]

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.

[dewi-ny-je]

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.

[KevinOConnor]

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

-Kevin

[KevinOConnor]

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

[dewi-ny-je]

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?

[yschroeder]

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

[n8bot]

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.

[dewi-ny-je]

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.

[n8bot]

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?

[dewi-ny-je]

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.

[D4SK]

200$ and I implement it :)

[yschroeder]

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? 😁).

[dewi-ny-je]

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.

[dewi-ny-je]

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

[dewi-ny-je]

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.

[n8bot]

I’m 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’s the case, would asking the gear to spin faster provide more grip?

I’ll 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’s barely been used. Most users have no clue how to tune it. Just FYI.

[KevinOConnor]

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

[dewi-ny-je]

Additional information for whoever willing to tackle the issue: in MarlinFirmware/Marlin#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/

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.

[n8bot]

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.

[dewi-ny-je]

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.

[n8bot]

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:

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.

[dewi-ny-je]

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.

[yschroeder]

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...

[dewi-ny-je]

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.

[dewi-ny-je]

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).

[yschroeder]

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.

[dewi-ny-je]

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.

[yschroeder]

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.

[dewi-ny-je]

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

[yschroeder]

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?

[dewi-ny-je]

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).

[yschroeder]

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).

[dewi-ny-je]

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 :)

[dewi-ny-je]

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

[yschroeder]

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 :-)

[dewi-ny-je]

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.

[yschroeder]

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.

[yschroeder]

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.

[dewi-ny-je]

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).

[yschroeder]

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

[dewi-ny-je]

@yschroeder I could be testing your design if possible, the sensor is on its way and my printer has most other issues fixed.

My plan is to hook up the sensor and the step/dir signals of the extruder motor to an external Arduino and to log, periodically, the offset between the two.

[dewi-ny-je]

Two more videos proving the issue with non-linear speed is real and common, and therefore a continuous correction of the extrusion multiplier (up to a certain max value) would benefit most printers.

Bi-metallic heat break testing on Ender 3
https://youtu.be/xAiUZ7HDhdM

Hemera testing
https://youtu.be/RCPDzT3mS4U

[yschroeder]

I did not have much time lately to work on this. I will put the step files here later.

[dewi-ny-je]

@yschroeder is there some aspect which you think it's still sub optimal? Maybe I can see if I can do something.
I checked the online model few days ago and I saw you placed two bearings to ensure straightness of the bolt. It seems a good design overall already.

[gluap]

I have been following this thread for a while. I have made experiments with compensating the dynamic underextrusion and wrote a python script to adapt feeds in g-code based on manually measured underextrusion at different feed rates. I had good results doing test prints, but as a g-code filter the code will not be useful for actual printing beyond tests (because really, the extrusion speed is only definitely known in the motion planner of the firmware). You can find the results here https://github.com/gluap/gcode_cflow .

I hope that a closed loop extruder is not required and experimetally determining a curve of the feedrate dependent underextrusion for ones printer and filament/temperature combination is enough to compensate for the effect (after all it works for pressure advance and resonance compensation already).

Before processing g-code I tried to find out where to implement it in klipper but was never entirely sure where to put this. I would have another go if someone gives me a hint where to implement this.

(Ok, maybe this could be done purely on the g-code side -- if the slicer controls all accelerations and stays within the limits of the firmware it seems plausible. But I'd still rather have it in the firmware)

[yschroeder]

@dewi-ny-je Sorry for the extremely late response!

I was busy with a lot stuff lately and have no time to push this project any futher at the moment.

I attached a STEP file of my design. Feel free to try/modify it, and please post your results here.

Filament Sensor v10.zip

[gluap]

edit: Question was answered by @alfrix link to his the pull request below.

@KevinOConnor could you give a hint where one could go about implementing this? I tried modifying extruder_calc_position in kin_extruder.c to multiply the increment by a velocity-dependent factor but this crashes klippy due to internal error in stepcompress (easy to reproduce by adding a constant multiplier for instance by multiplying the return values here and here by 1.02 each) . My guess is that the iterative solver upstream assumes that the predetermined start and end positions of the moves will be met.

But I haven't found another good location to intuitively add a velocity dependent extrusion factor.

[alfrix]

#4231