Am 13.01.2013 um 15:12 schrieb Andy Pugh: > > > On 13 Jan 2013, at 11:57, Michael Haberler <[email protected]> wrote: > >> .. The Following Error Position field refers to the deviation of current >> actual position from the machine commanded position. > > Though that doesn't mention which iteration of the commanded position. > I am of the opinion that f-error is how close the machine is to where it was > told to be, and the pid "error term", which isn't actually an error in the > sense of a problem, is the basis for the PID calculations. > > They are different things, and the current situation is correct.
Nobody can falsify your argument because you dont give a correctness criterium to verify against - a formal definition of what ferror is supposed to mean for you However, if you are suggesting that ferror means 'the difference between where a joint is <now> and where it is supposed to be <now>', then that difference is not subject to variation by joint speed or servo period - it is just a distance if you use that definition, then the current ferror is clearly wrong because its absolute value depends proportionally on joint speed and inversely on the servo period to see why a value based on 'the difference between where a joint was <last time around> and where it is <now>' isnt useful to determine if a machine is off-path, assume the following steady state model: - perfectly tuned pid loop with an I term, such that commanded vel == actual vel hence mean(pid.error) == 0 (mean because of quantisation noise) - a linear move underway say The only ferror which you _ought_ to see in such a situation is the quantisation noise, a triangular wave which is zero at the middle of the sampling period, and has maxima at vel/dt and -vel/dt (provided you could sub-sample the noise with a higher rate) What you _actually_ see is that noise offsetted by the residual term, which is a) wrong and keeps tripping false positives b) there is no explanation why ferror should in any way depend on speed or sampling interval. A second thought experiment to show why it is wrong: Assume above move, and you could vary the servo period by a knob. As long as the servo frequency is sufficiently above 2 * the cutoff frequency of the pid/machine system, that system _should_ continue to run in steady state. However, by lowering the servo frequency you _increase_ ferror (why?) and eventually trip a following error while there is actually no path deviation at all. That said, of course you can conceive a value which compares last commanded to current position like in the current code - it's just not meaningful for determining path deviation. The only reason why it doesnt bug more folks is because machines used around here are too slow to make it an issue. I think some of the terminology misconceptions about ferror stem from mixup with residual error terms of a P-only PID loop. But that is a PID property, not a path deviation problem. -m re PMAC NC manual: given the thoroughness of that manual I would be very surprised to find such a gaffe in a fundamental definition; I'm sure Curtis would answer such a question > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
