This clip shows my C-Bot corexy 3D printer running smoothieware. The first 3 moves at 200mm/s are done with acceleration of M204 S5000 then I do the same moves at M204 S500 which should smoothly accelerate and decelerate but the steppers start skipping steps, regardless of the current. They steppers are Kysan 124090 bought from a reputable retailer.
youtu.be GLTlrN2f1KA
(People with low karma can not post links!)
Smoothie Build version: edge-ed25d57, Build date: Oct 17 2015 22:04:52, MCU: LPC1769, System Clock: 120MHz
Smoothieboard 5x purchased from Uberclock 3 months ago
Interestingly enough, one direction does it more than another, but I don’t understand how lowering the acceleration makes the problem worse when it should be more gentle. I do not believe it is hardware because it does not do it on the stable smoothieware release
Build version: master-9d27a61, Build date: Nov 30 2014 04:10:37, MCU: LPC1769, System Clock: 120MHz
I don’t really have the ability to build Smoothieware and find the exact commit where the issue begins though. Ideas?
I sat down and tried to figure out which firmware revision this started appearing in, but turns out my testing wasn’t valid because it worked with every firmware in git right up to Oct 17. Then it occurred to me that it must be something in my startup G-Code and I figured out what it was, the three-point-leveling.
After a G32 I get the errors with the stuttering and if I send M561 to clear the tramming plane, it works fine again. So there’s an interaction between the three-point-leveling strategy and the acceleration planning on the decelerate. Here’s my 3-point config if that’s important
# optional Z probe
zprobe.enable true # set to true to enable a zprobe
zprobe.probe_pin 1.25^ # pin probe is attached to if NC remove the !
zprobe.slow_feedrate 2 # mm/sec probe feed rate
zprobe.return_feedrate 0 # feedrate after a probe, default 0 is double of slow_feedrate (mm/s)
#zprobe.debounce_count 0 # set if noisy
zprobe.fast_feedrate 125 # move feedrate mm/sec
zprobe.probe_height 4 # how much above bed to start probe
associated with zprobe the leveling strategy to use
leveling-strategy.three-point-leveling.enable true # a leveling strategy that probes three points to define a plane and keeps the Z parallel to t
hat plane
leveling-strategy.three-point-leveling.point1 10.0,10.0 # the first probe point (x,y) optional may be defined with M557
leveling-strategy.three-point-leveling.point2 260.0,10.0 # the second probe point (x,y)
leveling-strategy.three-point-leveling.point3 135.0,260.0 # the thirdprobe point (x,y) #leveling-strategy.three-point-leveling.home_first true # home the XY axis before probing
leveling-strategy.three-point-leveling.tolerance 0.03 # the probe tolerance in mm, anything less that this will be ignored, default is 0.03mm
leveling-strategy.three-point-leveling.probe_offsets 0,0,0 # the probe offsets from nozzle, must be x,y,z, default is no offset #leveling-strategy.three-point-leveling.save_plane false # set to true to allow the bed plane to be saved with M500 default is false
A little more information. I was reading through the source code to see how the leveling handler interacts with the robot. I saw that the move is broken up using mm_per_line_segment to turn my 140mm test move into a whole mess of smaller bits. I didn’t see any need for this on my CoreXY bot. Setting this to 0 (it was 5) stopped 99% of my stuttering during deceleration. There is still a slight strange noise that comes right at the end of the move when the acceleration is set low that indicates to me that something isn’t completely right with the move. I think with the mm_per_line_segment set, I was seeing this happen every 5mm during the distance of deceleration? That said, I hear the same doot-doot sound at the end of a move even with the plane cleared so it seems this is a normal movement end.
Still, there’s definitely something wrong with the decelerator when used with “bed leveling” at least with the three-point-leveler which is really bad when mm_per_line_segment is set but is possibly workable with it set to 0. I can’t tell if this is causing small errors in head movement now, but at least my prints aren’t shifted off on every layer now…
im still a newbie at it, but i’ve encountered similar, in my case it was a slicer setting, the maximum extruder speed was too slow, i think couple that with the motors current being too low to run at such a low speed.(theres one set in your config and 1 in your slicer setting usualy).
if this is the case, its because the software slows everything to run at the lower exstruder motor speed limit.
mine starts at about 15mm/s… if iwant really slow prints, and with a low maximum extruder speed, (in kisslicer you can incroment the speed, so it increases each layer by the amount you set) when i try a set up print with 5mm/s increase per layer, when the layer hits the exstruder max setting its like the powers halved from the supply… and it dweeebs along suffering the lurgy lol.
if its not that, i think its the motor specs, its why you need the power curve charts to your motors, they work…but when outside the curve they dont work as healthy as they should. e.g. a 2 amp stepper will over come slower moves/move bigger objects but it will have an ideal min and max mm/s travel region…too much power you get a ‘singgg’ing noise’ to little and it buzz’s scarily. if alls well in the noise at the motors…its a setting some where.
beyond that…i couldnt say, sorry.
btw i couldnt find your link on you tube ‘‘doesnt exsist’’
I’m not extruding anything so there’s no maximum extruder speed to deal with, and my maximum stepper and axis speeds are set to 500mm/s so that shouldn’t be an issue.
As far as the video link, maybe this helps? Just take the spaces out.
https :// youtu.be / GLTlrN2f1KA
hmmm not healthy at all…i looks like a track obstruction to me, but as i said i’m new at all this… better to wait for the the other guys to answer.(may take a bit as theres not many of them btw)
Thanks for your insight but it isn’t track obstruction either. It is a firmware issue. Acceleration is the change in velocity over time. 5000mm/s^2 is whackado high levels of acceleration and the printer handles it just fine. When you lower it to 500mm/s^2 it should be even smoother. Changing the firmware to an old version makes it smoothly accelerate and decelerate, new version accelerates fine but deceleration is janky. You can see the acceleration change in the time it takes the head to get up to speed. Either the laws of physics change based on what firmware revision I am using, or there’s an issue in the nightly firmware.