Advance algorithm for extruder hysteresis #645

Open
Lenbok opened this Issue Mar 21, 2015 · 8 comments

Projects

None yet

4 participants

@Lenbok
Lenbok commented Mar 21, 2015

One of the major effects that is still seen with bowden extruders is filament deficiency during acceleration and surplus during deceleration. @bkubicek has a solution proposed at:

http://bernhardkubicek.soup.io/post/425547834/My-anti-oozing-algorithm-was-implemented-using

Which seems like it should be fairly straightforward to implement as a configurable constant added to velocity during acceleration and another configurable constant subtracted during deceleration.

It would be great to have a solution to this in smoothieware, particularly as smoothie is very popular with the delta crowd where bowden extruders are in the majority.

@arthurwolf
Contributor

Hey.

Yeah, that's JKN advance, lots of people are asking for it.

Actually, somebody -did- implement it, but it was never pushed to github.
Mostly because we are currently refactoring the motion control code, and
the work that was done is incompatible with the way JKN was implemented
there.

So once the motion control refactor is finished, we'll be able to re-do the
JKN code to take that into account, and it should be fairly straightforward
to merge things back in.

Cheers !

On Sat, Mar 21, 2015 at 5:25 AM, Len Trigg notifications@github.com wrote:

One of the major effects that is still seen with bowden extruders is
filament deficiency during acceleration and surplus during deceleration.
@bkubicek https://github.com/bkubicek has a solution proposed at:

http://bernhardkubicek.soup.io/post/425547834/My-anti-oozing-algorithm-was-implemented-using

Which seems like it should be fairly straightforward to implement as a
configurable constant added to velocity during acceleration and another
configurable constant subtracted during deceleration.

It would be great to have a solution to this in smoothieware, particularly
as smoothie is very popular with the delta crowd where bowden extruders are
in the majority.


Reply to this email directly or view it on GitHub
#645.

Courage et bonne humeur.

@Lenbok
Lenbok commented Mar 21, 2015

Is it actually described anywhere what the difference is between @bkubicek's advance and JKN advance? I.e. what are the "JN" additions to the algorithm?

While looking for the advanceV2.pdf (which seems to be a dead link) I found another derivation:

http://www.dr-henschke.de/advance.html (google translate here: https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.dr-henschke.de%2Fadvance.html&edit-text=&act=url)

And other algorithm notes at:
http://bernhardkubicek.soup.io/post/255573067/the-advance-inplmentation-is-additionally-complex-as
and
https://groups.google.com/forum/#!topic/ultimaker/QMFVqEBarbQ

@Lenbok Lenbok changed the title from Extruder hysteresis algorithm to Advance algorithm for extruder hysteresis Mar 21, 2015
@dcnewman

... most sophisticated implementation according to its authors

At the time we did it, yes. I wouldn't be able to defend that claim now -- two years later -- as I am not familiar with all the progress in other firmwares in this area.

As to what we did beyond Bernhard's work? Not too sure why we need have done anything beyond Bernhard given that we had independently arrived at what we were doing but then quickly learned of Bernhard's work (early 2012). To acknowledge that several people had come up with the idea, when Jetty named it, he named it JKN putting the initials in alphabetical order.

Jetty and I had independently worked out the K portion of the advance in Sailfish. Then, in some discussions between Jetty and Bernhard, Bernhard mentioned his writeup which had come to the same conclusion. Again, this was around April of 2012. However, Bernhard was having a mental block as to how to realize the concept in 3D printing code. Jetty and I, on the other hand, had worked out a means of implementing it and had done so. Bernhard was a little dubious; he was at the time concerned about the discontinuity caused in the extruder's velocity profile. (E.g., http://bernhardkubicek.soup.io/post/255573067/the-advance-inplmentation-is-additionally-complex-as .)

