Peter C. Wallace wrote: > > Does you motor power supply droop when doing a fast move? With a bare Hbridge > (Voltage mode), FF1 is needed to compensate for the motors back EMF, I believe FF1 compensates mostly for motor resistance, not back EMF. Back EMF turns the servo motor into a velocity servo with finite gain, ie. speed roughly follows applied voltage. > Torque mode amplifiers depend on high bandwidth velocity feedback, so > you may need to raise the sample rate to get fast enough velocity feedback (D > term) Better velocity feedback will allow your P and D terms to be increased, > improving following error. When tuning a torque mode drive, at least in my > experience, you have to ratchet P and D up alternately while checking the > step response. Higher D allows higher P (and higher P allows higher I). > > One of the big problems with using encoders for velocity feedback is that they are doubly quantized. First, position is quantized by the lines in the encoder. Then, position is sampled at regular intervals. So, every servo_period, some number of encoder counts occur, and there is an unavoidable jitter. For instance, when moving at an average velocity of 1.5 encoder counts/sampling interval, the velocity will be measured as alternating counts of 1/2/1/2/1 etc. This appears to the PID calculation as a constant fluctuation over a 2:1 speed range every alternate sample. Therefore, applying too much D term magnifies this fluctuation. As speeds increase, the percentage fluctuation becomes smaller. Moving to a higher sampling rate moves the worst-case speed to a higher velocity, but doesn't really fix the problem. It CAN, however, move the resulting 1/2f frequency up to where the servo drive can no longer pass such a frequency. At the default EMC2 1 KHz sampling rate, the worst case produces a 500 Hz ripple in the PWM output. If you move the servo rate up to 5 KHz, the ripple would move up to 2.5 KHz. > Dont know if EMCs PID loop has been modified to allow an external (not > DPosition/DT) velocity input. If the PID component had a velocity input, you > could use HostMot2s encoder velocity output as a better velocity feedback > term > than the (crunchy) DPosition/DT > This is pid2, but it still doesn't solve the quantization noise in the encoder-derived velocity. The one thing that really helps is to have insanely high encoder counts per user unit. This allows the PID to have lots of response to actual movement through the D term, but to reduce the sensitivity to the +1/-1 velocity quantization effect. I'm using 128,000 quadrature counts/inch on my minimill. This works pretty well, if I had just 5000 counts/inch, I think the tuning would be a lot poorer.
Jon ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
