Unchangeable extrusion speed when "Advance" enabled


I have encountered the following phenomenon with both of the latest Repetier FW versions (0.91 Rev.8 and 0.92):

I have recently switched from Azteeg X3 Pro board (ATMEGA 2560) to a RADDS board (ARM). The firmware is running nicely, except a scenario where the advance algorithm is enabled. Whenever I set the linear advance factor in EEPROM to any value other than 0 (i tested from 0.001 to 100), the extrusion speed is always the same. In other words, there is no difference between slow and fast extrusion from the Repetier Host - both buttons produce the same (slow) extrusion rate. However, when advance_l =0, the buttons DO produce different extrusion rates just as it should (in my case 2mm/s and 10mm/s). This is quite annoying, since e.g. the infill is severely underextruded which is usually printed at higher speeds.

Any ideas what could this be?

Thanks for help!


  • Anyone?
  • With advance extrusion is handled by a separate interrupt. This used to run at 10-15KHz. I need to check the code.

    With RADDS you are maybe using 1/128 stepper requiring many steps for extrusion. So if extruder interrupt is still 15KHz it might be not enough for the speed. Or setting of frequency fails for radds using a wrong prescaler. I need to check that and it is not easy.
  • I am indeed using RAPS128 stepper drivers with a 1.8deg stepper motor in direct drive. However, I have installed the stepper drivers in a 1/64 uStepping mode - this yields around 550 steps per mm in my extruder. The rest of the machine (XYZ) is driven in a 1/128 mode.

    It would be magical if you could check the code! Thanks!
  • The whole advance stuff was not adjusted to ARM timings. The extruder was running with 244Hz while even the Mega did 16000Hz. So no wonder why it makes no difference.

    I have adjusted the timings and it now runs around 60000Hz or faster if required. That should make advance work even with higher stepper frequencies. After all we are using the due to be able to do so.

    In my logic analyser it worked, but I have no hardware currently to test advance. All bowden setups. So feedback if it is now solved would be appreciated. Only 0.92 was updated!
  • Many thanks for the quick response!
    I will download the updated version and report back if the problem was solved.
  • edited July 2015


    Here are some interesting results I observed using the latest update of Repetier FW (0.92.3).

    I measured the step and direction signals of the extruder using my logic analyzer and here are the results. In particular, I looked at how the signals look during the deceleration; in this test I printed single line at 80mm/s and then slowed down to 40mm/s over a single straight path. Here is the GCODE of the test (pre-amble commands for heating, homing, etc. omitted here):
    ; Move to start
    G1 X210 Y210 Z3.8
    ; extrude L1_1
    G1 X210 Y190 E0.732 F2400
    ; extrude L2_1
    G1 X210 Y110 E3.659 F4800
    ; extrude L1_2
    G1 X210 Y90 E4.391 F2400

    Now here are the results with and without advance algorithm enabled:

    1) WITHOUT advance algorithm (advance linear = 0):
    (Figure 1).

    The path planner does not seem to be working as intended. The extrusion slows down towards the point of the speed change where the speed is then the smallest and then accelerates to the speed of the second segment (40mm/s). I believe that there should be no phase where the extrusion is accelerating. The XY-movement is along a straight line!

    2) WITH advance algorithm (advance linear = 10):

    (Figure 2).

    Very weird behavior off direction and step signals. I cannot really follow what’s happening here…

    Could you elaborate on the above observations? Thanks!


  • For L=0 looks like it decelerated to far = < 40 mm/s. Would need to see y step signals to verify. But both are in the same loop so I guess the planner throttled too much for this combination. What jerk do you have set?

    L > 0: Really weird. You get direction changes if the steps needed is changing the sign and that can in deed happen. While normal move will increment the step counter pushing to positive value, the advance will go in opposite direction. So if we get +1 and it gets executed from extruder interrupt and then add -1 so we now have -1 from the advance, we have a direction change. I also increased the delay for direction changes to 500us in timer.

    So we have a new problem here with higher speeds this situation can arise and it looks like it really happens. Assuming that the error does not get higher then a low threshold of maybe 3, I could add a direction filter so that we switch direction not at 1 but at 3 and -3 steps. We will loose some steps at direction change but they will be executed later when it is clear what the real correction is. On the other side we would here only see one clear direction making it at least possible for the extruder to reverse direction and follow the speed. 

    For testing - what steps per mm in x,y and e did you use for the example.

    I will try to test it when I get the time, but currently I have some other urgent things and this is a complicated and longer test, so may take a while.
  • edited July 2015
    Hi Repetier,

    Here are my EEPROM settings relevant to movements and extrusion; these settings were used for the above tests (advance factor was set to either 0 or 10 depending on the test). High values for step p. mm for the Z- and E-axis are due to the fact that I have 0.9deg steppers implemented for these axes. I am using a CoreXY drive system.

    <?xml version="1.0" encoding="utf-8"?>
        <epr pos="75" type="2" value="250000">Baudrate</epr>
        <epr pos="3" type="3" value="1280.0000">X-axis steps per mm</epr>
        <epr pos="7" type="3" value="1280.0000">Y-axis steps per mm</epr>
        <epr pos="11" type="3" value="2560.0000">Z-axis steps per mm</epr> <-- high because of the 0.9deg stepper 
        <epr pos="15" type="3" value="250.000">X-axis max. feedrate</epr>
        <epr pos="19" type="3" value="250.000">Y-axis max. feedrate</epr>
        <epr pos="23" type="3" value="10.000">Z-axis max. feedrate</epr>

        <epr pos="39" type="3" value="10.000">Max. jerk</epr>
        <epr pos="47" type="3" value="0.300">Max. Z-jerk</epr>

        <epr pos="51" type="3" value="3500.000">X-axis acceleration</epr>
        <epr pos="55" type="3" value="3500.000">Y-axis acceleration</epr>
        <epr pos="59" type="3" value="80.000">Z-axis acceleration</epr>
        <epr pos="63" type="3" value="3500.000">X-axis travel acceleration</epr>
        <epr pos="67" type="3" value="3500.000">Y-axis travel acceleration</epr>
        <epr pos="71" type="3" value="80.000">Z-axis travel acceleration</epr>
        <epr pos="880" type="0" value="1">Autolevel active (1/0)</epr>

        <epr pos="200" type="3" value="1096.000">Extr.1 steps per mm</epr> <-- high because of the 0.9deg stepper 
        <epr pos="204" type="3" value="30.000">Extr.1 max. feedrate</epr>
        <epr pos="208" type="3" value="15.000">Extr.1 start feedrate</epr>
        <epr pos="212" type="3" value="250.000">Extr.1 acceleration</epr>
        <epr pos="246" type="3" value="0.000">Extr.1 advance L</epr>

    ...the results of the stepper signals follow in the next post

  • edited July 2015
    I have performed the same tests as in the above post - and now measured the STEP and DIR signals of the XY-motors. However, XY is probably not the best way to call them since I am using CoreXY, so I named them A- and B- motors on the charts:

    1) WITHOUT advance:

    (Figure 1)

    In Figure 1 above you can observe the same behavior as noted in the previous post regarding the deceleration and acceleration of the extruder step signal. Furthermore, one can observe that the step signals of A and B motors are not distributed equidistantly. Since individual step signals of the AB-motors are not visible in the image resolution, and to recognize any patterns I plotted the duration of step-signal periods (i.e. Step_high + Step_low timing) as a function of time in Figure 2:

    (Figure 2.)

    One can see on Figure 2 that the A motor is decelerating and then accelerating – the same behavior as we observed for the extrusion. This happens despite the fact that the movement is happening along a straight line in the Y-direction…

    Please let me know if this helps and if any further tests may help!
  • and here are the results for the test where advance was enabled (advance_L = 10):

  • I have to change firmware today and will add the direction filter teshold. That shoudl solve the fast direction switches.

    The deceleration/acceleration is correct I think. When the buffer is not full, path planning can not update the running move so first moves will decelerate to what jerk allows. Then next move of course accelerates to target speed again. If you do 5-6 moves more before the test move (e.g. without extrusion so you can trigger on extrusion for the analyser) you should see the move switching to 40 from 80 without going to jerk speed.
  • Sounds wonderful, thank you! 

    I will try the get the buffer full to see how the path planner does acceleration/deceleration and get back with some results. But I guess you are right, let's see...

  • Full buffer is only 50% of the problem I found out. The current jerk computation makes from a speed change 80-40 = 40 jerk so it slows down even if buffer is full enough.

    I have today developed a new jerk alternative. So with next release you set
    in config and then it will use my new alternative jerk computation where it will only slow down to 40. I think that system is better then the old but I want more tests before making it default.

    The direction switches are also gone in my tests with filter level 2. So with next release you can do your testing and I guess with much better results. Just need to fix some more things until I can publish next update.
  • I can't wait to test the new release.

    When are you planning to release the update?

    Many thanks,
  • Hi,

    I have the same problem as described from Andi in the beginning, but with a Rumba board (ATMega 2560) and a mixing extruder (1/16 stepping mode, 312 Steps/mm). An update to the newest firmware did not bring any change, the extruder(s) are running with a maximum speed of f400. Do I have to change anything in the frequencies? That's unfortunately something I know nothing about.

    Thanks in advance,
  • The new firmware with direction filtering is now only. Filter is also added for AVR boards.

    @svake F400 is 6.66mm/s right? If you meant mm/s then the extruder interrupt is not fast enough and never will be on a avr. There it is limit to I think 16000 hz.
  • Thanks Repetier,

    yes, that is right, it's 6,66mm/s. If I don't use advance then I can go up with the feeder speed until the stepper motor falters, what happens with about 50mm/s?. I have tested this once, but forgotten. So it should be faster then 6,66mm/s, even with advance?

  • The frequency depends on max. speed so if max. speed is 6.66 andvance will not be faster. Not sure how fast it wants to get with your setup but it retracts much faster then during normal printing. So it would be better to set extruder max speed to 40. You can still use slower rates on command line but extruder interrupt will test more often.
  • Hi,

    Could you elaborate on how to use the new direction filtering in the firmware? Is there a flag or parameter that needs to be set?

    Another question: What do you recommend for #define STEP_DOUBLER_FREQUENCY ? Since I am using an ARM, this value could be higher than for the AVR, but do you maybe have a best-case value?

  • Just add


    to configuration.h that is all needed to use the alternative that works I think better. But I want some more experience with it before I make it default.

    STEP_DOUBLER_FREQUENCY for arm is 80000 - 90000. 
  • edited July 2015
    Hello Repetier,

    I have just downloaded the new firmare with the ALTERNATIVE_JERK implemented. As you suggested, I included this in the configuration.h: #define ALTERNATIVE_JERK

    However, I am observing same issues here. I performed the test again. This time, I changed microstepping for X/Y from 1/128 to 1/64 and reduced max.jerk to 10mm/s; advance disabled:

    The motion is first decelerated to a very slow speed and then accelerated to jerk speed!

    Could it be that CoreXY is "schuldig"?
  • The same test with advance_L = 10.

    Interestingly, this problem does not appear now - the X/Y motion is not decelerating during speed increase.

  • Hi,

    It's been a while, but a managed to test the firmware's advance algorithm... and it fails.

    Here's what happens:

    - If advance is enabled, the extruder driver (in my case RAPS128) fails after a few layers causing the extruder motor to stop turning resulting in a failed print.
    - If advance is DISABLED, the extruder driver works as expected.

    So there must be something weird happening which either massively overheats or somehow disturbs the driver. Note that my motor and drivers are cooled by strong fans and the current is limited to a value below the current limit of the motor.

    I hope there is a solution/explanation to this so i can move forward.

Sign In or Register to comment.