this theme is quite complex, and anybody interested might have a look at the ensuing discussion: http://emc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-12.html#18:46:00
I think the core of the issue revolves around a unclear definition of 'ferror', which makes everybody fill in his favorite perception, including mine. what it obviously was intended to measure was a degree of deviation from an ideal path, with the purpose of aborting motion as a safety measure if that 'degree of deviation' becomes too large. what the original code does is lump together three pieces of information, by taking the previous commanded position, and the current encoder position into a pin value which is by definition constant over a motion period. These are: 1. the actual path deviation of the machine, if any 2. the quantisation error introduced by sampling of a continuous path 3. a residual error introduced by a one-motion-cycle timeshift, by taking the old commanded position compared to the current encoder position. That residual varies with joint speed - the faster, the larger the residual. what we really would be interested in is 1). 2) is baggage and 3) is counterproductive and was the motivation for the patch. We clearly cant do anything about 2) per se, but it is interesting to observe that for the maximum of that value is is relatively unimportant whether to sample it at the current or the next sample, because a quantisation error tends to be largest at the sampling points. That is an important property because it makes the question of a cycle delay or not with respect to absolute value of this error relatively meaningless. This image from wikipedia illustrates this nicely: http://en.wikipedia.org/wiki/File:Quanterr.png - note also that the quantisation error is a continuous curve and not a step function which is why it cannot be represented as a step function (pin) in motion intervals in a meaningful way. third, the velocity-dependent residual error. The reason why this was an issue was *false positives* on following errors - the residual would cause to trigger even if in fact the error is within limits, simply if speed was high enough. I disagree with Chris as the impact on 'tuning': what the patch will cause is avoid unjustified following errors - meaning a working configuration will continue to work; it will however allow to work with tighter ferror limits at high speeds without following error, which is yes-or-now but has no impact on tuning per se, except improving options. As for the purpose of determining path deviation, I still am convinced the only meaningful value to look at is current actual versus current commanded position, and I dont think compensating a dubious delay cycle in one component by a not-quite-clear-about-all-consequences delay cycle in another component is the way to fix this issue. What about non-pid configs which have, at least in principle, the same problem? I'm laying that out in more detail because it shows the need for more formal and tighter definition of terms; and it would be very useful to give the question of how to measure path deviation more thought. Does anybody have experience how these things are measured and decided in other systems? While I am at it: another rather dubious error condition which would warrant more academic rigor is the 'unexpected realtime delay' message of motion. What it obviously is intended to mean is 'oops, the commanded position could be off because I'm executing late'; however I have not seen any attempt to quantify the actual path error against some limit, and - much more important and promising for better results - actually correct for delays in motion execution. NB I'm not saying _all_ realtime delays can be compensated algorithmically, but the commanded position can within certain (actually rather large) limits, and it has never been attempted. Well actually I have, but my first two attempts failed pending my better understanding of underlying theory and code. - Michael Am 12.01.2013 um 19:46 schrieb Chris Radek: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