So, as to the K portion of Sailfish's K and K2 parameters, Jetty and I had come up with that independently of Bernhard but then, through discussions with Bernhard, learned of his work. However, Jetty and I took it further: we took it from theory to implementation. I'm not sure if Bernhard ever finished his implementation in code (https://groups.google.com/d/msg/ultimaker/QMFVqEBarbQ/TYYYCbj6hwcJ).

The K2 portion of Sailfish's K and K2 parameters is entirely empirical and relates solely to the difficulty in bleeding off pressure in the melt chamber when decelerating.

@Lenbok
Lenbok commented Mar 24, 2015

@dcnewman Thanks for the additional background information and clarification!

So is the K2 parameter an additive offset to the primary K, or is it something that adjusts the profile in a more tricky manner?

It seems some aspects of the pressure management are quite hard to capture even after factoring in the advance model. I have observed while printing structures with extreme overhang and bridging that immediately after these sections of the path there is a deficit of extruded material -- I assume that during the overhang / bridge an excess of material is extruded due to reduced back-pressure, causing a drop in pressure in the extruder. While there is a chance that the slicer could capture that information perhaps the systems would benefit from some direct feedback. Some quite interesting work towards that is seen in http://airtripper.com/1338/airtripper-extruder-filament-force-sensor-introduction/

@dcnewman

@Lenbok It's purely an additive offset and entirely empirical. Thanks for providing that airtripper link. When I have some reasonable bandwidth I'll give it a look. Certainly reduced back pressure such as can occur when bridging would have an effect -- an effect best addressed in a slicer since expecting the firmware to know what it did (or did not do) in the layer immediately below is asking a lot. Unless of course, you have active pressure sensing which the title of that article hints at. Interesting indeed.

@dcnewman

Pulled some old research papers out of the cabinet. From what I know, the earliest publication presenting a reasoned, empirical unidimensional model showing that there is a dependence on the acceleration (second gradient of the motion) goes back to 1983, B.D. Coleman, Archive for Rational Mechanics and Analysis, Volume 83, page 115 (1983). Full disclosure: B.D. Coleman was my doctoral thesis advisor. For my Ph.D. thesis, I produced in 1989 the necessary mathematical analytic machinery to fully derive from three dimensional models that unidimensional model for both elastic polymers and polymers with memory including viscoelastic polymers. Coleman's work of 1983 drew upon work as far back as 1932 by Carothers, the discoverer of Nylon, and Hill, back at DuPont.

@hyperair
Contributor

Well, I unearthed bkubicek's advanceV2.pdf, but I'm unfamiliar with a lot of the symbols, so I'm not really able to make sense of the equations.

I had a look at Sailfish's implementation of JKN as well, but for some reason am simply unable to understand how it's done -- it's all over the place and hidden behind layers of #ifdefs. Can someone who understands this thing actually describe what should happen, please?

The closest I have to an understanding of how it's supposed to work is this graph, but it doesn't describe how you're supposed to calculate that velocity offset. Does JKN even function like the graph describes?

@hyperair
Contributor

Reposting this publicly with Dan's permission:

At the end of the day, K just recognizes the viscous stresses in the flow which scale
linearly with the local acceleration. (Local acceleration as opposed to
convective acceleration; there's always convective acceleration
here owing to the constriction in extruder; i.e., even at constant
feedrate, there's convective acceleration.)

We then asked ourselves how much faster do we really need to be attempting
to push in order to get the expected output rate. That then leads to
needing to run the extruder a tad faster for a bit whilst accelerating
and a tad slower under deceleration. You can look at it as needing
to build the pressure up a little faster under accel and then needing
to let it off quicker under decel. The hard part is not taking more
extruder steps than you're supposed to. In the original Jetty Firmware
(RepRap Gen 3 and 4 electronics), we simply ran the bressenham DDA a tad
faster/slower for the extruder steps. That's what we still do, but it's a
little more obscure: Jetty, in squeezing more cycles out of the little AVR
which could, made things a little less obvious.

The K2 parameter is purely a fudge: It's just really hard bleading
pressure off. K2 is just 100% empirical let's have an deceleration
dependent slowing down of the extruder even more during decel, preferrably
early on. Fortunately, for the speed ranges we work with it appears
to work well with a single constant, K2, across the range of interest.
(Some past attempts at doing advance algorithms all had the unfortunate
feature that the empirical constants had significant dependence on
feedrate.)

As per line 525 of

https://github.com/jetty840/Sailfish-MightyBoardFirmware/blob/master/firmware/src/MightyBoard/Motherboard/StepperAccelPlanner.cc#L525

The additional amount we speed up/slow down extrusion by whilst under
acceleration (deceleration) is

K * (Vfinal - Vinitial) [units of steps/s]

No acceleration term? It was there but then kinematics lets us work it
out using (Vfinal - Vinitial) owing to the use of constant acceleration.
(See earlier on in that block of comments.)

The K2 term is computed as

K2 * 100 * (acceleration / 64) / (steps-spent-decelerating)
[units of steps/s^2]

Again, the use of K2 is completely empirical.

this graph,
but it doesn't describe how you're supposed to calculate that velocity offset.

Have you found,

https://groups.google.com/d/msg/ultimaker/QMFVqEBarbQ/uqCcunbvuYMJ

Does JKN even function like the graph describes?

The K parameter indeed does behave just like that graph. Bernhard has posted
versions of that graph in the past, including back when he posted about JKN
in 2012. He's since deleted much of that posting and some related ones and only
some remnants survive,

http://bernhardkubicek.soup.io/post/255573067/the-advance-inplmentation-is-additionally-complex-as

But at the end of the day, we're running the extruder slightly faster or slower
based upon that calculation from line 525 cited above. And, yes things are
more obscure in current code: keep in mind that Sailfish is 66% an exercise
in squeezing the utmost performance out of a 90's 8bit, 16MHz AVR. So, there's
lots of stuff done with that goal but which has the effect of obscuring stuff.

@boelle boelle referenced this issue in MarlinFirmware/Marlin May 25, 2016
Closed

Extruder "Advance" Functionality #3867

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment