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
