Am 22.10.2009 um 12:21 schrieb Andy Pugh: > 2009/10/22 Jon Elson <[email protected]>: > >> Good hypothesis and data taking! So, it seems the problem is the >> encoder counter sees >> a zero velocity between actual encoder counts, and tells the slaved >> axis >> to stop NOW! Then a >> count comes in, and it says MOVE NOW! Yes, I can see this is a >> definite >> problem. > > I am not sure that this is the full story anyway.
Me neither. I've collected my current conjectures at http://mah.priv.at/txt/sm.txt and asked the emc-devel folks for a review. If that's considered to contain sufficient facts as opposed to factoids I'll put it on the wiki - comments welcome. > The oscillations > are typically nothing like encoder frequency (say 200Hz) but nearer 5 > Hz. I dont think the oscillations relate to encoder frequency per se but to the rate at which the TP sees an unchanged position between subsequent TP cycles - it's a spindle-speed and PPR dependent problem after all. The speed at which the corrective action is taken after a hiccup (stopping or accelerating the dependent axis) depends on axis acceleration and speed. That was clearly visible after I tried your suggestion in fiddling with acceleration - higher acceleration resulted in lower f-error and higher oscillation frequency (which happened to taper off faster of course). maybe one should view it differently - the encoder creates a stream of *changed* position updates and the TP consumes it (only changed/ reasonably accurate position reports make sense). If the encoder falls behind due to quantization the TP starts stuttering. The relative speed could be subject to all sorts of fluctutations and delays, which could explain why some passes sort of look ok and some stutter > Also note that G33 et-al are position-mode not velocity-mode. > > The simple solution might be for stepconf to always connect to > position-interpolated rather than just position. yes - I ran into the problem when switching to hm2 which doesnt currently provide position-interpolated > With a good encoder > this seems to work fine in most cases as long as the axis > accelleration is adequate. yes, I'm out in shopping mode.. -Michael ------------------------------------------------------------------------------ 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
