On 01/12/2013 12:46 PM, Chris Radek wrote: > > > > OK, that is the problem as I understand it. There are two ways to > approach the fix. I agree with your analysis, and also michael's. > > > > 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 didn't understand Michael's fix enough. I think you are right! (I'm away from home right now so I can't test anything, but will do so as soon as I can.) I don't see why it affects tuning, except that it may enable the following error limit to be tightened on some systems. I have some systems that maintain extremely small PID error, in the 2 x 10^-4 inch at high speed, but the following error limit had to be .005" or so to avoid trips. I'm pretty sure this will fix it and be easy to show.
Jon ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
