PWM control with encoder regulation

You seem determined to do this with analog, or mostly analog, and you don't seem to like the (eminently sensible for a one-off or small run) idea of using a pre-packaged motor controller -- why?

At any rate, you don't seem to want an absolute encoder count -- you just want a velocity from the motor that you can wrap with a PID. Here's a circuit that'll do it for you; this can be done with all 7400 series logic, and a 555 for the clock:

.------. xor | | __ and xA --------|D1 Q1|----o----------| | __ xB --------|D2 Q2|--o-|--------. |==|-------| | .---|D3 Q3|--|-|--------|-|__| |& |---- up |.--|D4 Q4|--|-|----. o------------|__| || | | | | o-------------. __ clock -----o>clk | | | | | __ '--| | || | | | | | '-| | |& |---- down || '------' | | | |==|-------|__| || | | '-----|__| |'------------' | '---------------' created by Andy´s ASCII-Circuit v1.24.140803 Beta

When clocked faster than the highest frequency you'll ever see out of the motor (so, around 100kHz in your case) you'll get an "up" pulse each time the motor advances and a "down" pulse each time it retreats. You can feed the result into a difference amplifier, and the average value out will be your motor velocity. The result can go from there to a PID. If you _only_ care about rate and you can be sure that the motor will only go in one direction you can replace the above circuit with a single edge-triggered monostable multivibrator with the period set to less than the shortest pulse you'll ever see (74xx126, IIRC). Once again the average will be proportional to velocity.

Any way you slice it, you'll use up about 5 times as much board space as an AVR or PIC and you'll fiddle with it more, but it won't be any obscure digital crap!

Tim, thanks for your elaborate help!

I'm actually not determined to do it one way or another, I couldn't care less how it gets done.

I'm realllllly leaning toward the gecko drive right now. It does everything I want at a great price. Good enough to give it a try.

The reason the encoder is not absolute is because this is the encoder that we already have right now. Also, it comes preattached to the motor and is in stock. These are important factors for the design, these components were selected by other people, I'm just trying to make it work.

Good. I've seen more good solutions blocked by folks getting wrapped around the axle on trivial details.

For a one-off (or small run) project where a pre-made solution will fit the bill it's foolish to do anything else. Only if you can get economies of scale to pay for your design time, or when an off-the-shelf solution won't work, or when you're determined to learn something, should you play with custom solutions.

The most frustration I experience with this sort of thing is when an off-the-shelf solution _almost_ works, and can't be expanded, or _almost_ fits, but is just a hair too big (I always forget to do the size check with connectors on, ferinstance). But when they work it's great.

I keep harping on the encoder because I get the impression that you're a newbie, and quadrature encoders can be confusing to the uninitiated. They're simple once you get it, but it usually takes people one or two false starts.

Tim,

I couldn't agree more. I am indeed a newbie, and I'm not sure I would have enough time on this project to fully understand and implement the hardware (and software) associated with doing this myself. I have NO problem trying, though, and if the gecko doesn't work out, I may just end up doing that. I have thought of a few ways of doing this myself before even posting here, but of course, more experienced engineers can usually offer me a much better way of solving problems.

The biggest advantage, still, of using a custom solution is logistics. Even though this project is a relatively small run, the nature of the project makes it important that the components be around long enough (at least ~3-5 years) without the design changing (almost at all), so that broken systems can be repaired and such. The slightest increase in size can make a huge redesign problem that probably wouldn't be funded (at least not properly funded, you know, duct tape and zip ties).

Although the topic may be confusing, I catch on quickly and luckily I am allowed a false start or two. The gecko is seeming like a safe bet anyway..

Thanks again.

Well, the upshot of which is: you need feedback. Of course you don't need very precise feedback, but since what I proposed uses standard industry components, precise is what you get.

Your situation is, and has been, very clear from the beginning. It is also a very simple problem to solve. Your explanation (which I snipped due to length) primarily shows that you are confused about the concepts of servo motor control.

Yes. If you are familiar with stepper motors, you might think of everything to the right of the VCO as a stepper motor driver.

To make this more clear: Let's assume your motor is equipped with a standard 1000 line optical encoder wheel (that is, a wheel with

In my "schematic" above, just think of the PWM/low pass combo as DAC output.

Just measure the rpm, and work out the frequency based on the encoder specs as I have outline above. Or, even easier, connect the motor to 24V, measure the frequency of the signal coming out of the quadrature encoder, and multiply by 4. Leave some saftey margin here, otherwise the servo loop may go bonkers when you try to drive the motor to full speed.

Gosh, yes.

You need to look at the VCO data sheet.

Yes, you may have to re-activate a teeny weeny bit of high school math for this one.

Yes, of course.

VCO means Voltage Controlled Oscillator. Most people think that it would be most useful not to voltage-control the waveform or amplitude of the signal, so frequency is what the industry eventually settled on.

You might want to look at the VCO part of the 4046.

Before you come back for more it would be good if you told us what the source of the "original" PWM signal is (by any chance, a microcontroller you programmed yourself?). and what the min/max rpm of your motor is. Does the motor ever have to come to a full stop? Do you already have some kind of encoder on the motor shaft, and if you do, what kind? So-called "tacho generators" used to be common, and although they fit the bill for your app, they can't be used with the servo drive I suggested.

