I never thought this blog would attract a serious following, but it appears I've recently lost half my followers. That leaves me with one.
I sent my motor back to Sherline a couple weeks ago. They replaced the thermal switch. I hope that was the actual problem. They shipped it back, I won't get it for another week. In the meantime I decided to write code to do backlash compensation.
Backlash is the "play" in any mechanical system. Some have more, some have less. Some "cartesian robots" like milling machines claim "zero backlash" but I think they are really "near zero backlash". I don't know, maybe there are some seriously tight roller bearing systems that are truly zero backlash. I made a zero-backlash nut once. Unfortunately it was also "zero-movement" as it was much too hard to move. Epoxy makes a great zero-backlash zero-move nut.
My system has a familiar looking threaded rod (1/4-20) with a nut fixed to the table. As the rod turns, the nut and table moves up and down the rod. If you've threaded a nut on a rod before, it usually moves easily down the rod because there is space between the nut and rod. You can wiggle the nut a bit on the rod. Once you tighten it down to something, the slack is pulled out of it and one side of the "V" that makes the threads is pulled tightly together and it doesn't move.
When the rod is turned such that the nut moves away, the slack is all on the far side. When the rod is turned such that the nut moves closer, the slack is all on the near side. When switching directions the rod turns a bit without the nut moving while the slack "moves" from one side of the V to the other. This is backlash.
When working entirely manually, you can feel the backlash. I have a digital read-out unit on my mill. This DRO has electronic backlash compensation. I measure the backlash and key it in to the unit. It tracks the direction of movement and doesn't count the signals during backlash take-up. I've added the same concept to my host software and controller firmware. It's pretty sweet. My circles are nice and round now. A side benefit is that my code organization has improved. The Controller tends to get a little messy and I moved some code out into its own class.
The code to track and compensate was pretty easy but there were some unrelated bugs that got in the way. One problem in the host software involved code that deleted (merged) points on the path that were very close together. I failed to update the IN/OUT speed of the point so it matched. I was testing a path that ran the spindle full speed into a corner and it was overrunning and missing steps.
A while back I improved my stepping algorithm but it does appear there are limits to it. I step the "longest axis" of a line every loop and step the shorter axis (just 2 for simplicity) every N steps of the long axis. It's not really N, tho' for odd proportions. It may be 2-2-2-3-2-2-2-3, for example. Every other step for a few, then the third, then back to every other. Extreme cases may have the 2 axes in step for say, 100 steps then one axis skips a loop. At full speed this is enough to cause resonance of the stepper motor. (I'm not really sure it's resonance, but that's what I'm calling it.) This results in the stepper not moving at all, but sort of rattling in place. And losing tons of steps, of course. This explains one of my formerly unexplained cases of the spindle going off course. Going forward, cutting such extreme vectors will be done at a low enough speed that it won't be a problem.
I implement "uncoordinated moves" for rapids that avoid such extreme vectors and allow me to move at full speed. A coordinated move is when you move from point A to B in a straight line. The 2 or 3 moving axes are coordinated with each other. In an uncoordinated move, all axes (required to be moving) move at the same speed and each stops as soon as it reaches the desired position. An uncoordinated move is made up of "45 degree" lines and straight line segments. These vectors are no problem to handle at full speed.
My velocity planner sets the maximum speed through a point based on the angle. A zero degree angle is full speed. A 70 degree angle requires a full stop. I had to drop the 70 down to 45 as the rapid movements appeared to be losing steps. I think there's a lot of room to tune this, a slow speed cut probably does not need to stop, but it will probably be good enough for some time to come. I doubt I'll be terribly concerned with achieving maximum speed to reduce overall run time.
