Faster speeds
- This topic has 16 replies, 2 voices, and was last updated 6 years, 5 months ago by .
-
Posts
-
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 quicklyIn 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.
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.
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.
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?
https://www.thingiverse.com/thing:2961400
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.
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?
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.
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?retweeted!
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.
- You must be logged in to reply to this topic.
