Blobless printing in Marlin

[antiklesys 3]

Does anyone know whether Marlin supports this feature or whether it could be added?

http://basdebruijn.com/2014/05/machinekit-and-additive-manufacturing

http://hackaday.com/2014/05/10/blobless-printing-with-velocity-extrusion

 

[gr5 2,167]

If you print slower than the jerk setting (20mm/sec) then you should get blobless printing also as now the feeder just runs at a constant speed for the whole print without slowing down or speeding up.

But it would be lovely to get high quality prints at 100mm/sec and for this we need this feature.

If you read all the comments in the second link you post above, people mention that in *Marlin* this feature is called "advance". I have been meaning to test it out. I haven't heard anything from anyone who uses the feature on the UM1 or UM2. Here is the relevant setting - you have to uncomment the first line and supply a constant in the units of s^2/mm^3 whatever that means. One would have to experiment with different values I guess.

from configuration_adv.h:

 

//#define ADVANCE
#ifdef ADVANCE
  #define EXTRUDER_ADVANCE_K .0

Here are examples on a (really crappy?) rep rap without advance and with:

 

Here is the original article about this feature:

http://reprap.org/pipermail/reprap-dev/2011-May/003323.html

 

[anon4321 16]

Hmmmm my post got lost or I never submitted it... Anyway the marlin firmware builder exposes the advanced option but the site notes that it is something that:

"does some fancy pressure calculated extrusion amount which never works as far as I know"

See the ? next to the Enable extruder advance:

http://marlinbuilder.robotfuzz.com/

 

[illuminarti 18]

That comment comes from the Marlin source code.

[Daid 306]

The above articles are about LinuxCNC, in which someone linked the E acceleration and speed to the X/Y/Z acceleration and speed. Something that Marlin, Sprinter has been doing for years already.

"Nothing to see here, move along" would be the proper title.

 

[gr5 2,167]

No - it's more than that. That was the first step which then allowed the second step: to add extra velocity when accelerating and remove some when slowing down. This preloads the pressure and removes the pressure sooner when slowing down than normal extruder movement. This is especially helpful in printers with Bowdens which store some of the energy/pressure.

The feature in Marlin that does something similar called "advance" has faulty logic - it may work somewhat but for the wrong reasons. Bernhard did the math better and realized to do it right you need infinite acceleration/jerk on the extruder and so I think he just kind of gave up instead of trying to come up with an approximation/improvement to Marlin.

Bernhard has a paper and several blog posts. Some posted years ago, some posted 3 days ago. This single image is sufficient though to understand it if you stare at it long enough:

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

