Hi Mario There really is no good way to equate a stepper's digital motion with a velocity servo's analog motion. Many of the big time control makers try to get round this by using very high count encoders. Many of these are more than 2Meg counts per revolution. These kinds of systems still work in position mode rather than velocity mode. Anytime you specify a position -- move one step or move to xx -- without specifying a velocity to achieve that move you will have a sawtooth finish.
The last time I used real closed loop servos with the EMC, I found that it could command very small velocities. Voltages of about 0.002 on a 10 volt scale were easily possible. There were a few issues back then where the absence of an encoder tick during a PID cycle led to ramping velocities. A good velocity controlled system should be able to cut a 0.0005 taper across 15 inches on a lathe. If you run that with a direct coupled stepper with a 64 microstep driver and a 5 TPI ballscrew you would have a bit more than two microsteps per inch. These would easily be visible to the operator where a real taper would not. Furthermore microstepping a motor causes a rapid loss of positioning accuracy. You would not really get 64 discrete equal angular positions between adjacent steps. Even 10 microsteps from a Gecko or equivalent drive doesn't produce equally spaced angular moves. Quite a bit of work has been done using PLL schemes to attempt to increase resolution. These systems can work fairly well at constant velocities but suffer errors during changes in velocity. Hope this helps Rayh On Thu, 2006-12-28 at 21:19 +0100, Mario. wrote: > 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 > ------------------------------------------------------------------------- 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
