Jon Elson wrote:
> Tom wrote:
>> Jon Elson <el...@...> writes:
>>
>> snip...
>>   
>>> Oh, one big feature I added, with the expert help of Jeff Eppler at the 
>>> Fest, was to put an integer lowpass filter on the jog dial to get rid of 
>>> the nasty buzzing that the coarse jog dial counts caused.  I have used 
>>> this on both the Bridgeport and minimill, and it is a great improvement.
>>> The ilowpass component should be on all EMC2 distros since about July 2008.
>>>
>>>     
>> Oh oh... Apart from the jog pendant, you just touched on the one aspect of 
>> my 
>> Kasuga EMC2 conversion that still bugs me. All the axes buzz and moan while 
>> holding position, and if I try to adjust the D term or deadband to eliminate 
>> this, then my following error causes faults during rapids.
>>
>> Is there a way to use the ilowpass filter to eliminate all the noise my mill 
>> makes while at rest?
>>
>>   
> What servo drives are you using?
> 
> A problem with EMC2 using the PID hal component is that the D term has 
> no filtering on it.  Due to the "double quantized" nature of encoders, 
> there is a real spike in the frequency spectrum of the velocity at 1/2 
> the sampling rate.  I call it double quantized because position is 
> measured in discrete counts, and then the count is sampled at regular 
> intervals.  So, it is guaranteed that at certain velocities you will get 
> a +1 / -1 jitter in the number of encoder counts per sampling interval.  
> If the encoder resolution is very high (I have 128,000 counts/inch on my 
> minimill) it somewhat masks this.  At lower encoder resolutions, the 
> problem grows.  Imagine a system where you are moving at 500 
> counts/second.  With a sample rate of 1000/second, then the samples come 
> up like this : 0, 1, 0, 1, 0 etc.  That is a 100 % jump from sample to 
> sample at 500 Hz.
> If you have much D turned on, it is going to buzz badly, as the D just 
> miltiplies this effect.  Try turning the D as low as you possibly can go.
> Another scheme that seems to help is to turn up the servo-thread rate.  
> Depending on your servo interface, you may be able to go to 2 or even 5 
> KHz.  At 5 KHz, the "buzz" frequency will be moved up to 2.5 KHz, where 
> it may be above the passband of the servo amps.
> 
> This problem has been bugging me for some time, and I am planning to 
> work on it at the EMC Fest in May in Wichita.  My general plan would be 
> to put in a fairly simple digital notch filter at 1/2 the sample rate.  
> Maybe somebody well versed in control theory can expound on the 
> implications of this, and whether it would be better to have a sharp 
> notch or a more gradual rolloff starting a little below 1/2 f.
> 
> Buzzing at rest may be eliminated by adding a little deadband.  
> Depending on encoder resolution, a deadband equal to a couple encoder 
> counts will often stop the oscillations entirely, or make them sporadic.
> 

That will be something very interesting to experiment with at the Fest.

I have long had my own thoughts on this issue.  Our software encoder 
counter has a velocity output which is much less quantized than the 
position output.  Some (but not all) hardware drivers also have a 
velocity output.  If the PID loop had both position and velocity 
feedback inputs, it could use the velocity feedback for the D term.

This has the potential to be better than any filter - the encoder 
counter (hardware or software) simply has more information to work with. 
  The software encoder counter generates its velocity output by looking 
at not only how many counts arrived, but _when_ they arrived (with base 
period time resolution).  I'm pretty sure the latest hostmot2 driver 
does the same - in that case it knows when pulses arrived with 
sub-microsecond resolution, and the velocity output can be very smooth.

This image ( http://jmkasunich.com/pics/new-encoder.png ) shows the 
software encoder's velocity output (blue) compared to the actual 
velocity (green) and velocity calculated by differentiating the position 
(red).  The improvement from red to blue is dramatic.  The only time the 
blue trace shows any significant error is when the velocity is near 
zero, when many milliseconds go by with no counts at all.

Despite the name of the image, this is not new - the velocity output was 
added to CVS in January of 2007 and was released as part of EMC 2.2.0. 
However, I've never gotten around to tweaking the PID loop to take 
advantage of it.

Regards,

John Kasunich






------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to