I missed the part where you said you are using linear encoders, that's a bit different. Backlash comp is probably not a great idea in that case as I'm pretty sure it's just a dumb "whip the lash out" on direction change kind of thing. Your backlash is already accounted for by the fact that your measuring the table directly and not the motor prior to the point the backlash exists or not measuring it at all.
The fact that the axis has to stop and reverse a noticeable amount implies that it is overshooting too far and just requires better PID tuning, the error should be decreasing over time as the PID "learns" the correction values. I'm not a PID tuning wizard, I generally have to read up on it every time I do it since I don't do it often. I run the Brushless DC spindle motor on my mill with a torque mode drive (Mesa 8i20) which is generally not the thing to do since spindle control is inherently a velocity mode deal with the drive handling half the loop. The moment a free spinning cutter enters a workpiece there is a drastic change in the torque required to maintain that spindle speed, then it levels off mid cut. It's difficult to tune a PID for velocity control over a torque mode drive but it works very well now, and as you can imagine it has to be very fast. I do rigid tapping as well with this setup. Your use case is typical, the only thing you should really need is what you originally had with a position input and velocity output PID it just needs proper tuning. As a side note I just stumbled across the AT_PID <http://www.linuxcnc.org/docs/html/man/man9/at_pid.9.html> component. Didn't even know it existed but an auto tuning PID would be pretty neat if it actually works well. I may try it on my spindle On Thursday, July 25, 2019 at 11:41:50 AM UTC-4, Edgardo Gho wrote: > > > I tried setting up backlash compensation (setting the backlash = xxxxx on > the axis) and increasing accelerations but that did not help much. > I spent more time trying to figure out how motion works, and noticed that > motion keeps moving independently from what the PID is doing. Basically > motion is reading the encoder position for an axis, generates a "next > position" at a certain feed rate and outputs the error from the current > position vs desired position.. and if this error is higher than a preset > value it reports joint x error. > So if the preset error is too low, it fails pretty quickly. > > What I ended up doing is putting a comp module with the f-error output vs > a preset value (0.1mm) .. so if the error is greater than that, it would > set the feed-hold input for motion. This way motion will stop until the > error goes back to less than 0.1mm. I combined X and Y using an or2 and the > backlash gets compensated by the PID. > Basically I'm stopping the motion module so it won't keep trying to change > the position until the PID reaches (or is close to reach) the desired > position. > > I upload a picture generated by recording the encoder output for X and Y. > Each pixels is 0.01mm. You can see artifacts when the spiral changes > direction on one of the 2 axis but this is greatly reduced compared to > running it without stopping motion. > > I still have to adjust error values and tune the PID. > The speed that I get is obviously not great considering most of the time > motion is stopped waiting for the PIDs to reach the desired position. > > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/d04c7a95-7a31-4ff2-af87-f0dcfca237ab%40googlegroups.com.
