Extruder "Advance" Functionality

[boelle]

Issue by CCS86
Thursday Apr 14, 2016 at 13:41 GMT
Originally opened as https://github.com/MarlinFirmware/MarlinDev/issues/402

---

We seem to have some interest now in retooling the "Advance" function in Marlin, and had a good discussion in another issue, here: https://github.com/MarlinFirmware/MarlinDev/issues/77

Here were the key points:

@CCS86 commented on Aug 12, 2015
Thanks for the update Scott.

I feel like extruder pressure management is crucial functionality to achieve precise printing, across a wide range of machines; with different mechanics, motion tuning, and gcode.

Printing at slower speeds, with aggressive acceleration/jerk mitigates the negative effects when lacking pressure control, but results in slow prints with surface defects. Using conservative acceleration / jerk with higher speed accentuates the need for pressure management, but allows for faster printing, with better surface quality.

Another big potential benefit I see, is the ability to run much smaller retract moves. You no longer have to depressurize the nozzle with the retract move. Instead, you have bled off extruder pressure beforehand, so only a small retract move would be needed (in theory). Smaller retract = less nozzle dwell time = better print quality (especially if retracts occur on an external perimeter).

I'm not much of a coder, but as an ME, have some ideas on modeling the important factors and keeping the algorithm as light as possible. Happy to help where I can on the next attempt.

@alexborro commented on Aug 13, 2015
I have read a lot about Advance implementation and the one in SailFish
works pretty good.. We just need to port it to Marlin.

Cheers.

@Nandox7 commented on Aug 13, 2015
I also started looking to it sometime ago, but free time isn't much recently.
But I'll have it again soon. :) (i hope)

Hopefully we're getting enough people attention to have more looking into this and fix/implement it properly.

In a different issue # i shared some of my findings and testing results so far.
For example I see no change whatsoever when changing the values despite the debug output calculations seem ok.
The current implementation doesn't seem to be taking and using the calculated values.

I compared similar behaviour with some slicers that already do this in the produced gcode and it's definitely a much welcome feature as it greatly improves specific parts of the printing process.

@thinkyhead commented on Feb 24
I see this issue is still alive!

The ADVANCE feature is still not well-trusted and needs a lot of testing and refinement to make sure it's following the right idea. I just downloaded Matthew Roberts' custom firmware in which he implements his ADVANCE feature and I'm using that for reference. I'd like to gather together all developers and users who are interested and form a little working group to attack this feature and get it working properly.

I have also peeked at the "JKN Advance" algorithm in Repetier, Sailfish, and SmoothieWare, all of which follow similar but divergent approaches. What I'd like to do first is to flowchart all these implementations so we have a best understanding, compare their similarities and differences, and settle on how we want to patch Marlin to capture the best elements of all these implementations.

Note that Slic3r now includes its own handling of Advance. Slic3r may be able to do Advance more smartly than Marlin because the slicer allows you to specify the filament diameter. In contrast, Marlin has only a default filament diameter (DEFAULT_NOMINAL_FILAMENT_DIA) and an EEPROM setting that can be changed and saved for "Volumetric Extrusion" (M200 E units in mm^3), but it has no adjustable setting for filament diameter that would apply to ADVANCE. I believe that for ADVANCE to work well, it should use an adjustable filament diameter value and not a fixed one, as it now does. I believe this is one way that firmware-based ADVANCE needs to be improved if it is to work as well as slicer-based Advance.

Related issues:

#1600
Ultimaker#7

@Sebastianv650 commented 12 days ago
Hope it's OK I'm posting here regarding the JKN feature..
I think a working JKN (or similar) implementation could improve "high speed" print quality dramaticaly. "" because high speed is everything with print speed > jerk speed, and with usual jerk values thats all low speed ;)
That's why I'm thinking about how to get it into Marlin. During my resarch I found this issue, glad to see an active person like thinkyhead has this on the list also :)
I had a look at the sailfish implementation here: https://github.com/jetty840/Sailfish-MightyBoardFirmware/blob/master/firmware/src/MightyBoard/Motherboard/StepperAccelPlanner.cc#L525
Together with this description: Smoothieware/Smoothieware#645 (comment)