robert

On Tue, 11 Oct 2005 08:40:47 -0700, Tim Wescott wrote in Msg.

No! No! Don't confuse him! He's only using the VCO.

The whole servo loop stuff would be happening in a ready-bought module like the one I recommended.

Right.

Robert

Are you measuring the current? For this kind of control some form of IR compensation may be sufficient.

Robert

Don't filter the PWM, and don't run it through a VCO. Use the feedback to control the pulse width, at some convenient fixed frequency. You'd want to pick a frequency so that the motor's inductance doesn't wind up filtering the pulses.

Now, what I mean by "drive it with current", you could do something like this:

- | Diodes ^ K | | [R] - | ^ K | | | GND GND

The two silicon diodes put about 1.2V on the base - select the emitter resistor such that it drops .6V at the rated motor current - this is a simple current regulator, that supplies the motor's rated current during the pulse - the motor will drop whatever voltage it needs to.

Full torque, all the way down to 0 RPM, and surprisingly independent of the mechanical load. :-)

I know it works, because I've done it. :-)

Good Luck! Rich

I wouldn't be sending filtered PWM to the motor... I would send it to the VCO which goes to the control of the Gecko G320 motor driver. The G320 outputs its own PWM signal switching at 25kHz, which works well with my motor.

I'm still not quite sure I understand the drive it with current theory. First, I don't see how the circit can switch directions (forward, reverse), and second, I don't see an advantage over the mosfet h-bridge (commercial) I am using now? It just looks like a half bridge with a little twist? I'm sure I'm missing something, though.

I wouldn't think I would want the extra resistance in the path with the motor. The motor is rated at 6A max, but can safely (temperature permitting) operate at significanlty higher currents, depending on load. Extra resistance in the motor's path would take away from the potential torque of the motor. I mean, the motor is drawing about 2 to

Also, choosing a resistor for 6 to 10A to show a drop of 0.6V would make the resistor ~ 0.100 ohm, ~4W. This might be tough to find, although I haven't looked, and a current sense resistor may fit the bill.

What am I missing? Do you not like the Gecko drive for some reason?

Sorry. It is coming from a microcontroller that I am controlling. I have control over frequency and duty cycle. I was hoping to add external circuitry simply to allow the design to be more modular in the future. In reality I could probably share processor time to keep track of the encoder, but thinking of it as a black box would help to develop some circuitry to be used with any PWM signal in future applications.

I don't know anything about a Gecko drive, I'm just pointing out that controlling a DC motor speed by varying its voltage causes you to lose torque, as you've seen. If you drive it with a pulse at its rated current, you don't have that problem. But, yes, with the circuit I suggested (current regulator), you'd need a DPDT switch to reverse the motor.

Good Luck! Rich

On Tue, 11 Oct 2005 22:12:58 GMT, Rich Grise wrote in Msg.

We don't know where the "original" PWM comes from. For what it's worth we may think of it as a black box putting out a PWM signal. Since you don't know anything about the black box, where would you add the feedback?

In this situation, PWM -> Low Pass -> VCO -> motor controller is the only solution.

Of course if we knew more about the source of the PWM signal we could maybe suggest better solutions.

robert

On 12 Oct 2005 09:32:46 -0700, Andrew wrote in Msg.

There are 3 solutions to this problem:

From a verstility standpoint, 2 is the best. Step/direction is industry standard and will adapt to a vast variety of drivers, including stepper motor, brushless DC and servo AC. Also it's very simple to implement on the MCU side and needs only 2 output pins.

robert

The MCU is already providing the direction signal, but what do you mean by having it provide the step signal? Basically create a PWM signal with the MCU that has software variable frequency? I can definitely try to do this, rather than a VCO.

Rich, would you mind explaining how the circuit works to regulate the current? I just can't see it, I'm sorry.

On Thu, 13 Oct 2005 05:13:09 -0700, Andrew wrote: [Rich Grise wrote:]

OK. :-) Ireg v | | |/ c Vb ----------| NPN |\ e | | [R] | | GND

When you put a voltage on the base of the transistor (Vb, which you could call the "control voltage"), the transistor wants to conduct, because the base-emitter junction becomes forward biased. As the current through the transistor increases, so does the current through R, the emitter resistor. As the current through it increases, the voltage drop across it increases. When the voltage at the top of the resistor, (at the emitter) increases to approx .6V (a Vbe drop) below Vb, it wants to decrease the forward bias on the B-E junction, which wants to decrease the current through the transistor. It's kind of like a common-emitter amplifier with 100% negative feedback. There will _always_ be approx. .6V from base to emitter. Increase the voltage at Vb, the transistor conducts more, until the voltage drop across the emitter resistor comes up within Vbe of Vb, regulating the current at Ireg. And, since it's a bipolar transistor (I think this works with FETs too), the collector voltage can be anything, within the Vcemax and power dissipation limits of the transistor.

So, ignoring tolerances and stuff, Ireg = (Vb - Vbe) / R .

Mr. Hill and Mr. Horowitz also wrote this up in their book, but I don't remember under what heading, or what its "official" name is.

Hope This Helps! Rich