Well, that explains a lot. One option is to convert the D into floating point (or fixed point with a decimal), but with an integrator - FIR filter. You need a FIFO buffer where you put the D value, you sum all the values in the FIFO, and if necessary divide it by the size of the FIFO.
For starters, we may begin with 16, 32 or 64-entry FIFO. Just one rolling pointer and 16-entry table should do a lot. (similar to analog D/A converter) The most sensitive input on a PID is the D term, so solving this is very important. On 9/24/07, Jon Elson <[EMAIL PROTECTED]> wrote: > Hello, > > I had some odd problems with following error settings this > weekend. I am setting up a machine in pure mm user units, and > got the tuning working pretty well, so I then wanted to tighten > up the following error limits. So, I set both FERROR and > MIN_FERROR to 0.01 (mm) and found that I would get the following > error trip about 150 ms after motion started. The jerk at the > start of the linear acceleration ramp caused the worst error of > about .003mm, the error then decreased a lot, and was about > .001mm when the following error was declared! So, the error > never reached the limit. I then raised both FERROR and > MIN_FERROR to 0.05, and everything was fine. If a put enough > drag on the motors to cause a following error, it ocurred at > around 0.05mm, as expected, and was very prompt, within a couple > ms. I have looked at the code, and can't see what could make > this happen. Are there some defaults for these parameters that > may override what is in the ini file? > > Another problem that I discussed a bit with Stephen Padnos was > the sensitivity of the D term. When I look at the velocity > derived from the ppmc encoder, it is conveniently in raw encoder > counts, and looks beautiful, ie. it is a noisy band between > consecutive integers, so it jumps between 2 and 3, then as speed > picks up it jumps between 3 and 4, etc. This is as good as you > can get due to the double quantizing, first by the encoder, and > second by the servo sampling interval. But, of course, this > forces the following error to suffer the same quantization, so > there is a lot of noise at 1/2 the servo sampling frequency. > The D term of the PID is totally swamped by this noise, that is > maybe 2-5 times greater than the real velocity fluctuations. > The lower the encoder resolution, the worse it gets. I am using > 128,000 counts/inch on my minimill, this user's machine is set > up for 40,000 counts/inch (or in mm units it comes to 1574.803) > And, worst of all, on his A axis it is 400 counts/degree. That > axis is really growly at low speeds. Anyway, the range of D > settings that produce stability is narrow, and has to be set > very low to prevent the quantizing from being greatly amplified > and swamping the actual velocity signal coming out of > pid.x.output. When I look at that pin, I see a very small > signal, punctuated with huge noise bursts that are about 3 times > larger than the P-P magnitude of the velocity ramp hidden under > the noise. That sure isn't the way to make a well-behaved servo. > > Steve and I discussed some digital filtering of the > instantaneous error signal before feeding it into the D term. > After looking at the signals with a very expanded time scale, it > became clear that a lot of the energy was at 1/2 the servo rate > (no surprise there), so the filter could actually be really > simple. I'm not an expert on control system theory so I could > be chasing the wrong problem. Hey, John, how about an FFT > function in HalScope? That would be really cool! Otherwise, is > there a data dump function that would hardcopy the screen > samples to a file? > > I couldn't find too many people on IRC yeaterday. > > Any comments? > > Jon > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