The basic math seems to be realy simple (given the fact someone invented it already, of course!). I compared the code to the Marlin one, it looks even quite compatible in some areas. At last compatible enough to give a good basis for someone already in the Stepper control files, which is not true for me at the moment.
Long text for a short question: Is there a reason why a "copy and modify where neccesary" won't work? At the moment, it seems to be too easy compared to the fact nobody tried it in all the years..

@thinkyhead commented 2 days ago
@Sebastianv650 The hook is in place with an added interrupt when ADVANCE is enabled. As far as I know, "JKN" uses the same technique, just slightly different maths.

@Sebastianv650 commented 19 hours ago
I got the advance to work after a little bit of debugging and I also implemented somithing with the calculation method used by JKN. I think I will create a pull request for the implemented advance version because it is always better to have a working feature instead of a broken one.
But I got two conclusions:
.) The result with a calibrated k value is the same for JKN like method and "advance". OK not much a surprise as they both add or subtract esteps / loop. But
.) I'm not happy with the results. I thought I should get a nearly perfect square looking on top of a test cube without bleeding edges, but that's not the case. It's better then without advance, but it could be much better.. I think the method of distributing the advance e-steps equaly through the acceleration and deceleration phase is not good enough. For a deceleration phase for example, I think it would be better to start releasing the pressure slowly at first, but retract much faster during the last decel steps..
I have to do more tests during the next days if I can find some time.

@CCS86 commented 18 hours ago
Great to hear that you got it up and running!

I wonder whether we could create a simple gcode test to simplify and quantify how well each phase is working. Maybe a single line commanded at a very high print speed, and repeated for some number of layers. Then with calipers you could measure the width near the start and ends to gauge the extrusion vs print head speed mismatch.

Does marlin support logic in gcode? (ie. IF/THEN/GOTO)

@alexborro commented 16 hours ago
Hi Sebastian,

I'm temped to work in the "advance" algorithm as well, actually, trying a
port of JKN from sailfish to marlin. Everybody says JNK is wonderful.

Did you understand how JKN works? If yes, I appreciate any simple
explanation. We can work together on this.

Cheers.

Alex.

@CONSULitAS commented 2 hours ago
@Sebastianv650
Great!

I think I will create a pull request for the implemented advance version because it is always better to have a working feature instead of a broken one.
We would like to see a PR for your fix. 👍 A lot of people are waiting for this, i think.

I'm not happy with the results.
Even if it is not the perfect solution, every improvement counts. Could you perhaps post a photo that illustrates the improvement so far?

For a deceleration phase for example, I think it would be better to start releasing the pressure slowly at first, but retract much faster during the last decel steps..
IMO it is clear, that a linear solution for non linear behavior of the pressure in the nozzle is not perfect. There seems to be a nonlinear factor missing in the maths...

[boelle]

Comment by Roxy-3DPrintBoard
Thursday Apr 14, 2016 at 15:05 GMT

---

It would be helpful for me to see close up pictures of a JKN improved print versus a 'Normal' print. Does anybody have a way to get both pictures so it is easier for us to visualize and discuss the properties?

[boelle]

Comment by Sebastianv650
Thursday Apr 14, 2016 at 15:41 GMT

---

OK here is what I plan to do on next Saturday (hoping a have enough time):

• Create a pull request against RCbugfix for Marlin advance.
• Create a presentation about what I found out up to now, also with pictures so we can reference to something if we discuss a special detail. I think this is absolutely necessary to get a common understanding to start with.

I think I found out whats the problem with both existing advance implementations:
They calculate a speed depending advance step amount. That's OK and I think especialy the k*dv (dv=delta velocity, extruder velocity to be precise) is the right way how to do it.
But they spread it equaly through all acceleration/deceleration step loops. That would be true if this ISR is called in equal time steps, so dv is the same for each loop. But we step the steppers in equal distances depending on the step/mm value, not in equal time frames. This leads to a wrong advance step distribution. You can see a graph of the speed distribution over distance at the bottom of the page here: http://prusaprinters.org/calculator/
The best way to get around this would be to calculate the dv between each ISR call (dv= currentv - last v) and calulate the neccesary extra esteps "on the fly". I will try such an implementation in the next days, I think it should work much better..

[boelle]

Comment by alexborro
Thursday Apr 14, 2016 at 15:58 GMT

---

