Hi all,
Years ago I tried the at_pid and it didn't work very well if at all.
Like I said it has been years. Tuning torque mode is difficult at best
but at least on a spindle one doesn't have to worry about it crashing
something. I have thought about the idea of manual tuning to get close
and then implementing a monte-carlo to finish the process. My experience
with linear scales and velocity mode has not been good. Just not enough
counts. Having said that the dual encoder approach the guys used on
Stu's big machine should work very well. Since you already have the
linear encoder the expense to add a rotary encoder is minimal. There are
people in both mk and linuxcnc plenty bright enough to write an
auto-tune but since this is a volunteer group some has to want to do it.
Most of us get by with manual tuning and get very good following errors
but it is tedious.
Hang in there.
Dave
On 7/25/19 3:43 PM, justin White wrote:
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 machinekit+unsubscr...@googlegroups.com
<mailto:machinekit+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/d04c7a95-7a31-4ff2-af87-f0dcfca237ab%40googlegroups.com
<https://groups.google.com/d/msgid/machinekit/d04c7a95-7a31-4ff2-af87-f0dcfca237ab%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/2d49d8a0-1d9c-5d3f-8946-65fa4f094e5f%40charter.net.
