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? > > 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.
Wow. And wow again. That is one VERY low inertia motor, or an astonishing amount of torque, or both. Zero to 1200 RPM in 75uS is 16,000 RPM per millisecond. I don't know what the top speed of the motor is, but it sounds like it can get there in at most a couple milliseconds. That's remarkable performance. You might want to connect it to your actual load and measure the accel rate again. If it is a very low inertia motor, you might find that the load inertia gets the accel rate down to something a little less astonishing, and a lot easier to deal with. > 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. > > > Does this seem feasible? Or am I barking up the wrong tree? > The problem is going to be getting usable velocity feedback. Your encoder sampling is at 25uS, and your PID is running at 75uS. That means in any one PID period, you get either 0, 1, 2, or 3 encoder counts. Not much resolution. Regards, John Kasunich ------------------------------------------------------------------------- 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
