Speed multipier vs. max feedrate

Hi,

not shure if it ´s a bug or not.

if i Change printspeed by host or ui i can set Speeds higher than max feedrate of machine.

should´t that be prevented by Firmware?

not shure where to prevent from exceeding Limits in Firmware , but from my Point of view it should not be possible

to exceed max.feedrate

Comments

  • It is ok to have feedrate set higher which happens with this, but in

    void PrintLine::calculateMove(float axisDistanceMM[], uint8_t pathOptimize, fast8_t drivingAxis) {

    the maximum per axis speeds are enforced. See e.g.


        if(isXMove()) {

            axisInterval[X_AXIS] = axisDistanceMM[X_AXIS] * toTicks / (Printer::maxFeedrate[X_AXIS]); // mm*ticks/s/(mm/s*steps) = ticks/step

    #if !NONLINEAR_SYSTEM || defined(FAST_COREXYZ)

            limitInterval = RMath::max(axisInterval[X_AXIS], limitInterval);

    #endif

        } else axisInterval[X_AXIS] = 0;

    The delta case comes later.

    So what case do you have and why do you think that it is ignored?

  • edited January 2018

    just building my first corexy.

    f.e.  my kinematics can move up to 600mm/s at acceleration of 12000 mm/s2

    max feedrate in Firmware is limited to 500mm/s for x and y

    so i just generated a gcode like the following and use it as script in repetier host Manual control

    G0 X0 Y0 F30000

    G0 X250 Y250

    G0 X0

    G0 Y0

    and so on..

    with Speed 100%  everything moves as expected, reducing Speed also works as expected.

    but when increasing to 115 %  via Speed slider in repetier host it still increases Speed  although from my understanding it should be limited to the 500mm/s instead of going up to 575mm/s




  • Not exactly. Second move is a diagonal and limits are per axis.
  • edited January 2018
    ok, i understand.
    So on a 45 degree diagonal move limit is  feedrate * sqrt2  (that´s also what test showed)
  • Yes, exactly.
Sign In or Register to comment.