Faster speeds

Home Forum Makelangelo Polargraph Art Robot Faster speeds

Viewing 17 posts - 1 through 17 (of 17 total)
  • Author
  • #20255

    For a new project, I need to make things move faster than the speeds I get when simply changing the Feedrate and Acceleration values. Increasing those will only create jerking before reaching anything near the speeds I’m looking for (I can only go up to F5000 A4000 smoothly).

    What changes can I do to the firmware code to get faster speeds? To my best knowledge, motor.ino’s ISR(TIMER1_COMPA_vect) is where the motors are pulsed on/off. But I can’t seem to find where the delay/pause happens between each step/calculation – so I can decrease it. Because surely each step can happen faster right?

    My setup: Nema17 200steps/rev motors, Ramps1.4, ArduinoMega, running latest firmware, Zarplotter mode (4 motors)


    When you say “jerking” what do you mean? when i hear “jerk” I think of speed is affected by acceleration is affected by jerk is affected by snap, etc.

    What speed are you trying to reach?

    The two most obvious limits to top speed are

    * the physical limits of the hardware – improved by reducing mass, increasing torque, etc
    * the clock speed of the brain – improved by getting a faster brain to step motors more quickly

    In zarplotter.h there is a MAX_FEEDRATE, MAX_ACCELERATION, and MAX_JERK. These can all be raised.

    I want to hear more about your experiments so that they can be shared with everyone.


    With “jerking” I mean the motors seem to jump and struggle as they move. Almost as if they take one step back for every two steps forward.

    I’m looking to move ~0.5m/s.

    MAX_FEEDRATE & MAX_ACCELERATION: you change this with Gcode right? G0 F5000 A4000? That’s what I’ve done and the “jerking” hinders me to go above F5000 & A4000.

    What is MAX_JERK?

    My project is to use the 4 motors to stretch a piece of stretchable cloth into different geometrical shapes (using the jog feature on each motor, which btw can be sped up just fine by altering pause() in Makelangelo-firmware.ino), and then moving that shape around the 2D space (here is where I need much faster speeds). Happy to post pics when I start to get somewhere.

    What do you think I can do?


    500mm/s is crazy fast. I mean, that would be hard for ANY cnc machine.

    For feed rate (speed) and acceleration there is the default, the maximum, and the current value. MAX_FEEDRATE and MAX_ACCELERATION are the maximum. you cannot change the current value above the maximum. default is the starting value when the machine is turned on. So YES, you can change the current value with that gcode. if you want to go higher you will have to change the value for MAX_(whatever) and then upload the code to the robot.

    Acceleration is change in velocity. Jerk is change in acceleration. max jerk is the limit on acceleration changes.

    I think you’ll find that even if you change the pause() you cannot get 500mm/s. Currently at 5000 steps each step takes ~200us to calculate. The stepper motors would have to turn over 600 RPM, or 40000 microsteps per second AT FULL SPEED, not including acceleration and deceleration delay. That would require a minimum clock speed of 40 microseconds per step. So… the RUMBA board would have to be >5x faster clock to do what you want OR the code would have to be vastly more efficient OR the microstepping would have to be turned off, creating a less accurate but faster moving machine.


    Thanks for clarifying. I think I’ll start with trying to remove microstepping, as I might accept some accuracy loss. Another thing might be using bigger spools?

    But when it comes to the code, you mean there is *nothing* I can change other than MAX_FEEDRATE etc to get faster speeds? There is no added delay/pause anywhere, like the Jogging feature has?

    Increasing MAX_FEEDRATE won’t help I’m afraid, since the “jerking” starts way before I reach the levels already in there. What can this jerking be btw? The motors can run much faster under the same load manually with my own code. Could it be my Arduino Mega or Ramps board that are slower than your Rumba? You seem to be able to go much faster than me.


    it’s hard to say. increasing spool size will increase the amount of torque required to turn the spool, which could make the steppers miss steps. like… if it is trying to make a step but is not finished by the time the next step begins… oops.

    the code works by using an Interrupt Service Routine (ISR). basically… I use one of the chip clocks and say “every nth tick run this routine”. the routine is optimized to be as fast as i can make it, so that it can make the step commands as fast as possible. if the ISR is not done by the next clock tick then the ISR … trips over it’s own feet, metaphorically. unpredictable things happen. that is also why you don’t see pause() or delay() in there. the ISR speed is adjusted to control the delay between steps. I have pushed it to about F8000 with success, but the drawing accuracy is very very low and the belts start to skip on the pulleys.

    A RUMBA board should be running at the same speed as a Mega. I like to think of the RUMBA as a Mega and a Ramps on a single PCB.


    Ok so I tried changing microstepping (in both HW and SW) to 1/4 and 1/1 without any significant speed increase. The “jerking” keeps starting around >F5000. In fact it the jerking seem to change even earlier with 1/1 than 1/16. Interesting.
    Now I’m wondering if it could be the current limit setting of my A4988 drivers. I have not changed them at all, maybe they are set too low or something and wont give enough current required at higher speeds? I haven’t really understood what changing the current limit *actually means* lol.

    Regarding the code, you mean one can only adjust the ISR speed by changing the FEEDRATE value?
    These things in configure.h shouldn’t be tampered with I presume? 🙂
    #define CLOCK_FREQ (16000000L)
    #define MAX_COUNTER (65536L)
    #define MAX_SEGMENTS (32) // number of line segments to buffer ahead. must be a power of two.

    One more thing, say you’ve pushed to F8000 – did you also notice if the motors themselves seem to “jerk”/jump at these speeds? (irrespective of belt skipping)


    I’m glad you changed microstepping correctly. Probably bigger steps means you’ll need lower acceleration.

    current limiting prevents the motors from getting hot. too hot they could be damaged. Too low and there isn’t enough power to make successful steps.

    The only way to change the ISR speed while the robot is running is by sending gcode commands with Fnnn where nnn is a new feed rate. nnn is capped 0…MAX_FEEDRATE.

    Correct, do not tamper with those #defines.

    Do you have plain rollerstake bearings?


    Print the Leg and the Outer Ring files. Put a plain 8x22x7 bearing on the leg, put the outer ring on the bearing, and then screw the leg onto the stepper. the outer ring should press the timing belt against a GT2-20 pulley and prevent skipping, which might allow faster acceleration without skipping.


    Thanks, but my problem was not skipping of belt, because I am not using pulleys and timing belts (I use spools – there are pros and cons but I’m happy with it for now). My problem was that the motor shaft itself was jerking/skipping when commanded >F5000.

    I increased the current limit on my A4988’s up to the max rating of my steppers (1.3A/phase). This helped a lot, so insufficient current was probably the main reason for my motors jerking/skipping. I can now run F8000 smoothley, almost F10000 with some steps being skipped.

    Another current-related thing that might hinder me going even faster is that my power supply only outputs 6A @12V. With my 4 steppers @ 1.3A/phase, won’t I need 4 x 1.3 x2 = 10.4A power supply?

    I also read somewhere that increasing the input voltage from 12V (to max 18V?) “generally allows for higher step rates and stepping torque”.


    Good to know.

    spools were abandoned early because the diameter changes as the material winds/unwinds. It maybe causing some of the accuracy problems you are seeing.

    IIRC only one phase is active at a time. don’t forget to leave room for the power needed by the board/shield.

    I would first check if the RUMBA or RAMPS shield can run at >12v. I believe the answer is No.

    Can I see a pic of your setup?


    Some progress: now with enough current given to the motors, I see that also lower levels of microstepping and full stepping work better. Things do now go faster, but you also need to lower the F-speed in order not to go too fast and skip steps. At the end of the day, there is only a slight increase in speed, and unfortunatly not enough to satisfy me.

    **CONCLUSIONS** for anyone reading this in the future with motors that skip steps when trying to go faster: make sure you are providing enough current by setting the current limit on your driver (e.g. A4988) to the rated current of your motor. And don’t worry about your power supply not delivering enough current; it (usually) supplies 12V which is higher than your motor’s voltages (~2-3V), so it don’t need to output as much current as they are rated to. A 12V supply with 5A is enough in most cases.

    Regarding spools, I found that they, when tensioned, actually automatically let the cord place itself uniformely on the spool. And if the cord is thin enough and spool diameter is big enough, even if there’s a layer of winding on top of another, the accuracy does not get measurably worse. I’ll place a pic or video of my setup here during the weekend.

    >>>New question: can I somehow send Gcode commands within the Firmware, or must I use the serial input? I’m writing new code that will generate position commands and I want to feed that to your Makelangelo firmware to react upon.


    from within the code you could call lineSafe(float *pos, float new_feed_rate)

    pos is an array NUM_AXIES long (3 for x,y, and z servo on most drawing robots)
    new_feed_rate is speed of this line segment.
    Up to 32 segments can be buffered ahead for speed optimizations.


    This was running at F14000 with full microstepping and A1500. I think the problem here is that it takes too long to serial transmit the commands and the buffer runs empty. From the SD card it would be many many times faster and create a smoother image.


    Regarding commanding within the code: thanks, lineSafe() worked just fine! I am trying to find an equivalent for jogging the motors. I see that the variable “amount” is responsible, but amount = parseNumber(MotorNames[i], 0), and afaik “MotorNames” is not a step amount but only the letter assigned to the motors (L,R,U,V..)? How do I command jogging from within the code?

    Regarding speeds: so you think the serial transmit is what is preventing even faster speeds? So using lineSafe() within the code should help?
    Also, have you tried raising the Acceleration? For me it works smoother when I raise it to the same as feedrate, and sometimes even higher. On the other hand, changing MAX_JERK didnt do much for me.

    As promised, here are some videos of my setup (it’s still being improved):
    2) CLOSE-UP
    3) THE NEW PROJECT THAT NEEDS FASTER SPEEDS (Strechable canvas, soon audio-reactive)


    jerk only matters when the machine is changing direction. full stops don’t matter to jerk.

    motor_onestep(int motor) ? it steps once in the current direction.
    It doesn’t seem there was a need to say “step motor A for B steps in direction C” any time in the recent past. Is that what you’re looking for?



    Also YES, sometimes serial is a bottle neck. if the lines being draw are short enough and the transmit speed is slow enough the lines-to-draw buffer runs empty. this would cause a lot of jitter as the machine is starting and stopping in a way that feels unnecessary.

    for stepping yourself, you could directly

    digitalWrite(motors[i].dir_pin, x); // where x is direction and i is motor number

    for (j = 0; j < amount; ++j) { digitalWrite(motors[i].step_pin, HIGH); digitalWrite(motors[i].step_pin, LOW); pause(step_delay); } for amount number of steps.

Viewing 17 posts - 1 through 17 (of 17 total)
  • You must be logged in to reply to this topic.