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 notifications@github.com:

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 notifications@github.com:

@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 notifications@github.com:

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.