Jon, thanks. First things first I will try to improve the Z axis response while staying within the torque mode, just so that I do not switch back and forth too much. I will try to increase P and will report what happens.
As for velocity mode, I will proceed carefully with this. Thanks for mentioning putting square waves as the input to the amp. The AMC manual talks about the same thing. I have a wavetek square wave generator and could use it. But that would probably come later. I am saving all posts about velocity loop tuning for later. I believe that this is very useful stuff to learn. - Igor On Wed, Sep 15, 2010 at 9:42 PM, Jon Elson <[email protected]> wrote: > Igor Chudov wrote: >> I may have been too quick to declare a total victory. >> >> Here's why: >> >> I did have a good success moving UNLOADED table in all directions with >> relatively low (0.0002" or so) following error. That cannot be denied. >> No chattering, buzzing, the system calms down instantly after motion, >> etc. >> >> But I also noticed something that I did not quite like: >> >> If when EMC2 is in holding position, I take my hand to the pulley of >> the Z axis motor, I can turn it by hand against the resistance of the >> servo motor. If I watch the position display in AXIS, I would say I >> can turn it enough to make Z move by 0.002", until the servo >> resistance strengthens enough to stop by hand. And I am not a >> particularly strong person. >> >> With the old tuning, that was not the case and servos acted in many >> annoying ways, but always held position so that I could not >> perceivably turn the servo motor pulley by hand when position was >> held. >> >> I wanted to hear some comments on this matter. Does it mean that my P >> and I are not high enough? Or what? >> > Yes, probably. Does it get unstable if you raise P? If not, then raise > it as high as you can. > P = stiffness. But, that's where it starts to get really messy. The > velocity servo is > a continuous-time system, as the tach provides velocity information with > no quantizing > of position or sample rate. The encoder is quantized in both position > (encoder resolution) > and time (servo sampling rate). These quantizations cause a "noise" to > be added to the > information from the encoder. This noise requires that EMC treat that > information > with some allowance for that noise. But, that is not required of the > tach feedback, it is > pretty close to noise-free, at least with a good tach. > > With a very high resolution encoder, sampled at a very high rate, the > added quantization > of the encoder becomes quite small. The positional quantizing is of > little consequence, > and the frequency response moves up to way outside the servo bandwidth. > > I think your encoders are not that high resolution, and you are using > the default 1 KHz > servo period of EMC, I am guessing. The Nyquist bandwidth of that is > 500 Hz, which > is likely to be outside the servo amp's response. > > So, anyway, what I'm trying to get around to saying is that these > quantizations put an upper > limit on how much P gain you can use on the EMC servo loop before it > starts to exhibit > instabilities. The quantizing stuff adds noise to the apparent velocity > derived from the > encoder counts. Say you are moving at 1500 encoder counts per second, > and sampling > at 1000 times a second. You get alternating samples of one count, then > 2 counts, then back > to one count, every servo period. That is a 2:1 jump in apparent > velocity every sample! > The D term amplifies this and starts to add this artificial noise back > into the PID output. > So, you have to use D sparingly or it makes the noise worse. Forcing D > to stay at a low value > limits how high you can go with the P term. > > This is why the velocity servo system has its benefits, as it does not > suffer from this quantization. > But, the velocity loop needs to be tuned. You can use Halscope to do > the tuning, so it doesn't > require a lot of test gear. My guess is you didn't have the velocity > loop well tuned on your machine, > and were trying to fix the response with EMC's PID. That won't work. > > The proper way to do this is to apply either square waves or trapezoidal > waves (feed a square wave > through the Hal limit function to limit the slew rate) to the PPMC DAC > to step the system back and forth. > Observe the response, probably best with the ppmc.0.encoder.00.delta > output (velocity) and adjust until > the command and response are as close as possible, especially at the > inflection points. Then, use > the PID to clean up any remaining departures, using the error signal. > > Jon > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
