Am 21.10.2009 um 14:33 schrieb Haberler Michael:
ok, following up to myself once more:
- set acceleration from 300 back to 70
- changed
net spindle_rev_count encoder.1.position => motion.spindle-revs
to
net spindle_rev_count encoder.1.position-interpolated =>
motion.spindle-revs
Result: problem gone completely.
to sum up so far - let's call this the 'position update underrun'
problem:
- a low PPR encoder without using position-interpolated translates
into jerky position updates into the TP (=no *updated* position values
for one or several servo intervals)
- jerky position updates tickle a TP behaviour which looks like
oscillation but really is a catch-up game once a position update
finally becomes available - the TP really cant do much better
- a high servo/stepper acceleration value makes catch-up easier and
less noticable, but is not a fix for the underrun problem per se
- the problem shows at *slow* spindle speed, not *high* spindle speed
because the servo cycle defines a lower bound
- it's garbage in-garbage out.
so here's my pet theory:
for stable synchronized movement, there should be a *updated position
value* available to the TP at least at each servo interval.
To get at a ballpark figure, let's assume 1msec servo intervals, and a
ridiculously low spindle rpm like 60rpm, or 1/sec. So we'd need an
updated position value each msec, or 1000/sec . If the encoder has
250PPR and is in x4-mode, we'd get 1000 updated position values/sec
(in theory, probably should leave some margin here). So that would be
stable (hopefully) even without position-interpolated .
So the lower bound on threading RPM depending on PPR would be 60 /
(servo interval * PPR * pulses_per_line)
in my case that would be 60/(0.001 * 45 * 4) or 333 RPM. Guess what -
I tried with 240 RPM and boom, problem appears.
I just tried with my lathe wether this is plausible lower limit. So I
reverted to position instead of position-interpolated =>
motion.spindle-revs and tried some speeds ("auro-optical measurement
only").
360 RPM - fine
320 RPM - still ok, some wobble
270 RPM - heavy oscillation one some passes
So it's actually a bit more robust than my assumption would indicate.
But I'd say that is a usable ballpark formula if position-interpolated
is not available.
The relative speeds of updated position values and servo runs might
also explain that some passes look almost ok, and on some there's
heavy oscillation. Could be that if RPM is near the lower limit some
passes suffer more serious underrun than others depending on load or
beat effects
possible "fixes":
- thread at high spindle speed
- variant a) use a high PPR encoders and hardware q-decoder - forget
about parport+encoder altogether
- variant b) use a low PPR encoder + parport+ encoder + position-
interpolated and live with it
- use position-interpolated if available - cant underrun by definition
because an updated position is computed on the fly at each servo cycle
- increase servo intervals (potentially a bad idea)
It seems higher acceleration isnt really a workaround, just makes the
problem less noticeable.
-Michael
reading up on
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-21.txt
was very helpful
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
