On Wed, Jan 09, 2013 at 08:13:05AM +0100, Michael Haberler wrote: > motion has an issue with ferror calculation:
I've studied this some more and disagree with the change, and I have a different, much simpler change that I propose instead. I've pushed this to pid-ferror-fix-try2 Currently, before either change, motion generates a new commanded position every servo cycle. It expects the machine to use the next servo time slice to move to that new position. Then it waits... Now on the next servo cycle, it reads the new feedback position and compares, and calls the difference the following error. Also currently, before either change, pid reads the commanded and feedback positions simultaneously, on the SAME servo cycle, and compares those to get its own idea of the error. The astute reader will notice these methods don't match, and in fact use different commanded positions - different by one servo period in time. This makes the two ideas of ferror disagree by the distance moved per period (in other words, proportional to the velocity). As Peter has pointed out, at least with a velocity mode setup, you can turn the FF1 knob to move this error into pid's calculation or motion's calculation, but you can't get them both minimized at once. Here is a plot of motion ferror vs pid ferror at the start of a move, generated with servo-sim. As you can see they don't match at all. http://timeguy.com/cradek-files/emc/neither-fix.png OK, that is the problem as I understand it. There are two ways to approach the fix. Michael saw motion as the part of the puzzle that's "off by one" and changed it to generate the new commanded position and compare that to the current position, even though the machine has had no time to reach that new position. This actually does a decent job of covering up the problem, as long as the machine is traveling at a constant velocity. If it is accelerating, though, the distance per dt is changing and I believe this moves the discrepancy from velocity-proportional to acceleration-proportional. I have evidence of this in my test results: http://timeguy.com/cradek-files/emc/motion-mode.png In the new branch I've reverted this fix, which I think is mistaken, and changed pid to use the previous target vs current position to calculate error, so it agrees with motion. This makes the two errors match exactly (you only see one trace because they are on top of one another): http://timeguy.com/cradek-files/emc/pid-ferror-previous-target.png Aside from apparently fixing the discrepancy exactly, my change has the benefit of being much less invasive and much simpler. It makes more intuitive sense to me because it does not calculate error based on a brand new commanded position the system has had no time to reach. I agree with Michael that unfortunately this will affect existing tunings, so it must be made an option, at least in 2.5. If we agree it's correct, we should probably make it the default behavior in master. I'd appreciate it if concerned parties, especially Peter, Michael, and John K. would check this out and comment. It would be great if someone could test on hardware that had problems before. Thanks Chris ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