Sebastian, as far as I know - at least in marlin - the advance has its own
ISR (TIMER0_COMPA_vect).. the extruder stepper is not fired in the same ISR
as other axis.
Did you ckeck that??

Cheers.

Alex.

2016-04-14 12:42 GMT-03:00 Sebastianv650 [email protected]:

OK here is what I plan to do on next Saturday (hoping a have enough time):
.) Create a pull request against RCbugfix for Marlin advance.
.) Create a presentation about what I found out up to now, also with
pictures so we can reference to something if we discuss a special detail. I
think this is absolutely necessary to get a common understanding to start
with.

I think I found out whats the problem with both existing advance
implementations:
They calculate a speed depending advance step amount. That's OK and I
think especialy the k*dv (dv=delta velocity, extruder velocity to be
precise) is the right way how to do it.
But they spread it equaly through all acceleration/deceleration step
loops. That would be true if this ISR is called in equal time steps, so dv
is the same for each loop. But we step the steppers in equal distances
depending on the step/mm value, not in equal time frames. This leads to a
wrong advance step distribution. You can see a graph of the speed
distribution over distance at the bottom of the page here:
http://prusaprinters.org/calculator/
The best way to get around this would be to calculate the dv between each
ISR call (dv= currentv - last v) and calulate the neccesary extra esteps
"on the fly". I will try such an implementation in the next days, I think
it should work much better..

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210008602

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[boelle]

Comment by jbrazio
Thursday Apr 14, 2016 at 15:59 GMT

---

Just for reference: #3424

[boelle]

Comment by Sebastianv650
Thursday Apr 14, 2016 at 16:07 GMT

---

@alexborro thats right, but the esteps addition is made in the usual ISR. They are only executed by a seperate ISR. I don't get the purpose of this to be honest, I think that's not absolutely necessary.

[boelle]

Comment by alexborro
Thursday Apr 14, 2016 at 17:55 GMT

---

It is strange.

I think we should understand how a good advance algorithm should work and
compare Sailfish and Marlin solutions.. Implementing it will be pretty much
straight forward.

@Sebastianv650, if you could spend some time making some doc about what you
figured out, the math involved, I can help you debugging the code and
implement the fixes/new algorithm.

We can create a branch off of Marlin to work together.

Cheers.

Alex.

2016-04-14 13:07 GMT-03:00 Sebastianv650 [email protected]:

@alexborro https://github.com/alexborro thats right, but the esteps
addition is made in the usual ISR. They are only executed by a seperate
ISR. I don't get the purpose of this to be honest, I think that's not
absolutely necessary.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210022259

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[boelle]

Comment by Sebastianv650
Saturday Apr 16, 2016 at 07:46 GMT

---

I did a quick-and dirty presentation about the basics I got up to now:
https://drive.google.com/open?id=0B5UvosQgK3adaHVtdUI5OFR3VUU

I hope it is enough for a first step, I want to spend my time into coding now. I'm very excited if my aproach regarding new advance step distribution will work!

[boelle]

Comment by jbrazio
Saturday Apr 16, 2016 at 08:58 GMT

---

Great info, great investigation, great work ! :double-thumbs-up:

It makes perfect sense that dV will vary between ISR(), this could be overcome by having Marlin doing some kind of global average instant velocity or why don't include a dt into the advance calculation like some PID have exactly to compensate for inconsistent sampling intervals ?

[boelle]

Comment by Sebastianv650
Saturday Apr 16, 2016 at 13:18 GMT

---

I'm currently looking for some existing dt.. We have an acceleration_time and a deceleration_time used by the ISR. They are used to calculate when the next interrupt has to happen. But I don't get the unit they use, maybe someone can help?
I printed the result after a block to serial. A move with speed = 100mm/s and accel. of 1200mm/s² should take (speed/accel) about 80ms. But Marlin prints 154567 for accel. and 160889 for decel.
So the numbers could be in µs, but they are doubled compared to my calculated ones. This is repeatable for other speeds, if I calculate 40000µs to reach 50mm/s, Marlin reports 80000 and so on. Why?

Anyone has a better idea how to get e velocity? Looks like I have a little mental block..

Edit regarding acceleration_time: Dumb question, it proves my last ATmega project was some years ago.. Of course this is due to the timer / prescaler settings. 1ms = 2000 "cycles" for the settings used in Marlin. Perfect, so everything we need as input is already calculated!

[boelle]

Comment by alexborro
Saturday Apr 16, 2016 at 18:41 GMT

---

What if we put all the esteps related calc in a separated place?? I mean,
maybe in its all ISR ?? We have the total total steps the extruder should
move and the total time of that movement. And the other axis acceleration
as well.
I mean, something like this:

Does it make sense??

[image: Imagem inline 1]

2016-04-16 10:18 GMT-03:00 Sebastianv650 [email protected]:

I'm currently looking for some existing dt.. We have a acceleration_time
and a deceleration_time used by the ISR. They are used to calculate when
the next interrupt has to happen. But I don't get the unit they use, maybe
someone can help?
I printed the result after a block to serial. A move with speed = 100mm/s
and accel. of 1200mm/s² should take (speed/accel) about 80ms. But Marlin
prints 154567 for accel. and 160889 for decel.
So the numbers could be in µs, but they are doubled compared to my
calculated ones. This is repeatable for other speeds, if I calculate
40000µs to reach 50mm/s, Marlin reports 80000 and so on. Why?

Anyone has a better idea how to get e velocity? Looks like I have a little
mental block..

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210813734

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[boelle]

Comment by Sebastianv650
Saturday Apr 16, 2016 at 19:10 GMT

---

Maybe I'm not understanding what you are meaning, but the calculation for advance is only 3 or 5 extra lines. I would go the other way round:remove that unnecessary extra advance isr and do the esteps inside the main ISR as it's done without advance.

[boelle]

Comment by jbrazio
Saturday Apr 16, 2016 at 19:29 GMT

---

Do you believe we can create this as a self contained object ?

[boelle]

Comment by Sebastianv650
Monday Apr 18, 2016 at 15:27 GMT

---

Somebody want's to see some awsome pictures?
I got it working, and it's way better than the implementations before! I would say it's hard on the border to perfection - sorry, but I feel like a child on christmas :-)

I printed two identical test cubes: 20x20x2mm, 0,2mm layer height, 80mm/s print speed, 500mm/s² accel. to see the distribution.
On the left you can see the one without advance (k=0), on the right there is the cube with advance (k=250, I'm using integer calculations for speed). I think the pictures and the dimensional tolerance increase don't need more words - the k=0 part has the rough top infill due to the high speed, the other one is smooth as skin!

Here you go: Pictures

Now the code needs some testing and streamlining, then I call it ready to share!

[boelle]

Comment by CCS86
Monday Apr 18, 2016 at 16:28 GMT

---

Dude, @Sebastianv650 , that looks outstanding!!!!

I am super excited about this!

[boelle]

Comment by jbrazio
Monday Apr 18, 2016 at 16:32 GMT

---

Congrats, that looks awesome !

[boelle]

Comment by Nandox7
Monday Apr 18, 2016 at 16:40 GMT

---

Great work done there! That is cool.

In regards to the results cube when using K=0, why the warped corners?
A normal print without using this feature won't create that, is that the
result of having the feature enabled?
(and working, because before it wasn't actually doing anything... :) )

-Nando
Sent from my Sinclair ZX81

On 18 April 2016 at 17:32, João Brázio [email protected] wrote:

Congrats, that looks awesome !

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-211459963

[boelle]

Comment by jbrazio
Monday Apr 18, 2016 at 16:53 GMT

---

why the warped corners

Due to the [high] printing speed.

[boelle]

Comment by Sebastianv650
Monday Apr 18, 2016 at 17:34 GMT

---

@Nandox7 , @jbrazio is right it depends on the print speed. That's why you should print the perimeters slow without advance. The faster you go, the more the edges will bleed out. If you print at or around jerk speed, the edges will be perfect. But than a big print will take ages..
Same is true for the top infill. If you print it slowly, it will look nice even without advance. But if you go fast, it will get rough at the direction change points. Fast is meant as mm³/s to be precise, if you are happy with your print quality at 30mm/s and 0,2mm layer height you can do also 60mm/s at 0,1mm layer height without quality changes. At least if your axes can to that, of course..

[boelle]

Comment by alexborro
Tuesday Apr 19, 2016 at 00:22 GMT

---

Nice work Sebastian!

If you don't mind sharing the code, I would like to merge it into my branch
and perform more tasks.. I think the more data we gather, the better.

Cheers...

Alex.
Em 18/04/2016 14:34, "Sebastianv650" [email protected] escreveu:

@Nandox7 https://github.com/Nandox7 , jbrazia is right it depends on
the print speed. That's why you should print the perimeters slow without
advance. The faster you go, the more the edges will bleed out. If you print
at or around jerk speed, the edges will be perfect. But than a big print
will take ages..
Same is true for the top infill. If you print it slowly, it will look nice
even without advance. But if you go fast, it will get rough at the
direction chance points. Fast is meant as mm³/s to be precise, if you are
happy with your print quality at 30mm/s and 0,2mm layer height you can do
also 60mm/s at 0,1mm layer height without quality changes. At least if your
axes can to that, of course..

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-211489911

[boelle]

Comment by Sebastianv650
Tuesday Apr 19, 2016 at 14:38 GMT

---

I created a fork of Marlin RCBugfix and added my changes:
https://github.com/Sebastianv650/MarlinRC_LIN_ADVANCE

Any comments are welcome, consider it as a working draft. The goal is to improve the code until everyone is happy and we can transfer it into Marlin.
Working with Github (forks, pull requests etc) is new for me, so also feel free to tell me if I'm doing something wrong with it!

What should be tested:
.) Is one k value true for different print settings (layer height, speed ranges, ..)? K should differ between filament types (PLA, ABS, PETG, ..) or extruder types.
.) There might be a problem with very tiny perimeter steps. Take this model as a reference. Without advance, it prints with much of stutter on my TAZ 5 over USB with high print speeds, with advance there is too much material on the feets of the gecko. I'm not sure if this is because Marlin can't catch up calculating all the necessary steps in general or if it has something to do with the advance feature.

One important thing is still open in the code:
If you have a look into stepper.cpp, line 770 to 784, you can see I got crazy about macros staggered on each other. I had a mental block how to write this in a nice way so I took the original advance way of doing it and clipped it to only fire the first extruder. So this will not work if you have more than one..

Edit: And the M905 code was only choosen because it was free, if someone has a better idea where it would fit - tell us!

[boelle]

Comment by jbrazio
Tuesday Apr 19, 2016 at 14:48 GMT

---

So you have completely removed this method ?

// extruder advance constant (s2/mm3)
//
// advance (steps) = STEPS_PER_CUBIC_MM_E * EXTRUDER_ADVANCE_K * cubic mm per second ^ 2
//
// Hooke's law says:    force = k * distance
// Bernoulli's principle says:  v ^ 2 / 2 + g . h + pressure / density = constant
// so: v ^ 2 is proportional to number of steps we advance the extruder
//#define ADVANCE

#if ENABLED(ADVANCE)
  #define EXTRUDER_ADVANCE_K .0
  #define D_FILAMENT 2.85
#endif

[boelle]

Comment by Sebastianv650
Tuesday Apr 19, 2016 at 14:58 GMT

---

The original advance is still there, my implementation is quite different so I wasn't able to reuse code. So I created a new LIN_ADVANCE because I wasn't sure if somebody wants to keep the original thing.

[boelle]

Comment by jbrazio
Tuesday Apr 19, 2016 at 17:04 GMT

---

If we improve then this one shall replace the other, re using as much as possible (not the code) but the configuration flags.

If you don't mind cleaning the code from the previous unused implementation that would also be appreciated.

[boelle]

Comment by Sebastianv650
Tuesday Apr 19, 2016 at 17:29 GMT

---

.) There might be a problem with very tiny perimeter steps.

Got it. Marlin will collapse very short moves to the next longer move. If a short move is executed together with a retract or unretract move, this leads to an unwanted hughe advance step mounts. The math is correct, but advance together with retract moves is unwanted. I have to find a way to filter is one out. A workaround is to compare bse and allsteps, if they are nearly equal it is a retract or unretract move.

[boelle]

Comment by Sebastianv650
Tuesday Apr 19, 2016 at 18:35 GMT

---

@jbrazio, no problem, I could do that. But there is one thing to consider:
Due to the new advance esteps distribution, the extruder has to do a lot of steps at the beginning and ending of a line. This seems to be no problem for a direct drive, but what's about bowden systems? I guess they need a much bigger k value, maybe their extruder can't handle that. Than it would be better to have a (working) classic advance than nothing. Maybe someone with a bowden system can test this?

[boelle]

Comment by alexborro
Tuesday Apr 19, 2016 at 18:44 GMT

---

@Sebastianv650 I have a bowden system to test. And believe me, it is possible to have faster bowden extruder, with correct gear ratio. Mine is capable of 85mm/s.

By why does it need a lot of steps in the end of a line?? I understand in the beginning - the advanced steps - but it should be subtracted from the esteps in the end of a line, shouldn't it?

[boelle]

Comment by Sebastianv650
Tuesday Apr 19, 2016 at 19:03 GMT

---

I know a bowden can be as fast as a direct drive, but I'm afraid it has to be much faster then a direct for this. Think of the filament between the nozzle and your extruder as a spring. If you have to bring this spring to a specific force by compressing it, that might be no problem if your spring is short. If your spring is 10x longer, which means it's much "softer", you have to do a lot more travel mm to reach the force needed in the same time..

You are right, the beginning is the chalanging part. If it can handle the "jumpstart", the break down will be no problem.

[boelle]

Comment by CCS86
Tuesday Apr 19, 2016 at 19:19 GMT

---

It seems to me that the machine's acceleration settings will have a
dramatic impact on the advance extruder velocity demands. The default 4000
mm/s/s is pretty aggressive. Having proper advance really eliminates the
need for such aggressive acceleration. I already run mine closer to 2000,
with no advance. Though I print at slower speeds usually.

On Tue, Apr 19, 2016, 2:03 PM Sebastianv650 [email protected]
wrote:

I know a bowden can be as fast as a direct drive, but I'm afraid it has to
be much faster then a direct for this. Think of the filament between the
nozzle and your extruder as a spring. If you have to bring this spring to a
specific force by compressing it, that might be no problem if your spring
is short. If your spring is 10x longer, which means it's much "softer", you
have to do a lot more travel mm to reach the force needed in the same time..

You are right, the beginning is the chalanging part. If it can handle the
"jumpstart", the break down will be no problem.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-212070773

[boelle]

Comment by Sebastianv650
Wednesday Apr 20, 2016 at 16:35 GMT

---

I noticed that I get too much material extruded with advance enabled, which is most noticeable on small details with 100% infill like the top of a cone. To track this down, I created a counter for the sum of all esteps due to advance and another one that counts the time spent accelerating and decelerating.

In theory, they should be both 0 after each print - you can't come to a stop if you are always longer accelerating than decelerating. In reality, both values gets bigger over time which means Marlin is always longer in accel. than decel.

Anyone has an idea what's wrong in my thinking? You can try it very simple with a static long counter_timer variable in stepper.cpp. Add all "timer" for accel., subtract all "timer" during decel.

[boelle]

Comment by alexborro
Wednesday Apr 20, 2016 at 17:03 GMT

---

The number of acceleration is not equal to deceleration due to jerk and
look-ahead. You can have a sequence of movements with 10 accel and just 1
decel.

About the amount of extruded material, are you sure you are not changing
the total amount of steps??
If one movement is suppose to have 1000 esteps, no matter when you fire the
steps, it should have done 1000 esteps in the end of XYZ movement. Maybe
you are adding (advancing) steps in the beginning of the movement and not
subtracting them in the end??

Cheers.

Alex.

2016-04-20 13:35 GMT-03:00 Sebastianv650 [email protected]:

I noticed that I get too much material extruded, which is most noticeable
on small details with 100% infill like the top of a cone. To track this
down, I created a counter for the sum of all esteps due to advance and
another one that counts the time spent accelerating and decelerating.

In theory, they should be both 0 after each print - you can't come to a
stop if you are always longer accelerating than decelerating. In reality,
both values gets bigger over time which means Marlin is always longer in
accel. than decel.

Anyone has an idea what's wrong in my thinking? You can try it very simple
with an static long counter_timer variable in stepper.cpp. Add all times
for accel., subtract all times spent on decel.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-212504327

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É
aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[CCS86]

@Sebastianv650

How difficult would it be to merge your code into the 1.0.x branch of Marlin?

Part of me wants to try the new 1.1.x RC, but I'm a little worried about all the safety stuff being 100% online, and I'm not sure if anyone has set it up for an Ultimaker yet.

