-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed-dependent extrusion: can it be accounted for? #2610
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, PS: I'm just an automated script, not a human being. |
More info: |
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: |
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. This extrusion compensation instead corrects the fact that the gear teeth tend to slip more the faster you extrude. Pressure advance improves basically corners and sharp changes of extrusion. |
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? |
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 |
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. |
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 |
That was also my guess, that's why we need another two-three people to chip in. |
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. |
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 -Kevin |
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... As said, I am willing to sponsor to some degree the development, but by myself it won't be enough. |
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? |
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, 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. |
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. |
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? |
I made a design for a filament sensor: It requires this type of AS5600 PCB with a 6mm magnet: 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: |
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? |
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. |
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. 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. 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: 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. |
@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. |
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 Hemera testing |
I did not have much time lately to work on this. I will put the step files here later. |
@yschroeder is there some aspect which you think it's still sub optimal? Maybe I can see if I can do something. |
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) |
@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. |
edit: Question was answered by @alfrix link to @KevinOConnor could you give a hint where one could go about implementing this? I tried modifying But I haven't found another good location to intuitively add a velocity dependent extrusion factor. |
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:
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.
The text was updated successfully, but these errors were encountered: