Andy Pugh wrote: > 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. The oscillations > are typically nothing like encoder frequency (say 200Hz) but nearer 5 > Hz. > Right, I guessed around 2 Hz, but they are not plain oscillations, ie. not at all sinusoidal. The axis.2.f-error was a sharp-edged, straight-sided triangle wave, indicating some function feeding the velocity was giving a square-wave signal, ie. hard limiting. What I BELIEVE is happening, is that the coarse granularity of the encoder signal is exciting the velocity logic to ram into its output limit, and then the system becomes violently unstable. This is all just guessing from too little info, hopefully we can get some plots of other signals from the stepgen to see in more detail what is happening inside. > Also note that G33 et-al are position-mode not velocity-mode. > But, stepgen needs to convert to velocity to know what step rate to generate until the next servo cycle. I think this is where the oscillation is coming from, but the root CAUSE may be from violent fluctuations in the commanded position going in, requiring the velocity to change faster than the algorithm can handle. Once it has been upset, it seems to not recover gracefully. > There might be an argument for using a more sophisticated PID type > controller, but the correct P. I and D would almost certainly be > strong functions of spindle speed. Add to that the complication that > you are trying to control to position but are limited by velocity and > acceleration and it becomes difficult to think about, let alone work > out how it should be coded. > Agreed that for rigid tapping, which needs to follow the exact path from BOTH directions with minimum position lag, this is not easy.
Jon ------------------------------------------------------------------------------ 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
