On Mon, 01 Mar 2010 19:10 -0800, "Flying Electron Inc" <[email protected]> wrote: > Hi all, > > Hoping some people that have tuned their servos with EMC2 might > be able to share some of their insights that they learned during > their tuning with me. > I built a pick and place machine with a servo on the X axis and I > started > running tests to tune the PID loop for the servo. Right now, I have > everything set to zero, a deadband set to 0.00001 and I am adjusting > the Pgain to find the optimal Pgain before I start varying the other > parameters.
0.00001 inches seems like a very small value for deadband. What is your encoder scaling (counts per inch)? Normally, the deadband should be set to about 1 or 2 counts. Do you really have 100,000 counts per inch? > The test I am using is to start from a standstill at X=0, move to > X = 8 inches with an acceleration of 25in/sec^2 and a maximum > velocity of 9in/sec, come to a full stop and wait for 0.5 seconds, > then reverse back to X=0 with the same acceleration profile. That seems like a reasonable profile to tune with. > I tried different Pgain values of 4, 8, 10, 12, 13, and 14 to see > what the error looked like. at Pgain of 16 the machine began > oscillating badly. I've attached a link to an image of the > screenshots i took from hal scope for the different Pgains that I > tried. To my inexperienced eye, it looks like Pgain 12 is the best, > but I'm not sure if the error graphs are even supposed to look like > this. > > http://i.imgur.com/hefCf.png > > If anyone can tell me if these error graphs look normal or not, I'd > appreciate it! > No, they don't look normal. There is way too much wiggling going on there, even at the lowest Pgain setting. Those Pgain numbers seem very small to me, but that might be because of the way you have things scaled. I recommend that you always scale things such that you can understand the traces on halscope in physical units. Looking at your traces, motion.current-vel is in inches per second. The trace clearly ramps up to 9 inches/sec, just like you commanded. It is easy to understand what that trace means. All position signals are normally in machine units - inches in your case. So the pid.2.error trace shows a maximum error of about 0.035" in the Pgain = 12 trace. Probably not what you want, although maybe OK for a pick-n-place machine, since you really only need to be accurate at the endpoint of the move. What is not clear from your traces is the scaling of the pid output. The pid.2.output trace is scaled at 0.2 "units" per div, and at the fastest part of the move, when the axis is moving 9 inches/sec, the pid output is at 2 divisions, or 0.4 units. That means a "unit" on of pid output would make the axis move at roughly 22 inches per second. I don't know what kind of drives you have, and it makes a difference in how you tune. If you sending pid.2.output to a PWM generator and directly driving an H-bridge, then the average motor voltage will be proportional to the duty cycle, and motor speed will roughly track the voltage, with some droop under load. If you are sending the output through an analog output to a torque-mode drive, then motor current, torque, and acceleration will be proportional to the output value. (That doesn't seem to be the case here.) Finally, if you are sending the output through an analog output to a velocity mode drive, the motor speed will fairly accurately track the output, but only if the velocity loop inside the drive (NOT in EMC) is tuned. Judging from the traces, I suspect you have velocity mode servo amps, and I suspect their velocity loops aren't tuned. It doesn't make sense to tune EMC's position loop when the drive velocity loop isn't right - the position loop builds on the foundation provided by the drive. If you can tell us about your drives (and ideally post a link to a copy of the drive manual and/or specs), we can probably help more. Regards, John Kasunich -- John Kasunich [email protected] ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
