So this was the key ....
>> - set acceleration from 300 back to 70
>>net spindle_rev_count encoder.1.position-interpolated => motion.spindle-revs
With the working setup you have now, what version of EMC2 are you using and
what patches have you applied?
Thanks,
Dave
Haberler Michael wrote:
> 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
>
>
------------------------------------------------------------------------------
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