The UM2 can probably handle the infinite acceleration (it's not a huge velocity increase) as it should be able to handle much larger sudden velocity changes for typical extruding speeds.

Someone at UM should send Bernhard a free UM2 so he can test this stuff out with that fast feeder. This could improve "blobbing" on sharp corners and such. It should help with Bridging also. It should make it so you can print faster and still get excellent quality.

 

[lars86 42]

No - it's more than that.  That was the first step which then allowed the second step: to add extra velocity when accelerating and remove some when slowing down.  This preloads the pressure and removes the pressure sooner when slowing down than normal extruder movement.  This is especially helpful in printers with Bowdens which store some of the energy/pressure.

The feature in Marlin that does something similar called "advance" has faulty logic - it may work somewhat but for the wrong reasons.  Bernhard did the math better and realized to do it right you need infinite acceleration/jerk on the extruder and so I think he just kind of gave up instead of trying to come up with an approximation/improvement to Marlin.

Bernhard has a paper and several blog posts.  Some posted years ago, some posted 3 days ago.  This single image is sufficient though to understand it if you stare at it long enough:

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

The UM2 can probably handle the infinite acceleration (it's not a huge velocity increase) as it should be able to handle much larger sudden velocity changes for typical extruding speeds.

Someone at UM should send Bernhard a free UM2 so he can test this stuff out with that fast feeder.  This could improve "blobbing" on sharp corners and such.  It should help with Bridging also.  It should make it so you can print faster and still get excellent quality.

 

This deserves a bump!

Has anyone been experimenting with the "advance" function in Marlin?

[gr5 2,167]

To do "advance" correctly I've come to realize you need a bit more powerful computer (not much more) than an arduino. For example a beaglebone. Most printers out there are not bowden printers and the few that are (e.g. ultimaker) don't seem to think this is a priority. :(

[lars86 42]

Bummer!

I can't help but wonder if there is a simpler approximation of this model, that could run well on the arduino, or even just a slicing feature.

I understand that skeinforge and slic3r (experimental) have features to shift extruder moves relative to print head moves, to help account for this spring induced lag/energy storage effect.

I was thinking about making a test print that laid down some single filament lines as a "start/finish line" , then approach them at 90* in a print move and right when the print head crosses the start line, begin the extruder move for printing, and at the finish line stop extruding.

You could look at the distance between nominal and actual start/stop, do this at different speeds and see if there is a correlation of lag time or distance.

[gr5 2,167]

That's interesting but you shouldn't think about it as a simple lag time there actually is zero lag time as the speed of sound through PLA from feeder to extruder is negligible - you should think about it as controlling the pressure. You want a higher pressure when you are printing faster and a lower pressure when printing slower. You need to add extra pressure depending on the extruder acceleration. But you need to modify the pressure instantly if you change the acceleration instantly and Marlin only allows instantaneous acceleration changes (no true jerk control). Marlin allows some instantaneous velocity changes but it's limited to the "fake jerk" parameter. Just read Bernhards stuff linked above - it's very interesting. Especially the graphs. But keep in mind that the Y axis is velocity not position - this takes some time wrapping your head around it.

I think you could do it possibly on an arduino if you put some of the smarts into the slicer. But the slicer and arduino would both have to know a constant for how much extra velocity you need on a given acceleration.

[lars86 42]

That's interesting but you shouldn't think about it as a simple lag time there actually is zero lag time as the speed of sound through PLA from feeder to extruder is negligible - you should think about it as controlling the pressure.  You want a higher pressure when you are printing faster and a lower pressure when printing slower.  You need to add extra pressure depending on the extruder acceleration.  But you need to modify the pressure instantly if you change the acceleration instantly and Marlin only allows instantaneous acceleration changes (no true jerk control).  Marlin allows some instantaneous velocity changes but it's limited to the "fake jerk" parameter.  Just read Bernhards stuff linked above - it's very interesting.  Especially the graphs.  But keep in mind that the Y axis is velocity not position - this takes some time wrapping your head around it.

I think you could do it possibly on an arduino if you put some of the smarts into the slicer.  But the slicer and arduino would both have to know a constant for how much extra velocity you need on a given acceleration.

 

I agree. I see evidence of the need for this all the time in my prints. If you could effectively bleed off extruder pressure when approaching the end of a print move, you could get away with much shorter retract moves as well. Then you spend less time dwelling, waiting for the retract to finish.

It sounds as if sailfish has implemented this motion control logic without the need for faster hardware. I have to believe that you can simplify the mathematical model to predict the most dominant effects, in a way that isn't computationally expensive.

[gr5 2,167]

Actually you don't need retracts at all if you implement this properly. It's kind of built into the whole thing.

There's two ways to implement "advance". Most people get the idea to modify the extruder such that it accelerates faster than the head accelerates and decelerates faster and so on. But alternatively you can have the extruder run at a reasonable position and have the XY lag instead - have the XY accelerate *slower* than the extruder and so on. Have the XY pause briefly while extruder builds up pressure and so on.

[lars86 42]

It seems like working within existing acceleration values for the head and extruder, you could still implement this.

The two main issues are:

- There is a relationship between extrusion rate and extruder pressure. (this will vary between hot end design, temperature, filament characteristics, etc). No need to force mathematical modeling in real time of this (in my eyes). Just model it offline to determine correct application and starting coefficient values, then empirically tune the value(s) for your machine/print.

- There is a spring effect when using filament to drive extrusion (especially with bowdens). This K will also vary between bowden setup, filament type, etc.

The idea seems to be keeping the extruder at the pressure required for the current extrusion rate ( 0 - max mm^3/s), and you can do this by knowing the spring constant K of the drive system, therefor how much linear filament movement is required to get from the current extruder pressure to desired pressure, and doing so slightly ahead of time relative to the print head, to account for the time needed for that prime/deprime extruder move.

Edited July 31, 2015 by Guest

[gr5 2,167]

Yes. You can also "easily" calibrate and determine the K value by printing a bottom layer pattern on glass and taking a photo.

I would draw a large open square with 3 90 degree turns and do this at various speeds (10mm/sec, 40mm/sec, 150mm/sec). It's known what the jerk and acceleration values are so knowing that and the speed and looking at the line widths you can figure out K. You could also add a few extra lines like ruler lines to help judge the scale (near the corners of the square.

You want a large square to get up to pressure before you hit the corner.

Alternatively (maybe simpler?) you coulddo a 10mm/sec line and then go around a 90 degree corner and do the second line at 50mm/sec. With that huge speedup you should see thinning of the line at the corner just like the previous pattern would have thickening at the corners due to slow down.

Anyway from a photograph of that result you could measure line widths and get a good approximation for K. Then turn on "the feature" with that K value.

Alternatively you could do several patterns with 3 different K values and have a user say which pattern looks the best at the corners (left, middle, right pattern). Then use the best K value going forward.

[lars86 42]

I like it.

[eldrick 65]

Slic3r 1.2.9 has what sounds like a calculated version of this. I haven't tried any tests of precision, but on a test print it gave me the least-noticeable divots and blivets (pocks and blots) I've seen on the UM2.

Edited August 25, 2015 by Guest

[lars86 42]

I tried that the other day. What K value did you use?

Watching the motion of the extruder, it looks to be trying to prime / deprime the extruder pressure. I had good results in some areas of my print, but other areas didn't get filled at all. Not sure if it was an anomaly or the pressure advance function, or those fast extruder moves causing skipped steps.