Sebastian Kuzminsky wrote: > I'm playing around with EMC, trying to control a small brushed DC motor. > The parallel port controls an H-bridge circuit which feeds power to > the motor. The motor has a 256-line encoder on the motor shaft, which > I read through the parallel port. > > The fastest thread my PC can run reliably is about 40 KHz, so that's > how fast I'm reading the encoder lines. This really puts a damper > on my top motor speed. > > Let L be the number of lines on the encoder. Let R be the speed of > the motor in revolutions per minute. > > (4 * L) is the number of quadrature transitions per revolution. > > (R / 60) is the number of revolutions per second. > > (4*L) * (R/60) is the number of quadrature transitions per second. > > F = 2 * (4*L) * (R/60) is the minimum sampling frequency for reliable > operations (according to Nyquist, as I understand it). > > > If F = 40 KHz and L = 256, then R = 1170 RPM. Experimentally, I can push > the speed a bit higher than this before it starts missing transitions and > losing position. I guess that factor of two (Nyquist) is conservative? > Because of the quadrature, the encoder signals are not 1/2 the count rate, but 1/4. Still, due to variations in the width of the 4 states per cycle, you have to leave some leeway for that variation. If you entirely miss even one state, it is impossible to determine which directiion the missed state was in. (At 1000+ RPM, you can take an educated guess, but the hardware shouldn't have to do that.)
Sampling motor encoders with software is a really bad idea for this reason, unlsss the encoder resolution is very low and the motors slow. > Anyway, this is much slower than the top speed of the motor. I think > there are two ways to deal with this situation: > > The prefered way is to read the encoder lines much faster, say 10x. > This is hard over a parallel port, but easily doable on dedicated > hardware like the Pluto-P or similar. > > The alternative, if option 1 isn't possible, is to limit the motor > speed. That is what I want to ask about in this email. > > > I've determined that with no load on the motor shaft, stepping the > PWM duty cycle from 0 to 100% causes the motor to accelerate from a > stand-still to the 1200 RPM limit in about 75 us. > > My plan for trying to limit the motor shaft speed is to run a two-level > PID controller. The first PID controller tries to achieve the target > position using encoder.position as feedback. The output from the > position PID controller goes not to the pulse generator, but to the > command for the velocity PID controller. The velocity PID controller > uses encoder.velocity as feedback, and *its* output goes to pwmgen.value. > > I'll run the velocity PID controller in a relatively fast thread (no > more than 75 us period), but the position PID controller can run at the > usual rate of 1 KHz or so. A very interesting idea! If you can actually get this simple thread to run that fast, it will be sort of a software velocity servo amp. A classic 3-loop servo system has an inner current or torque loop, which compares actual motor current to the velocity error. A tach or tach simulator is used to compare actual velocity to the velocity command. Only the outer (positioning) loop involves the computer, and sends a commanded velocity to the velocity error amp. So, the one thing you are leaving out here is the current loop. If the motor has a lot of inductance, then the motor current can lag the voltage by quite a bit, and this can cause instability. I'd be very interested to see how this works out! Jon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
