On Wed, 31 Oct 2012 21:22:58 -0700 (PDT), Peter C. Wallace wrote: > On Wed, 31 Oct 2012, EBo wrote: > >> Date: Wed, 31 Oct 2012 22:56:28 -0500 >> From: EBo <e...@sandien.com> >> Reply-To: EMC developers <emc-developers@lists.sourceforge.net> >> To: emc-developers@lists.sourceforge.net >> Subject: Re: [Emc-developers] ferror calculation incorrect in motion >> >> On Wed, 31 Oct 2012 19:28:30 -0700 (PDT), Peter C. Wallace wrote: >>> After spending some forum time trying to help a customer with >>> tuning >>> a torque >>> mode drive, I have noticed that ferror is calculated incorrectly >>> and >>> if >>> minimized will result in less than optimum actual error. >>> >>> The error appears to be that ferror is calculated before the >>> trajectory is >>> calculated so it always compares the previous waypoint with the >>> current >>> (encoder) position. This is easily see by the difference in ferror >>> from the >>> PID error (they should be the same) >>> >>> This causes a value equal to the velocity in machine units per >>> second*servo >>> thread_period to be added to the ferror. >> >> interesting. Can you give your preferred technical reference for >> the >> PID error calculation for review? I am sure I can dredge several >> up, >> but you might have a clearer reference. Also, have you located the >> offending code? If so what file and line number? >> >> Thanks and best regards, >> >> EBo -- >> > > This is not a PID issue. The issue is that the ferror is calculated > differently than the PID error. So if you tune the PID loop properly > the > ferror is larger then the PID error by an amount proportional to > velocity. > > > The normal processing sequence that causes the problem is this: (and > all the > HAL files I looked at are arranged this way, that is, > read/motion/pid/write) > > encoders are read to get current position > motion does ferror calculation (on previous waypoint but current > encoder position) > motion calculates next waypoint (TP) > PID uses difference in motions new waypoint and current encoder > position to calculate error > > The problem is that if the PID loop is tuned so it has close to 0 > error (its > error, which is the difference in the new waypoint and the current > position) > you will have a calculated ferror thats equal to (velocity * sample > period) > because the ferror was calculated from different data (current > encoder > position and previous waypoint) than the PID error (calculated from > current > encoder position and next waypoint) > and this is just plain wrong.
Peter, Got it in two ;-) OK Now the question is should the ferror be calculated based on the current encoder position, or the PID on the previous position? I'm assuming the former, but I've never studied this to know exactly how previous and current positions (and some dT) would be used to calculate the derivative gain. I have not gotten enough sleep in the last couple of days, so maybe I am just to tired to see it. All that being said what you write makes sense. So, do you have a patch so that we can test? EBo -- ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