[jbrazio]

Duplicate of #3676

[SimonSolar2C]

Id like to add an observation to this discussion, regarding my observation running tests of the LINEAR_ADVANCE functionality.
I started this investigation when I observed inconsistent extrusion thickness whilst printing thin walled wing sections, and then in diagnosing, I syudied the thicker blobbing corners on a basic test square. My conclusion is that the speed. I also wanted to print as fast as possible. According to E3D, the ability to push through the filament consistently at the specified temperature is limited to 60mm/s at 0.20mm height, 0.40mm nozzle.
I wanted to actually see when this dropoff occurs - when does extrusion stop being consistent as we increase the speed.
The results were astounding !
The Test
10 test cubes printed at speeds of 10,20,30,40,50,60,70,80,90,120mm/s
Esun PLA tests with K=70, wall thickness extrusion setting
Measure the single wall thickness averaged around the cube.
Results
What I saw did not match the theory - the wall thjckness at slow speeds is far greater than higher speeds and it is not linear. The wall thickness should not change until it hits that point where extrusion cannot keep up.
Conclusion
The ADVANCE algorithm may help with blobiness at the ends/starts of extrusion, but thickness is not consistent at various speeds and likely across the acceleration. So for small intricate models, XY motion will move slower and likely be over-extruded compared to large models where full speed is reached (60mm/s in my case)
My Action Item
Write into this thread and hope a developer cleverer than me will implement a 'fudge factor' into the part of marlin that relates extrusion velocity to XY velocity so we can use it to adjust the angle of the curve in the graph below to become more horizontal.

.

[Sebastianv650]

I think I don't get your chart to 100%. What do you mean with 1 turn / 2 turns and what are the differences between the 4 plots in generall. The short description below is a bit confusing to me, do you tested different heat blocks or extruders?

Beside this, I think you might have a problem not related to the intention that an advance function has. Advance only adjusts for the effects during acceleration / deceleration, where the main portion is comming from the springiness of the filament but there are a lot of other smaller factors that are not covered from any implementation at the moment. So advance tries to cover a dynamic behaviour.

When you measure the wall thickness of a "suitable long" straight wall at different speeds, where suitable long means it's much longer than the acceleration distance, you should see a stabilised flow with and without advance active. Therefore, also the wall thickness should be equal through all test cube speeds. If it's not, you have a slipping extruder to filament drive. Think about it: If the filament wouldn't be slipping in the extruder gear and you see less extrusion than your extruder speed should result in - where is the delta filament volume gone? It can't disapear.
Some slipping at high print speeds is quite common, depending on the drive system used. The best solution if you have problems with it is to upgrade to a better drive system. A software solution could be to use variable estep/mm settings depending on extrusion speed. But this would be maybe even more complicated to calibrate than advance K factor and I'm not a fan of SW solutions if there are hardware ones. Especialy because our AtMega boards are already quite on their processing power limit.

[SimonSolar2C]

Hi @Sebastianv650 - only just saw your comment now - Yes I 100% agree that the delta filament cannot disappear - hence my test to try and find cause. Also looking to see if linear advance can fix the problem seen in the graphs. As stated the graphs should be a straight line, until the speed increases such that the heatblock can no longer keep up, and then what will happen? If it cant shove the filament through, then either it compresses ( and oozes out during the next move ), or the extruder slips.
You can see I got better results with the screws on the filament tighter - so that answers the second part of this.
But what this test should be showing for good linear behaviour, is a straight line up to the theoretical top speed , which is said to be about 60mm/s @0.48mm /0.20layer . For some reason the original TEVO hotend performed better than the E3DV6, but I never went back to double check the original hotend again.
And so I wanted to see just where the performance dropped off, but because it is not a straight line, I have to wonder where is the cause. What it means in reality is that more extrusion comes out at slower speeds, eg corners of test squares, which is often what we see.
Is it the same on all machines - is it a physical science problem of liquid flow - what is the cause, and does marlin need a fudge factor of extrusion*speed, or maybe I just need a new extruder.
I'm suspicious that tightening the screws improved the linearity, therefore 'm thinking of buying the TitanAero, then I will run a comparison test.

[Sebastianv650]

Maybe #9852 will give you some informations.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.