Why doesn't pressure advance use a more simple algorithm?
-
Why does pressure advance use a complex algorithm? Perhaps I am missing something, but wouldn't simply shifting the time of the movement of the E axis coordinated with the X/Y/Z axis achieve nearly the same effect, with minimal calculation and no extruder jerk?
Has it been attempted? Could a simple pressure advance algorithm with just a time-shift in the E axis be tuned to work as well as the more complex algorithms which seem to not be accurate enough to be perfect?
It seems to me that all the presumptions made about extrusion flow, in order to arrive at the pressure advance complex algorithm, could lead us to the simple algorithm. If we assume it takes a bit of time to start flow, why not just start it early? Why increase the acceleration of the E axis in a burst? And conversely, if we assume that the deceleration of the E axis has a lag, why increase the deceleration in a burst?
Why not just shift the E axis by some tiny adjustable amount?
If it's found to be needed, the amount could be slightly adjusted based on the given feedrate/acceleration settings. But, it wouldn't need to recalculate the amount of steps in the E axis, or different jerk or accel... it would just send the same step pulses at a different time.
*not actually a robot
-
@bot Interesting idea. I'd have thought that starting the extrusion slightly earlier than the carriage move, and finishing the extrusion slightly earlier than the carriage move, ought to achieve the same effect as starting and ending at the same time but messing with the acceleration/deceleration rates.
Delaying the extruder move should negate any need for any "look ahead" capability, so it seems to me to be an elegant solution that ought to be easy to implement. -
Wouldn't you run into all kinds of extrusion issues if you simply time shift the extrusion? You would need the shift to be based on , at minimum, the speed and acceleration of the next move because if you do a slow move you need a different time shift compared to a fast move. You can't possibly account for differences between direct extruder and remote extruder so you still need to tune for those factors (possibly for material type nozzle size and nozzle temperature).
I don't think going 'simple' is the way to go.BTW, I have had pressure advance settings that actually reversed feed at the end of a move ... something that a time shift is not able to deal with.
-
@bot
The idea is attractive, but I'd suggest it's only simple if you say it quick
At present, the movement of all axis are coordinated to all happen in the same time.
What you are suggesting would require the extruder movements to be extracted from each line, then injected into another (earlier) move.
The extruder movements are in steps/pulses rather than time.
I could be wrong , but I think the processing overhead would be enormous. -
@bot It would be great if it could be that simple but based on my own fairly detailed analysis as reported on in another post I don't think that the simple approach would be possible unfortunately.
Your question about extruder jerk being part of the PA algorithm is a good one. At present there is extruder jerk at the start and end of all PA events whether that is at a line start/end or at any junction where a print direction change takes place (such as at a corner). The positional axes however, only incorporate jerk at direction change junctions, so this results in an incorrect PA extrusion rate profile at line starts and ends.
For line starts/ends the PA algorithm should not incorporate extruder jerk at the beginning of the PA event (there does need to be extruder jerk at the end of the PA event).
In short, when keeping it simple, whether or not extrusion jerk is used at the start of the PA event should be matched to whether or not there is jerk on the positional axis.
There are some further considerations to this which I have written about in detail in another post but will not go into that here as that is a lengthy discussion.
(I am linking this for the benefit of those who are not aware of that post.)
PA asymmetry & speed sensitivity & easy way to calibrate for it
-
Thank you for all the thoughts.
@deckingman I think the E axis would have to be shifted to execute pulses BEFORE the X/Y/Z axes. Though, the amount of the time shift would likely be in ms, if not microseconds. Not sure. I literally have no clue this is just a crazy idea right now.
@jens55 yes, the more simple approach might be a total failure and lead to more problems than we have. Though, with conservative enough values, it shouldn't affect too much.
The acceleration and deceleration phases of print moves are sooo soo so so so so small/fast. They only last a tiny fraction of a second in most cases. So, the shift in extruder timing would be also tiny. I think we might be able to squeeze some improvement out of a simple time shift before we shift too much and get excess oozing before the moves.
@OwenD perhaps you are more familiar with the firmware workings than I am. I'm barely familiar. But, afaik, it would be fairly easy to un-synch the E from X/Y/Z axis. Even though the G-Code line contains all X/Y/Z/E info together, the printer parses the info and calculates its own thing. I know the firmware makes an attempt to ensure all steps are sent at the right time, but it's not exactly perfectly accurate. It can sometimes be too late, and step pulses are dropped, etc. (IIRC).
So, basically, altering the timing of the step pulses should be as easy as adding a tiny number to another number.
And, yes, it seems intuitively that the amount of timing advance of the E axis would need to be coordinated with the move's actual feedrate and acceleration settings. But, how many different feedrates do you use in your prints? Either we could tune a dead-simple algorithm with one set time to advance E, and tune it to be "about good enough" for all print feedrates. Or, we could do a simple arithmetic scaling of the shift factor. Like, by feedrate and acceleration. It's a heuristic, so it can be fudged.
My guess is that someone has tried this before, and it didn't work that well, hence why we have the algorithms we see today. However, it might be worth trying it it's not been done.
*not actually a robot
-
I have been informed by @Edgars-Batna that with RRF (at least RRF 2.0, which he has experience with) the code for E is very hard to decouple from X/Y/Z without re-writing a lot of stuff. He has apparently experimented with this very idea of shifting E.
So, it's a pipe dream for now.
-
@bot said in Why doesn't pressure advance use a more simple algorithm?:
@deckingman I think the E axis would have to be shifted to execute pulses BEFORE the X/Y/Z axes...........
We are in agreement - my quote "..........starting the extrusion slightly earlier than the carriage move......." is the same as shifting E axis pulses BEFORE the XYZ.
DC has mentioned something about forthcoming multiple data streams - this might be a candidate. It's somewhat akin to the technique I developed some years ago to shift the tool change points earlier in the gcode file so that colour changes with a mixing hot end can be accomplished with little or no purge. Although, in this case it's a fairly simple post slicer process to shift tool changes - the only complicated part is the need split moves into segments if the new tool change point happens to be in the middle of a move. But shifting every "E" move isn't something that could be done by manipulating the gcode file so it would be a bit more tricky to do.
-
@deckingman Sorry. I have a terrible ability to completely misunderstand things as I read them. You exactly said the same thing as me but I somehow interpreted it wrongly. My apologies. (Edit: It appears I was referring to your "Delaying the extruder move" statement. This would be akin to delaying all X/Y/Z moves.)
I have been dreaming of your tool-change preheat ability to be included into prusaslicer. They said it might come in 2.4, but if you ask me the chances look slim since it's already in beta.
Multiple g-code streams could definitely make this easy, perhaps. At least it might provide the facility in the codebase to hack it in.
*not actually a robot
-
@jens55 said in Why doesn't pressure advance use a more simple algorithm?:
[...]
BTW, I have had pressure advance settings that actually reversed feed at the end of a move ... something that a time shift is not able to deal with.I forgot to comment on this. This behaviour would be very similar with the simple algorithm, because any commanded retraction would happen slightly early.
-
@bot said in Why doesn't pressure advance use a more simple algorithm?:
.............I have been dreaming of your tool-change preheat ability to be included into prusaslicer. ..........................
You slightly misunderstand what it is I do. With a mixing hot end, all filaments are already loaded and therefore heated. This is both a blessing and a pain but suffice to say, there is no need to pre-heat when changing tools (or mixing ratios). But there is a need to purge out the old filament before using the next and that is where advancing the tool change point comes into play. Essentially when changing from one filament to another, the amount of filament that is in the mixing chamber and which needs to be purged before the new filament comes through can be determined. So what I do is work back from the tool change point in the gcode file and sum all the "E" values until I reach that pre-determined value. Then I move the "Tn" command from it's original position to the new position. The net result is that the tool change happens and the new filament starts to push out the old filament. The print continues and (if the tool change has been moved to the correct position in the gcode file), the new filament start to flow at exactly the point where the original tool change was. So (most of) the purge happens as the part is being printed which negates or at least reduces the need to purge between filament/colour changes.
Apologies for "diluting" your thread but I just wanted to clear that up.
-
@deckingman Oh right yes yes thank you. Similar concept, but different need.
