New algorithm Velocity Extruding for more smooth print

[avaradus]

Request support new algorithm in Marlin. Extruding without the E or A axis. The velocity of the extruder is linked with the velocity of the nozzle. Width of the line (perimeter/infill) and height of the layer are set from the g-codes, and calculate the correct cross section to be extruded.

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

[bkubicek]

I invented this algorithm, and would have implemented this 3 years ago, if I saw a chance to do this.

Bernhard

On Tue, May 13, 2014 at 7:21 AM, avaradus notifications@github.com wrote:

Request support new algorithm in Marlin. Extruding without the E or A axis. The velocity of the extruder is linked with the velocity of the nozzle. Width of the line (perimeter/infill) and height of the layer are set from the g-codes, and calculate the correct cross section to be extruded.

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

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/916 .

[bkubicek]

reference can be found: http://kariert.org/advanceV2.pdf and http://bernhardkubicek.soup.io/post/425547834/My-anti-oozing-algorithm-was-implemented-using and here http://bernhardkubicek.soup.io/post/168776124/Another-acceleration-extrusion-compensation-for-repraps

Bernhard

On Tue, May 13, 2014 at 8:02 AM, Bernhard Kubicek < bernhard.kubicek@gmail.com> wrote:

I invented this algorithm, and would have implemented this 3 years ago, if I saw a chance to do this.

Bernhard

On Tue, May 13, 2014 at 7:21 AM, avaradus notifications@github.comwrote:

Request support new algorithm in Marlin. Extruding without the E or A axis. The velocity of the extruder is linked with the velocity of the nozzle. Width of the line (perimeter/infill) and height of the layer are set from the g-codes, and calculate the correct cross section to be extruded.

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

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/916 .

[bkubicek]

and in between there was the trouble with the sailfish Makerbot/WeSueCompetitorsAndPatentStuffWeDidNotInvent firmware, who claimed to have implemented this, but I personaly failed to find this in their (finally published) sourcecode.

Bernhard

On Tue, May 13, 2014 at 8:11 AM, Bernhard Kubicek < bernhard.kubicek@gmail.com> wrote:

reference can be found: http://kariert.org/advanceV2.pdf and

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

http://bernhardkubicek.soup.io/post/168776124/Another-acceleration-extrusion-compensation-for-repraps

Bernhard

On Tue, May 13, 2014 at 8:02 AM, Bernhard Kubicek < bernhard.kubicek@gmail.com> wrote:

I invented this algorithm, and would have implemented this 3 years ago, if I saw a chance to do this.

Bernhard

On Tue, May 13, 2014 at 7:21 AM, avaradus notifications@github.comwrote:

Request support new algorithm in Marlin. Extruding without the E or A axis. The velocity of the extruder is linked with the velocity of the nozzle. Width of the line (perimeter/infill) and height of the layer are set from the g-codes, and calculate the correct cross section to be extruded.

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

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/916 .

[whosawhatsis]

This post talks about two completely different things.

The first is a method of controlling extrusion volume based on cross-sectional area multiplied by feedrate rather than sending pre-calculated volumes to the gcode interpreter, which might be a good idea, but it won't affect print quality. All the same math, you're just changing where the separation is between what is calculated in the slicer and what is calculated in the gcode interpreter.

The second, completely independent thing is the addition of an advance algorithm which attempts to reduce blobbing by pre-emptively equalizing nozzle pressure. Marlin has had one of these for years (ADVANCE), and there's currently a pull request pending to add one to Slic3r as well. "Velocity Extruding" is not necessary for this.

[bkubicek]

i can't find the pull request, do you know which it is? https://github.com/alexrj/Slic3r/pulls My method cannot be implemented in anything that sends standard gcode, because it requires asynchronous moves. So it would be quite surprising if it could be put into the slicer.

Bernhard

On Tue, May 13, 2014 at 8:30 AM, whosawhatsis notifications@github.comwrote:

This post talks about two completely different things.

The first is a method of controlling extrusion volume based on cross-sectional area multiplied by feedrate rather than sending pre-calculated volumes to the gcode interpreter, which might be a good idea, but it won't affect print quality. All the same math, you're just changing where the separation is between what is calculated in the slicer and what is calculated in the gcode interpreter.

The second, completely independent thing is the addition of an advance algorithm which attempts to reduce blobbing by pre-emptively equalizing nozzle pressure. Marlin has had once of these for years, and there's currently a pull request pending to add one to Slic3r as well. "Velocity Extruding" is not necessary for this.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/916#issuecomment-42921621 .

