XY axis speed coupled to E axis/extrusion volume?

Printer slows down with increasing extrusion volume. (Extrusion multiplier is set to 100%)
Is there a way to change the amount of slowdown or deactivate it completely,
even when risiking that the extruder/hotend can't keep up?
Prioritize XY over E axis so to speak.

Comments

  • There is no volume dependent slowdown. You might have a slowdown based on z position depending on this setting:
    /** If you print on a moving bed, it can become more shaky the higher and bigger
    your print gets. Therefore it might be helpfull to reduce acceleration with
    increasing print height. You can define here how acceleration should change.
    You set ACCELERATION_FACTOR_TOP to the factor in percent for the top position
    of your printer. Acceleration will then be modified linear over height.
    INTERPOLATE_ACCELERATION_WITH_Z sets, which accelerations get changed:
    0 = do not interpolate at all
    1 = interpolate x and y acceleration
    2 = interpolate z acceleration
    3 = interpolate x,y and z acceleration
    */
    #define INTERPOLATE_ACCELERATION_WITH_Z 0
    #define ACCELERATION_FACTOR_TOP 100

    Only other limit is extrusion speed when you need to move faster then max. e speed.

  • edited June 2021
    Slowdown happens when starting on layer 0, so no INTERPOLATE_ACCELERATION_WITH_Z.

    I can see the printer move faster when i adjust the extrusion multiplier (not speed! multiplier) on the LCD, so I thought they were somehow coupled.
    I tested with equally long segments that are on the same line and only have different E-Values. 
    Segments with low E-value move faster. All for the same feedrate. (though it looks like the 'velocity painting' technique, constant de- and increase of speed)
    Here is a quick video printing a cube, each wall has 1mm segments with different E-values.


    Extruder speed is 50mm/s, so plenty enough.
    Can really small E values be a problem?
    Or what happens if E=0.0?

    Hm, anything else I could check?



  • Is this repetier firmware? Looks like a rotating table and we have no support for rotating tables at least in the official version. 
    Does the side have multiple segments where speed changes all over? Maybe a problem in the polar conversion, bus since I did not write that code hard to say.


  • edited June 2021
    It's Repetier 1.0.4 dev, configured as cartesian.
    Conversion to radians happens in postprocessing.
    Yes, the sides are segmented, but their are no differing feedrates commands.
    Adjusting the flowrate multiplier via LCD changes the XY speed?! Low flowrate = higher XY speed.
    Hope you can see.


  • Ok, i guess the postprocessor solution is the problem here. When you handle the printer as cartesian it computes accelerations and limits due to cartesian constraints and not in your coordinate system.
    You should use a solution like we did for deltas where we compute and check in regular coordinate system and only afterwords use the transformed coordinates in firmware. In v2 firmware this could be done very easily by just adding a new printer type (copy from closest existing) and change the transformation and homing handling. Thus putting transformation inside firmware - benefit is that it van be handled like any normal printer. Make coordinare system a circle with zero in 0,0 and our server can even display bed correctly.
Sign In or Register to comment.