Delta printer; Repetier; CuraEngine: holey inner structure
Posted by BigMan200
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 16, 2015 02:31PM |
Quote
BigMan200
However when I build my Delta-Printer (own design) I had one think in mind: speed. So I think, next I will increase all speed values together step-by-step. In the moment I am getting the breaks, will try to maintain this higher speed by increase the filament flow.
If you have a bowden extruder then try to maintain all speeds about the same. They can differ but not much.
The problem is the time delay and elasticity in the bowden. Higher speeds need more pressure but slicers do not factor this in. They tried to factor this in in the firmware (which I think is a wrong place to do it). The firmware feature name is advance. But it takes into account only the elasticity and not the time delay. The time delay may or may not be predictable due its cause being friction in bowden. And the time dealay compensation is hard to do only in firmware. The result is that the firmware "advance" feature does not work well.
What you got was not enough pressure in the infill areas since these were quicker. Even at the same speed you will get worse quality of infill than the quality of perimeters since rectangular infill is typically printed in one direction only for one layer. That means that one direction is printed only each second layer. That means there are gaps in the infill wall and therefore worse filament adhesion. At higher speeds this can lead to gaps. But this will start at speeds above 100 mm/s.
Good luck printing
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 18, 2015 06:26PM |
I've incorporated the formulas for pressure compensation we discussed above into my post processor.
This plot shows the pressure curve, and (sample) extra length needed for increased print volume/second, here showing the lower end of the scale. Note: The input and output values are arbitrary at this point. I'm still coding the internals, it isn't validated yet.
[edit] I noticed my caption on the bottom should read Cubic MM/second (Extrude Volume), not ...Change in Extrude Volume. Fixed.
Before I go too far, am I on the right track?
Thanks!
-Paul
Edited 1 time(s). Last edit at 11/18/2015 07:49PM by Paul Wanamaker.
This plot shows the pressure curve, and (sample) extra length needed for increased print volume/second, here showing the lower end of the scale. Note: The input and output values are arbitrary at this point. I'm still coding the internals, it isn't validated yet.
[edit] I noticed my caption on the bottom should read Cubic MM/second (Extrude Volume), not ...Change in Extrude Volume. Fixed.
Before I go too far, am I on the right track?
Thanks!
-Paul
Edited 1 time(s). Last edit at 11/18/2015 07:49PM by Paul Wanamaker.
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 18, 2015 09:18PM |
Yes the equation for flow speed is v² = k₁ * f. There should be more terms related to density and height difference but these should be negligible. The obstacles in the flow i.e. the previous layers below nozzle (I believe you call this back-pressure) should be considered since viscosity is quite high. But the flow will be laminar thanks to the high viscosity and low density of melted plastics. That means the "back-pressure" effects will be predictable (no random process here like it is there with the friction in bowden). The "back-pressure" should be covered by the k constant. The only problem is that the constant will be different for a bridge (empty space below nozzle) and a normal layer (solid plastics after a small air gap). This is one of the reasons why a good pressure management cannot be done efficiently in the firmware. The firmware does not know whether the current path segment is a bridge or not. It could reconstruct the info from the previous gcode but it would be cpu/memory expensive.
The hard part is how to compensate for the filament friction in the bowden. The problem with friction is that it is a random process. If you have a brick on a table and start to push it then it is not predictable at which force it will actually start to move. But this random process will have a mean and some variance. If the variance is small enough then we can just use the mean value and we will get good enough results.
How should be the bowden modelled? We should divide the bowden to segments. The division points will be the places where filament touches the bowden. These division places will represent the friction elements (a.k.a. the "brick"). These friction elements are connected by springs which represent the linear compression/expansion of filament/bowden based on the force.
So we have something like this:
The friction element is characterized by a random process. It should be possible to express it by two random variables:
* the first defines at which force the filament starts to move relative to the bowden: slipForce(f₁-f₂)
* the second one defines at which force the filament stops moving: slipStop(f₁-f₂)
f₁ - force on friction element from the previous spring
f₂ - force on friction element from the next spring
Force from the last spring is the same as the force at the hotend (i.e. the force from which the hotend pressure depends linearly).
Force on the first spring is from the extruder stepper. Although you do not really know the force (the stepper torque is ideally infinite) but you know that f = k₂ * x (i.e. if the stepper moves filament by x then you can compute the force).
The distribution of random variables slipForce and slipStop should be close to normal. The papers measuring these distributions exist but first few google hits wanted $25 from me - phe! - they can keep the information secret!
From this one can build the simulation to compute how the whole bowden extruder will behave. Or ... we can just ignore it and measure how the bowden behaves ourself. One way is measuring the extrusion width. You know how the hotend behaves (v²=k*p(x)).
* v is plastic flow at some time t (you can compute it from the extrusion width, layer height and head position at time t)
* k is a constant (careful, different for bridges and normal segments; it will depend also on the extrusion width though I hope not that much if the extrusion width is bigger than the nozzle diameter)
* p is a random variable which defines pressure at time t based on the filament advance (you seem to call this ELPu) at time t-dt (we would just assume that this random variable has very small variance, dt is constant, and it looks like p = K * x(t-dt)
* x(t-dt) is filament advance (ELPu) at time t-dt
The problem with this approach is that dependence of k on extrusion width can be significant. And I think it is very likely that dt depends on the difference between the forces at the beginning and the end of the bowden.
The best approach would be make an experiment to measure how the force propagates in the bowden based on filament advance (ELPu) and the time. On entry side, there would be a stepper with a filament pulley and a force sensor. On exit side, there would be a pulley with a brake (to generate substitute for the back pressure from the hotend), another force sensor (how big the pressure is) and an angle sensor on the exit pulley (how much the filament is advancing at the end).
Or you can just forget about all this complicated stuff and assume that the hotend pressure is a time-delayed function of filament advance at the extruder stepper and try to approximate it by e.g. splines or whatever else. And find all the coefficients experimentally by hopefully not so random search. Which is just what you seem to be doing
Is it the right track? I'm not sure since I do not know exactly how the bowden behaves. Trying long enough will get you there eventually. We would need somebody more skilled in bowden modelling (i.e. physics of friction). Clearly simple model without bowden friction does not work. Otherwise Repetier firmware would already have working pressure compensation. Well, the other option is that their implementation had bugs they incorrectly identified as the time delay problem instead of finding the bugs in the code.
The hard part is how to compensate for the filament friction in the bowden. The problem with friction is that it is a random process. If you have a brick on a table and start to push it then it is not predictable at which force it will actually start to move. But this random process will have a mean and some variance. If the variance is small enough then we can just use the mean value and we will get good enough results.
How should be the bowden modelled? We should divide the bowden to segments. The division points will be the places where filament touches the bowden. These division places will represent the friction elements (a.k.a. the "brick"). These friction elements are connected by springs which represent the linear compression/expansion of filament/bowden based on the force.
So we have something like this:
-/\/\/\/-##-/\/\/\/-##-/\/\/\/-##-/\/\/\/-##-/\/\/\/-##-/\/\/\/-Modelling the spring part is easy (Hooke's law): f = k₂ * x
The friction element is characterized by a random process. It should be possible to express it by two random variables:
* the first defines at which force the filament starts to move relative to the bowden: slipForce(f₁-f₂)
* the second one defines at which force the filament stops moving: slipStop(f₁-f₂)
f₁ - force on friction element from the previous spring
f₂ - force on friction element from the next spring
Force from the last spring is the same as the force at the hotend (i.e. the force from which the hotend pressure depends linearly).
Force on the first spring is from the extruder stepper. Although you do not really know the force (the stepper torque is ideally infinite) but you know that f = k₂ * x (i.e. if the stepper moves filament by x then you can compute the force).
The distribution of random variables slipForce and slipStop should be close to normal. The papers measuring these distributions exist but first few google hits wanted $25 from me - phe! - they can keep the information secret!
From this one can build the simulation to compute how the whole bowden extruder will behave. Or ... we can just ignore it and measure how the bowden behaves ourself. One way is measuring the extrusion width. You know how the hotend behaves (v²=k*p(x)).
* v is plastic flow at some time t (you can compute it from the extrusion width, layer height and head position at time t)
* k is a constant (careful, different for bridges and normal segments; it will depend also on the extrusion width though I hope not that much if the extrusion width is bigger than the nozzle diameter)
* p is a random variable which defines pressure at time t based on the filament advance (you seem to call this ELPu) at time t-dt (we would just assume that this random variable has very small variance, dt is constant, and it looks like p = K * x(t-dt)
* x(t-dt) is filament advance (ELPu) at time t-dt
The problem with this approach is that dependence of k on extrusion width can be significant. And I think it is very likely that dt depends on the difference between the forces at the beginning and the end of the bowden.
The best approach would be make an experiment to measure how the force propagates in the bowden based on filament advance (ELPu) and the time. On entry side, there would be a stepper with a filament pulley and a force sensor. On exit side, there would be a pulley with a brake (to generate substitute for the back pressure from the hotend), another force sensor (how big the pressure is) and an angle sensor on the exit pulley (how much the filament is advancing at the end).
Or you can just forget about all this complicated stuff and assume that the hotend pressure is a time-delayed function of filament advance at the extruder stepper and try to approximate it by e.g. splines or whatever else. And find all the coefficients experimentally by hopefully not so random search. Which is just what you seem to be doing
Is it the right track? I'm not sure since I do not know exactly how the bowden behaves. Trying long enough will get you there eventually. We would need somebody more skilled in bowden modelling (i.e. physics of friction). Clearly simple model without bowden friction does not work. Otherwise Repetier firmware would already have working pressure compensation. Well, the other option is that their implementation had bugs they incorrectly identified as the time delay problem instead of finding the bugs in the code.
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 19, 2015 12:32AM |
Hercek,
Thank you very much for your analysis. I will be coming back to this many times.
Here are some things that struck me today:
I will look at the K "constant". Bridging, sparse infill, and loose support may require more of an initial boost than say perimeters. That will require some specific tests.
One thing I am relying on is: after I get a loop started at the right pressure, that the slicer has commanded the correct volume for the remaining segments... I know that's not always the case, but that's out of my control.
Thank you for laying out the variables. Other problems accounting for friction will come from how very different every user's printer is. From the extruder to the liner in the hot-end, and the brand of filament, how curly it is, how stiff, how rough, did they lubricate filament, hot end cooling, length of bowden tube, curve of the tube, printing temp, volumetric capacity, etc. Another factor I've not seen mentioned is filament reheat time. I've found with my all metal hot-end that increasing retract length can cool the filament slightly in the cooler part, creating a slight delay in flow on unretract, seen as a starved beginning of the next segment. So even the individual user's retraction settings could be a factor. A perfect model may match no printer, certainly not mine
I think that because of the large number of machine specific unknowns, this must be calibrated by the user. My goal is to make it as simple to test as possible, with just a few understandable inputs based on what the user observes in a standard test.
This I intend to find out. Having the right basic equation for pressure vs flow is a big help, thank you. If friction is close to linear with pressure, then perhaps increasing ELPu might be enough?
The right equation for acceleration is still to be determined. The rate of pressurization relies on so many things, I only have a few data points so far, these show that a very large change in pressure takes longer.
My theory is that errors in the pressure equation will show up primarily as under or over extrusion based on the magnitude of pressure change. That's testable.
Errors in the acceleration curve will show up as various blobbing or starved beginnings of segments, also testable.
Testing intermediate points hopefully will show if the curves are right.
I saw a printer that automatically printed test samples for extrusion amount, that was very nice. I need to make a test generator for these tests.
Thanks again for taking the time to help me understand this better. I have this all coded now except for K, but I still need to check everything. I might be able to get back to work next week.
Regards,
-Paul
Thank you very much for your analysis. I will be coming back to this many times.
Here are some things that struck me today:
I agree. Very fortunately Slic3r has a Verbose Gcode output mode, so I can identify each kind of segment, with some limits - I may not know if infill is sparse or solid. If it starts at the right pressure I'm betting it will be fine tho.Quote
Hercek
..the "back-pressure" effects will be predictable (no random process here like it is there with the friction in bowden). The "back-pressure" should be covered by the k constant. The only problem is that the constant will be different for a bridge (empty space below nozzle) and a normal layer (solid plastics after a small air gap). This is one of the reasons why a good pressure management cannot be done efficiently in the firmware. The firmware does not know whether the current path segment is a bridge or not.
I will look at the K "constant". Bridging, sparse infill, and loose support may require more of an initial boost than say perimeters. That will require some specific tests.
One thing I am relying on is: after I get a loop started at the right pressure, that the slicer has commanded the correct volume for the remaining segments... I know that's not always the case, but that's out of my control.
Very difficult indeed.Quote
Hercek
The hard part is how to compensate for the filament friction in the bowden. The problem with friction is that it is a random process. If you have a brick on a table and start to push it then it is not predictable at which force it will actually start to move. But this random process will have a mean and some variance. If the variance is small enough then we can just use the mean value and we will get good enough results.
Thank you for laying out the variables. Other problems accounting for friction will come from how very different every user's printer is. From the extruder to the liner in the hot-end, and the brand of filament, how curly it is, how stiff, how rough, did they lubricate filament, hot end cooling, length of bowden tube, curve of the tube, printing temp, volumetric capacity, etc. Another factor I've not seen mentioned is filament reheat time. I've found with my all metal hot-end that increasing retract length can cool the filament slightly in the cooler part, creating a slight delay in flow on unretract, seen as a starved beginning of the next segment. So even the individual user's retraction settings could be a factor. A perfect model may match no printer, certainly not mine
I think that because of the large number of machine specific unknowns, this must be calibrated by the user. My goal is to make it as simple to test as possible, with just a few understandable inputs based on what the user observes in a standard test.
Quote
Hercek
Clearly simple model without bowden friction does not work. Otherwise Repetier firmware would already have working pressure compensation.
This I intend to find out. Having the right basic equation for pressure vs flow is a big help, thank you. If friction is close to linear with pressure, then perhaps increasing ELPu might be enough?The right equation for acceleration is still to be determined. The rate of pressurization relies on so many things, I only have a few data points so far, these show that a very large change in pressure takes longer.
My theory is that errors in the pressure equation will show up primarily as under or over extrusion based on the magnitude of pressure change. That's testable.
Errors in the acceleration curve will show up as various blobbing or starved beginnings of segments, also testable.
Testing intermediate points hopefully will show if the curves are right.
I saw a printer that automatically printed test samples for extrusion amount, that was very nice. I need to make a test generator for these tests.
Thanks again for taking the time to help me understand this better. I have this all coded now except for K, but I still need to check everything. I might be able to get back to work next week.
Regards,
-Paul
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 19, 2015 04:19PM |
OK!
Since it is very very easy to change the formula I will test it both ways
The key to this is a test generator I'll make that will generate gcode for N number of lines of whatever length, with X increase in volume or extrusion width per line. I'll have full control that way.
The more I think about it the more I am certain that a test generator suite should be standard operating procedure for calibrating.
It should generate gcode with a set of variations, and the user can more easily hone in on what's best:
- For best temperature
- For speeds
- For max extrusion volume/second
- For extrusion width
- For bridging
- For acceleration
- For dimensions
- For extrusion multiplier
- For infill overlap
It should be smart enough to warn if the selections are impractical.
There should be a sequence so that the most important things are calibrated first.
It should tell the user how the results should look, with examples.
It should then tell them what settings to use in their slicer.
Hmmm, interactive calibration.
Oh blast!!! One obsession at a time!!!
Thank you both for your input.
Edited 2 time(s). Last edit at 11/19/2015 04:46PM by Paul Wanamaker.
My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!
Since it is very very easy to change the formula I will test it both ways
The key to this is a test generator I'll make that will generate gcode for N number of lines of whatever length, with X increase in volume or extrusion width per line. I'll have full control that way.
The more I think about it the more I am certain that a test generator suite should be standard operating procedure for calibrating.
It should generate gcode with a set of variations, and the user can more easily hone in on what's best:
- For best temperature
- For speeds
- For max extrusion volume/second
- For extrusion width
- For bridging
- For acceleration
- For dimensions
- For extrusion multiplier
- For infill overlap
It should be smart enough to warn if the selections are impractical.
There should be a sequence so that the most important things are calibrated first.
It should tell the user how the results should look, with examples.
It should then tell them what settings to use in their slicer.
Hmmm, interactive calibration.
Oh blast!!! One obsession at a time!!!
Thank you both for your input.
Edited 2 time(s). Last edit at 11/19/2015 04:46PM by Paul Wanamaker.
My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!
|
Re: Delta printer; Repetier; CuraEngine: holey inner structure November 19, 2015 07:42PM |
Did Repetier remove its quadratic factor (EXT0_ADVANCE_K) from its advance algorithm?
Ok, I checked. They did not remove it yet. At least not from the configuration. But it is "normally disabled in newer versions" .. whatever that means
I played with both EXT0_ADVANCE_K and EXT0_ADVANCE_L quite a bit long time ago and it was not much useful. I disabled Repetier advance completely at the end. More harm than good for all the cases I was trying. But I'm still running more than a year old version. It works pretty good but I'm having all speeds (except the non-printing moves and bridges) the same and using high accelerations so that low speed extrusions are happening only for a very short time. And I have some hacks to slicer to handle special low speed transitions around bridges. The hacks do not work well but they are better than nothing.
I never tried or looked at Sailfish (which may be the firmware where advance was introduced originally).
Edit: In italics. Just clarifying what needs to be done to print well even with no pressure management.
Edited 1 time(s). Last edit at 11/19/2015 07:52PM by hercek.
Ok, I checked. They did not remove it yet. At least not from the configuration. But it is "normally disabled in newer versions" .. whatever that means
I played with both EXT0_ADVANCE_K and EXT0_ADVANCE_L quite a bit long time ago and it was not much useful. I disabled Repetier advance completely at the end. More harm than good for all the cases I was trying. But I'm still running more than a year old version. It works pretty good but I'm having all speeds (except the non-printing moves and bridges) the same and using high accelerations so that low speed extrusions are happening only for a very short time. And I have some hacks to slicer to handle special low speed transitions around bridges. The hacks do not work well but they are better than nothing.
I never tried or looked at Sailfish (which may be the firmware where advance was introduced originally).
Edit: In italics. Just clarifying what needs to be done to print well even with no pressure management.
Edited 1 time(s). Last edit at 11/19/2015 07:52PM by hercek.
Sorry, only registered users may post in this forum.