Maximum motor axis speed
After hitting the limit on stepping rate yesterday using five bar scara kinematics I wonder who is responsible for limiting the motor speed?
The kinematics class has a method LimitSpeedAndAcceleration() that hint that the kinematics has some responsibility to not drive the motors or other mechanics too hard. It has a very rudimentary implementation in 5-bar, probably stolen from some cartesian kinematics.
Is there no lower level mechanics to limit how fast each motor-axis is run?
I have noted that fast-moves takes the straight line path in motor dimensions, the speed of those moves must be limited somehow.
Danal last edited by
In a G-Code controller, any move involving more that one axis (on a single G1 command) must exhibit "coordinated linear motion" such that all axis arrive at the designated endpoint at the same instant in time. This includes accel (if any), steady state speed (if any), and deccel (if any) being continuously coordinated throughout the move.
That in no way answers your question, it just defers it to the "fastest" axis in any given move. I mention this so you can think about five bar motion, and ponder which axes are being delayed properly to coordinate, and which one axis (only one) is the limitation on the move.
I noticed in your other post that you were using x256 microstepping and dropped to x128. x16 with interpolation to x256 would likely resolve any step rate limitations. It's not uncommon for an axis with a high steps per mm, or in your case a high rotation speed, or combination thereof, to exceed the limit.
@Phaedrux I need the high interpolation to get reasonable resolution. The problem is that the steps/mm varies a lot depending where in the build area you are. Typically you get very high resolution, and high step speed needed, when you are close to the towers. My profile picture is actually a resolution map of a five bar.
Looking around in the firmware code I can see that the polar kinematics has indeed implemented a speed/accel limit for the rotating bed motor. It has a similar, or even worse, problem near the center of the bed.
The scara kinematics has not implemented it properly either. It's not only us 5-bar'ers that cheat
In practice it is fairly easy to avoid these problem by staying away from the problematic areas.
Ah I understand now, thanks.
I need the high interpolation to get reasonable resolution
Using x256 microstepping won't give you higher resolution, because the incremental torque per microstep will be too low to overcome friction. Typically, microstepping up to x16 helps with resolution. but higher than that doesn't.
OTOH if you are using 1.8deg motors, changing to 0.9deg motors with similar torque should double the resolution.
@dc42 I actually see a quality improvement when going higher than 16 microstepping. Printed flat areas have less visible stepper noise in them. I have a Maestro with the TMC2224 drivers.
I already use 0.9 steppers. Gearing is a challenge for arm-based 3D printers.
What does x32 microstepping look like?
Did a test print with 32 microstepping. The 32 looks far better than the 16 but slightly worse than the 128. The black shiny plastic and lightning to see all imperfections exaggerate the flaws a lot.
I'll get a 64 going too now that the machine is warm. An old PCB bed heater glued to a thick alu bed takes it's sweet time to heat up.
The 64 is somewhere between the 128 and 32. It looks like the driver does something useful with the finer stepping.
I would guess that for static resolution it is pointless to go over 16, but when constantly moving the drivers can do something useful with the extra step information.
It would be interesting to test this out on a delta, or a regular scara. It might only be visible with the low gearing I have though.
The engineers at TMC are magicians.