If power rating for the slow motion would be ~10W or so, a big, fast microstepper stepper motor, like the Shinano Kenshi SKC83D I use could do the job. With 250 microsteps per electrical phase I get 12500 microsteps per revolution, what can get you really fluent motion.
But that is the system of things I like to use, your conditions may vary. On 12/28/06, Jon Elson <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
