Anders Wallin wrote: >Hi all, > >With a servo system using quadrature encoder feedback, what is the >slowest speed that can reliably be used ? > >I would imagine that there is a problem if there are no counts between >successive calls to the PID loop ? resulting in jerky instead of smooth >slow motion ? > > > There are two ways to solve this. The "old" way is with a true velocity servo, which uses a DC tachometer to sense velocity in continuous-time, thereby getting around the quantizing nature of an encoder.
The other way is to increase encoder resolution. I have a velocity servo on my Bridgeport, and did some tests when I first got it set up to see how well it did. I was truly amazed at how well the tach closed the loop. I can shut off the EMC positioning servo response by hitting F1 but not F2 so that EMC is in the "Estop reset" state. I can grab the leadscrew pulley and yank on it, and the encoder barely changes until I reach the current limit on the servo amp. With EMC in the normal mode, I was able to go down to .01 IPM (.254 mm/Min) before I got stick/slip friction overcoming the velocity gain of the system. This was with 3 encoder counts/second, but the nature of the PID loop is that if the encoder position shows the system is where it should be, then there will be no deviation of the velocity command. So, the tach and velocity loop were really in control there. The tach output was calculated at 7 uV, no way I could measure it, though. Without the velocity sensing, it would require a much higher encoder resolution. >any way to improve on this using some smart HAL code ? > >The setup I'm planning would use a 1000 line encoder (4000counts/rev) >motor directly coupled to a 2.5mm/rev ballscrew. If I require one count >for each call to the PID loop (1 kHz count rate) then that works out to >0.25rev/s or 15 rpm or a feedrate of 37.5mm/min which does not seem that >low ?? > > That really won't accomplish what you want. Even if there's one encoder count per servo cycle, then you get quantized to zero, one or two counts/cycle. That is still a VERY rough reading of velocity! So, you have to put in a lot of the D term to damp down these fluctuations. Fortunately, there really isn't much of a velocity loop in the PID calculation, the only term that uses it is D. Most of the loop's response is due to instantaneous error, or commanded position - actual pos. This is a much "softer" term, mathematically. So, the PID adjusts commanded velocity based on the trends in position error Without an analog velocity sensor, you are totally at the mercy of the encoder's quantization. I don't think there is any way for software to improve on that at low velocity. It has no way to know when the next encoder count will occur! And, you will not see gigantic fluctuations in actual velocity when you drop below one encoder count / servo cycle. That's what the D term is there for, and you might as well call it "damping". When the encoder counts are coming in at a rate below the entire system's response bandwidth, then you WILL see fluctuations. If you tune the PID correctly, they still won't be large, but they will develop. Depending on the machine (the iron), the motors, servo drives and the tuning, the real bandwidth may be from a few Hz up to 10's of Hz, but not likely more for a milling machine. You will have 1600 counts/mm, so a rate of 0.5 mm/min will give encoder counts at 1600 / 120 = 13.33 encoder counts/second. I think that might be about where the bumps will show up. With proper tuning, they shouldn't be too bad. If you need to maintain smoothness at/below that rate, then your only choices are higher encoder resolution or a change to a velocity servo. Jon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
