Hello *,
filament flow will be reduced at higher speeds. This is a problem no firmware or software is Addressing at all.
See this video for a nice filament flow measurement at different speeds and hot ends/heat breaks (e.g. min 10:50):
Smart filament sensors exists, they are not affected of this issue and always measures the true amount of extruded filament.
It should be an easy task to make use of it for calibrate the rotation distance, even at different speeds.
Hard to implement, but an impressive nice and total unique feature would be if the sensor could be used for compensate the flow while printing.
Respecting details like:
higher flow rate at the start of a fast extrusion (material already have target temperature)
constant distance measurement with low resolution (e.g. btt filament smart sens with 7 mm)
retraction will also trigger the sensor
changing from extrude to retract will have ~1 mm extra way even if the sensor is installed tightly (sensor mechanics slacks around)
maybe even inform the user and/or lower the speed if problems are detected (lost steps…)
For reduce complexity there could maybe be created some stats with test prints that are stored in profiles and tuned while printing.
I sadly have no time for developing another project. But I would help with testing if wished.
A working automatic flow rate compensation would/should just be a dream of everybody working with 3D-Print
I think you on a good way real-time compensation and usage of sensors input are needed for getting much better prints and are the future.
Hi again,
I think that I am able to build a high precision, high resolution, low resistance, lightweight, low latency motion sensor.
This unit could report the real filament motion/flow over an SPI interface as delta when requested using a DSP.
This could solve nearly every flow problem and makes a Bowden setup near as efficient as a setup with direct drive. Without the disadvantages as the weight.
If somebody is able to implement a some compensation systems into Klipper. I would build a such sensor and send it to the developer. After we are done I would supply such sensors to everybody. Either as open source project or as sold unit or both.
If somebody also loves this idea and is able to implement a such extruder compensation system into klipper, we can start talking what the potential is and how to integrate efficient. Starting implementation should wait until I have completed and send the sensor. I will need minimum a month because the supplier for some special parts are very slow.
Even if this picture is not beautiful it should show what the system will look like if completed.
The potential is:
Perfect flow rate!!!
Less complexity for the user (Only sensor calibration is required, maybe they are such precisely that no additional calibration is need. But this needs to be tested)
Autodetect rotation distance (Or the other way around, set rotation distance and autodetect sensor distance)
I like the idea, maybe somewhat overkill
In the Klipper domain, there exist the filament width sensor class, which compensates the flow (not the rotation distance!) by reading analog values from different sensors.
The filament motion sensor class (which I am using now, after accepting that the filament width sensor did more harm than good) is currently only used for a virtual filament detection, as the resolution is limited to one “tick” per 5 or 7mm.
Technically, a closed-loop control will not be easy, though, as the stepper moves (including these of the extruder) are calculated some 100-1000 ms in advance.
The best compensation would lag behind, so I don’t think this would help unless the complicated stepcompress-system would be rewritten, leading to other and bigger problems.
I’ll leave to others to prognosing the benefit of a mean-under/overextrusion compensation. But in fast accelerating/decelerating moves, I think this will also do more damage than good.
That being said, one could use this sensor for a calibration routine, for a certain filament at a certain temperature with the certain Hotend, compensating in advance.
This is nice to know! I think changing the rotation distance is not really important. So this is great!
I did some research and I think I am able to build a sensor with 0.01 mm resolution and up to 7K update Rate. But if not necessary needed it will not supply movement deltas as PWM but instead over a serial interface. But “only” 99-99.9% precision (depending on calibration), but it should be good enough as the existing differences are much higher.
A full closed loop control is an option but not necessarily needed, as the needed flow compensation will be somewhat equal in similarly situations. The compensation could be part of the klippers precalculations, starting with only reading the sensor, learning and then compensate.
Having such calibration routines would be a good point to start.
As the “filament width sensor class, which compensates the flow” exists, I will start building the sensor. Can you maybe supply more information about this?
If this is the point to start I would place the sensor before the extruder in first iteration, with addional options in mind.
I would doubt that, if you don’t take the Hotends Velocity into consideration. E.g., The infill section will be very fast, so the overall flow rate would increase. But as soon as the Wall Perimeters (which probably will be slower) start, you will have an over-compensation until the script “learns” the new flow rate.
This simple way is implemented in this filament_width_sensor module.
A speed-dependent flow rate multiplicator would be needed, which is possible but somewhat more complicated as you need the predicted speeds that are constructed in the stepcompress system (the iterative solver for accelerations etc). But I think you could get inspired by the pressure advance functionality, that uses similar information (especially the acceleration to compensate for changes in filament hotend pressure).
This would happen if we would use 1 variable that compensates the flow rate.
But I think a function operating on sets would be able to solve this much more precisely.
E.g:
a = motor acceleration
b = motor speed
c = measured acceleration
d = measured speed
e = target speed
f = target acceleration
g = motor acceleration delta
the source set A is defined as followed:
A = a X b X c X d X e X f
the target set B is defined as followed
B = g
So the function fx will look like this:
fx: A -> B
The result would reflect a delta motor acceleration what could be used to calculate a new pwm frequency for the motor control.
Let fx interpolate clever so we can reduce the size of the source set:
|a| = |b| = |c| = |d| = |e| = |f| = 4
|A| = 4^6 = 4096
while we still have:
|B| = |R|
I think not all of these inputs would be needed, but possibly other that I did not mention here and of course machine limit needs to be respected, and the example has lot of problems related to math and physical problems.
E.g. the inputs b and d could maybe be combined into h = “resistance”…
But I don’t care much about it now and this example is only to show out my point and lead to more generally discussions and the details should be handled by persons with better knowledge than me.
But for pointing out a possible strategy:
All in all profiles with 4096 elements (~16 KB of Data) can easily be handled by the host and a single of them can also be transferred to microprocessor and hold in RAM. The interpolation is an easy task and the microprocessor could easily look up and calculate the needed compensation in real-time. The microprocessor could continually stream the data pairs (measured values, motor values) to the host and the host could update the table and synchronize changes back to the microprocessor if needed.
Profiles could differ over temperature and material.
I use also that sensor: klipper/hall_filament_width_sensor.py at master · Klipper3d/klipper · GitHub
I just want to use it as a “too big” diameter detector. There were no way to disabled the compensation and keep the diameter measurement for out of spec parts then I implemeted it.
So at the beginning I had compensation enabled. The main issue I see is measuring only one caliper diameter. If the filament is even a bit oval, the deduction on the section is quite false (the error is squared). You may be accurate on the measurement but that is not enough. There were no improvement as the it compensate too much or too little and noticable degradation. That is my deduction but I didn’t investigate much in that way.