[avaradus]

Realisation of this method possible only in firmware. Only firmware know real speed movement in acceleration/deceleration sections. Slicer software nothing know where acceleration/deceleration sections and calculates wrong extrusion volume on corners and start/stop perimeter.

[whosawhatsis]

https://github.com/alexrj/Slic3r/pull/2018

By breaking a segment into multiple segments, it should be possible to at least approximate the effect in a way that is "better than nothing". I believe what's being proposed is to change the extrusion rate a number of millimeters before where it is supposed to change (due to a feedrate and/or extrusion width change), with that number of millimeters being determined by the magnitude of the difference between the two extrusion speeds.

I agree, though, that this type of thing is better handled after acceleration is calculated than before. Anyway, my point was simply that converting to "velocity extrusion" is not required to implement something like this.

[avaradus]

Slicer is very buggy program and in new versions addind more bugs. Other slicers, kiss, cura, skeinforge will not make any changes. =( But Sailfish firmware made this algorithm and makerbot have very good prints.

Author in link http://basdebruijn.com/2014/05/machinekit-and-additive-manufacturing/ made this and too have very good result!

And old ADVANCE algorithm Matthew Roberts is too not work in Marlin why? Errors after forked port from sprinter?

[ErikZalm]

Sailfish made a mix between Berhards algorithm. They also did some other strange things that seems to work on a Makerbot. As far as I can tell the algorithm in the link is comparable to Bernhards algorithm.

The Matthew Roberts algorithm is not working because nobody uses it. I had it working on my first printer. It worked perfectly. But it did not work with all extruders. If I have much more free time I can look at the code.

And Marlin only copied the g-code part from sprinter. Sprinter copied the motion part from Marlin. (And many other parts)

[nothinman]

I actually used to use advance, but its rapid movements were destroying my gears quickly. Not so much the teeth, but the grub screw would quickly destroy the bore...

[avaradus]

To: nothinman What version of marlin you use ? For me in latest version advance is not worked. =( after i enable this option in configuration then extruder motor no rotated and nothing extruded.

[nothinman]

@avaradus I don't use advance any more. I think I used it for the last time nearly a year ago... yes, I heard it's broken :( But frankly, with proper calibration the gain was rather insignificant.

[Lenbok]

I don't understand why people are looking at addressing this in the slicer (e.g. alexrj/Slic3r#2018 and alexrj/Slic3r#1203 which knows nothing about the acceleration settings of the printer) rather than getting proper "advance" fixed in the firmware itself.

[llluis]

@Lenbok I always used the advance in firmware in my previous cartesian non-bowden printer, as I had good improvements, mainly during infill. However, when switched to a delta bowden printer, I was never able to make it work as it should. Also, as others pointed out, its implementation is broken in the last versions. I really don't know how people use a bowden system with different speeds and without some sort of advance!

You are correct, the best / right place to do this is in the firmware, however, I've tried to look at the advance implementation and, with the time I had, wasn't able to fully understand / debug / correct it. Then, I tried new ways of resolving my problem and started looking into the Slic3r. With little effort, I was able to put a version together which improved drastically my prints, using 30mm/s perimeter and 100mm/s infill.

I've been using this modified slicer with success since then and wanted to share my effort with others, as it could help them also (and help me improve/correct the "feature"). It seemed the case as other people are using my branch and reporting improvements in their prints. It's true that the slicer doesn't know nothing about acceleration, but printers with a bowden typically uses high acceleration, minimizing its impact.

I'm available to help implement / correct / test this in the firmware but I need guidance.

[glx51mm]

Any updates on this one? This is the most important feature for getting high speed - high quality prints. Seems strange it doesn't get much attention.

[nophead]

Well for one thing the name is wrong. The speed of the extruder is already linked to the velocity of the nozzle since all axes accelerate together.

[glx51mm]

I have no reason to argue with what you say but when setting low accelerations on a Marlin powered printer, the extrusion is not smooth. More material than normal (full speed) is accumulated during acceleration/deceleration. Am I missing something?

[nophead]

Exactly the right volume is extruded, it is just in the wrong place because of the lag in the extruder. As it decelerates at the end of the line the flow rate of the plastic doesn't decelerate as fast, so you get too much. As it accelerates away you get too little. The number of E steps is exactly right though, and in step with the axes, so the total plastic volume is correct. The issue is it shouldn't be in step with the axes, it should be advanced.

[glx51mm]

That makes sense. So considering this, the best prints you can have by using as high acceleration/jerk values as possible while keeping the speed constant. Of course this is limited by the printer mechanical construction but this in theory should give the best results. The lag should also be reduced by extruding in as low temp as possible.

[nophead]

Yes high acceleration and lower speeds give better prints. I find a little over extrusion at the end of zig zag infill but that helps it bind to the perimeter.

I think actually higher temperature is better for reducing lag as the plastic is then less viscous, so the pressure is less, so it compresses less.

[alexborro]

What about fixing the advance algorithm? I have heard Jetty Firmware has a great one.

Cheers.

Alex. Em 12/01/2015 09:53, "Chris" notifications@github.com escreveu:

Yes high acceleration and lower speeds give better prints. I find a little over extrusion at the end of zig zag infill but that helps it bind to the perimeter.

I think actually higher temperature is better for reducing lag as the plastic is then less viscous, so the pressure is less, so it compresses less.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/916#issuecomment-69559521 .

[boelle]

How many still have an interest in this one? is what we have not good enough? and how much can be gained held against the work it will require?

[thinkyhead]

I think we need more charts and graphs to go forward on this one. I like to learn (for example) that high acceleration and low speeds give better quality. But also I would like to know optimal acceleration for mid-to-high speeds also. If nothing else, we can produce some better documentation on tuning the acceleration and jerk settings.

[boelle]

i'm tempted to close this one as not have happened for the better part of 6 months... no one seems to have active interest

[brainscan]

I have an interest but unfortunately lack the ability to help move this forward. I've been trying to look into the various methods others have worked on but I'm a long way off being able to implement something.

Maybe it's something to keep for the future, the developers have a lot on their plate at the moment from the looks of things.

On 31 May 2015, at 14:35, Bo Herrmannsen notifications@github.com wrote:

i'm tempted to close this one as not have happened for the better part of 6 months... no one seems to have active interest

— Reply to this email directly or view it on GitHub.

[boelle]

there are a lot on the plate yes.... and we cant please all...

[boelle]

@bkubicek any chance we can see a PR in the near future that implements this one?

[thinkyhead]

Fingers crossed. The other firmware I looked at uses an additional timer interrupt to implement this feature. We would probably have to do it in the same interrupt used for stepper movement.

[CCS86]

I agree with @whosawhatsis

"By breaking a segment into multiple segments, it should be possible to at least approximate the effect in a way that is "better than nothing". I believe what's being proposed is to change the extrusion rate a number of millimeters before where it is supposed to change (due to a feedrate and/or extrusion width change), with that number of millimeters being determined by the magnitude of the difference between the two extrusion speeds.

I agree, though, that this type of thing is better handled after acceleration is calculated than before. Anyway, my point was simply that converting to "velocity extrusion" is not required to implement something like this."

Firmware implementation would be the best realization of accounting for the drive spring/lag effect, but take the most effort.

On the slicer side, you could introduce a tunable "lag" parameter to decouple extruder drive moves from print head moves, in a preemptive way.

[thinkyhead]

@CCS86 Among slicers, Skeinforge has the ability to both stop extrusion early (to allow built-up pressure to finish a line) and to start extrusion early (to build up a little pressure). I'm not aware of any other slicers having this feature.

[CONSULitAS]

@thinkyhead There is experimental support in Slic3r since 1.2.2 (http://slic3r.org/releases/1.2.2, New experimental feature for Pressure Management based on the advance algorithm (#1203 #1677 #2018)). Recent release is 1.2.9.

But I had no time to test it, because i am far to far away from my printer. :-)

[CCS86]

@thinkyhead & @CONSULitAS

Thanks for the info guys. I'm interested to check it out.

[Nandox7]

Isn't that what the Advance Extrusion settings in the Configuration_adv.h tries to address?

[CCS86]

@Nandox7

I believe so, but from what I've read, it is broken in later versions of Marlin. I haven't tested yet.

[Nandox7]

I did some tests with it but results weren't that good. The fact you can't change the params in eeprom didn't help and I ended postponing further testing.

I was also looking into the full implementation present in the sailfish fw and how to port it to Marlin. But lack of time didn't help on that task.

[thinkyhead]

Please test the built-in ADVANCE when you get a chance. It hasn't changed (much) in a long while. I would be interested to know what state it's in.

[CCS86]

It would be great to vary the coefficient via G code, to enable fast testing iterations.

On Mon, Jul 27, 2015, 5:29 PM Scott Lahteine notifications@github.com wrote:

Please test the built-in ADVANCE when you get a chance. It hasn't changed (much) in a long while. I would be interested to know what state it's in.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/916#issuecomment-125366597 .

[thinkyhead]

@CCS86 Are you referring to the value set by EXTRUDER_ADVANCE_K which is 0.0 by default?

[CCS86]

@thinkyhead Yes, I was.

[Nandox7]

Started looking into this. I could be wrong but the ADVANCE code is not used, all the calculations are made but it is not actually applied. I continuously increase the value of K and there is no visible effect. Also in the planner and stepper code it doesn't seem to be put into use.

[thinkyhead]

@Nandox7 You can try un-commenting these lines in plan_buffer_line to see if anything is happening…

/*
SERIAL_ECHO_START;
SERIAL_ECHOPGM("advance :");
SERIAL_ECHO(block->advance/256.0);
SERIAL_ECHOPGM("advance rate :");
SERIAL_ECHOLN(block->advance_rate/256.0);
*/

[Nandox7]

@thinkyhead I did that and I can see the values it generates.

Thing is in the planner.cpp those values aren't used in any way. The other place I see them kinda been used is in stepper.cpp.

#ifdef ADVANCE
  unsigned char old_OCR0A;
  // Timer interrupt for E. e_steps is set in the main routine;
  // Timer 0 is shared with millies
  ISR(TIMER0_COMPA_vect)
  {
    old_OCR0A += 52; // ~10kHz interrupt (250000 / 26 = 9615kHz)
    OCR0A = old_OCR0A;
    // Set E direction (Depends on E direction + advance)
    for(unsigned char i=0; i<4;i++) {
      if (e_steps[0] != 0) {
        E0_STEP_WRITE(INVERT_E_STEP_PIN);
        if (e_steps[0] < 0) {
          E0_DIR_WRITE(INVERT_E0_DIR);
          e_steps[0]++;
          E0_STEP_WRITE(!INVERT_E_STEP_PIN);
        }
        else if (e_steps[0] > 0) {
          E0_DIR_WRITE(!INVERT_E0_DIR);
          e_steps[0]--;
          E0_STEP_WRITE(!INVERT_E_STEP_PIN);
        }
      }
 #if EXTRUDERS > 1

So a timer is set that will use the the calculated values. I'm still going over the code and understand how it works, but wouldn't be better to have the values add/subtracted to the steps of the E rather than having a timer doing it instead?

[thinkyhead]

@Nandox7 Dang, you are correct. It looks like most of the pieces are in place, but not quite all together. I will need to look at some other firmwares' advance handling and see where they create and apply these values.

Then there's code like this:

for(int8_t i=0; i < step_loops; i++) {
  advance += advance_rate;
}

…which seems like it could just be:

advance += advance_rate * step_loops;

[CCS86]

Awesome, keep us posted Scott!

On Fri, Jul 31, 2015 at 4:48 PM Scott Lahteine notifications@github.com wrote:

@Nandox7 https://github.com/Nandox7 Dang, you are correct. It looks like most of the pieces are in place, but not quite all together. I will need to look at some other firmwares' advance handling and see where they create and apply these values.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/916#issuecomment-126821080 .

[thinkyhead]

Looking particularly at Sailfish, which seems to have this down very well.

[CCS86]

Too bad Makerbot is a turd of a company. They seem to have some good minds over there.

On Fri, Jul 31, 2015 at 4:52 PM Scott Lahteine notifications@github.com wrote:

Looking particularly at Sailfish http://www.makerbot.com/sailfish/tuning#5, which seems to have this down very well.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/916#issuecomment-126821718 .

[Nandox7]

@thinkyhead yeah they do. I was looking at their implementation here. https://github.com/jetty840/Sailfish-MightyBoardFirmware (JKN_ADVANCE) As it seems up-to-date in terms of code updates.

There is also a much older implementation that seems to be the one where these originated from by Matt Roberts (http://reprap.org/wiki/Mattroberts'_Firmware).

In overall I spotted a few other things that look like it can be improved likes STEPS_MM_E that are already defined in the FW.

[Lenbok]

@CCS86 @Nandox7 Don't give any of the credit to Makerbot for that -- it's due to the hard work of @dcnewman and @jetty840 who have a fantastic focus on quality and getting the little details right (rather than the Makerbot "Done Manifesto" approach)

[CCS86]

@thinkyhead, have you dug any deeper on this?

Thanks

[thinkyhead]

@CCS86 After we get this release done I want to get into this more. For now just consider this feature not-implemented. Let's close this here and start a new topic on the MarlinDev issue queue, where we can be more developer-centric.