I’ve been trying to debug an issue with my new polargraph build where I’m getting a lot of stuttering, as you can see in this video: https://www.youtube.com/watch?v=fHHctoIGHDM
My first thought was the small nema 17s I was using, even though it seemed unlikely because not much torque should be required to move a little pen, but I changed them to bigger ones anyway and double checked the drivers to make sure everything was fine, and I was still getting stuttering.
After a bit of reading I’m fairly sure that my gcode resolution is too high, meaning I can’t send lines via USB to marlin fast enough to keep its internal buffers filled up.
Has anyone had experience with this issue before?
This is on my hit-list of things I try to resolve it:
Increase the buffer size inside Marlin (Whats the most sensible highest planning buffer size?)
Decrease the resolution of my GCode (Not ideal, although I'm sure I can make some tweaks)
Decrease the speed of my polargraph (ideally I'd like to speed it up, though)
Enable ADVANCED_OK in marlin so I can have better visibility over the buffer size
Smarter feed rate? Should I be adjusting the feed rate on tighter curves? How does acceleration and deceleration work when sending new feedrate values on every move
Make use of beziers splines within marlin and change my gcode accordingly. My small brain can't work out if this will work correctly as i'd need to translate position and control points from cartesian to non-cartesian? Welp.
Is your baud rate already at 250k? Have you tried running from an sdcard? Have you tried running it at 1/2 or 1/4 speed, just to see if that helps?
I couldn’t hear the steppers, but if they lost steps, you would have heard a grinding like noise and the drawing wouldn’t be right. If they aren’t skipping steos then the steppers and drivers are fine.
Do you have an idea of the resolution you’re using? There are certainly tricks you can play with there. Just going through your coordinates and deleting points that are too close should be an easy thing to test. 0.1mm resolution is a good starting point for the sand machines, but they move slower, 15-30mm/s ish.
You can also use arc commands G2/G3, but that’s more math.
What are your steps per mm? Things in the 100ish range are fine, but if you’re closer to 1k, then you might be hitting steps speed limits.
If you’re going from speed 20 to speed 10, then the acceleration is similar to going from speed 10 to 0. FYI, jerk is not the derivative of acceleration in marlin. It’s what delta speed can just be changed without applying acceleration. So if you’re going from 10 to 0 and jerk is 5, it will decelerate from 10 to 5 and then stop.
You can also try some patterns from sandify. they should have fewer nodes. Some of the patterns from the sysiphus tables are really detailed though.
Baud rate is 250k. Haven’t tried running off an SDCard but I’m trying my best to avoid it if I can. Running at lower speed fixes the problem, but I want to run as fast as possible.
That’s about the fastest I can make it move before it starts to stutter on the curvier parts.
I’d still like to try to squeeze some more speed out of it if I can, but I’m struggling to properly understand whats causing the stutter to happen. I’m using the MPCNC Marlin profile, but I’ve tweaked BLOCK_BUFFER_SIZE up to 32, BUFSIZE to 8, TX_BUFFER_SIZE to 32 and I’ve got ADVANCED_OK enabled. I’ve also bumped DEFAULT_MINSEGMENTTIME up to 100000 to see if that’d make any difference, but it doesn’t seem to have.
I’d increase these settings more if I had any spare memory to do it, but I’m struggling to work out what I can safely disable to free some more memory.
It’s difficult knowing what to tweak in the firmware when it’s not totally clear what the problem is in the first place. ‘Not sending over USB fast enough’ seemed like the most likely problem and the fact that it fixes when you slow things down adds weight to that argument, but as far as I can tell the planner buffer is always full, which is really confusing.
I dunno - I’ve got some time off work in the next couple of weeks so I can experiment a bit and learn a bit more about Marlin.
Thanks for sharing those videos. That is a neat machine! It’s great seeing sandify on it.
I would try grbl before writing your own. There’s a lot that you are using and the extra stuff isn’t such a big deal. I have one machine with low low memory and I disable SD card (but leave the lcd, but that’s not essential either).
Have you thought about the accel and jerk settings causing this? If jerk gets too low, it can try really hard to stop at corners. If acceleration is too high, it can also stop and start very abruptly.
I’ve messed about a bit more and made it slightly better (not too sure how). I’m pretty sure I’ve ruled out anything to do with data buffering. It’s definitely just related to motion control.
It seems to be happening when the motors have to change direction. For example, here’s a sandify spiral: https://i.imgur.com/KtHxKqf.jpg
You’ll notice that at the top right and top left there’s clear stuttering(?!) which starts at the point where the motors have to switch from ‘pulling’ to ‘pushing’ and and vice versa. It just seems to introduce some wobble that it struggles to recover from.
I am curious now, why it swings when jerked. If the center of mass were perfectly in line with both cords, a jerk wouldn’t create any torque. If it were hanging freely and not touching the board, then the center of mass would naturally be in the plane of the cords and directly below the intersection of the two cords. In such a case a jerk should cause the thing to twist around the pen which in theory shouldn’t cause a defect in the drawing.
But when the pen is also (very slightly) supporting the weight, the center of mass is now shifted slightly off the plane of the two cords and a jerk on the cords can cause swinging vertically and horizontally.
But it seems if the center of mass were higher, it would get closer to the intersection of the two cords and pen. This might shrink the offset between the center of mass and the plane of the two cords, and thus reduce the torque generated from jerks.
This could be tested by adding mass near the top until it almost wants to tip over. Change nothing else and see what effect it has.
I wouldn’t have thought so because they’re just pulleys with fishing line tightly wrapped around… but I see why you might think that, it certainly feels like backlash could cause that. I’ll double check the tightness of the pulleys tomorrow. Pretty sure they’re ok though as they’re press-fit and have set screws.
