PID loop frequency

If the target is to move at constant velocity, surely the control loop shou ld be aimed at doing that.

We don't know what kind of motor you are using, but a microstepped stepper motor would be getting in-phase and quadrature sinusoidal components to do what you want, and the control loop becomes phase-locked loop, with motor d rives taken from a divided-down voltage-controlled oscillator, and the step s from the position sensor as the phase signal you are trying to lock to.

The best phase-locked loops do use product detectors to extract the phase, but most realisations lock the voltage-controlled oscillator to the zero-cr ossings in the frequency signal to which the loop is being locked, so quant isation is a well-known probelm.

Floyd M. Gardner's "Phaselock Techniques" - my copy is ISBN 0-471-04294-3 b ut it's only the second edition and there's been a third one since

goes into loop control strategies at some length.

You might look at the PWM absolute position encoders from US Digital. That makes the position update rate constant, which is a help.

NB the output is the duty cycle, not the ON time, so you have to divide by the period. The duty cycle is very stable with temperature, but the frequency drifts a bit.

Cheers

Phil Hobbs

I did something similar for just a "dumb" brushed DC motor controller PID a while back, a cascade loop worked pretty well for me. Since your goal is a constant velocity I wonder why you need a position loop? if it's just that the shaft turn at a constant angular velocity of some RPM then what its precise position is at any time doesn't seem like a relevant state variable.

I believe I used a fast sampling inner loop, PI, to achieve coarse regulation of motor torque sensed from a current shunt in series with the motor. And a slower outer loop, PID, for velocity, sensed indirectly from motor back EMF generated by the PWM drive switching waveform.

I found a little "D" coefficient in the outer loop goes a long way, at least for my little motor.

All DC motors and servos are finally current/torque driven for whatever control variable it is you want to regulate, angular position, velocity, acceleration etc. so I think it's a good idea to have torque be the primary state variable of interest in the process.

I recall a problem I encountered with my "dumb" motor with just a single PID loop that only "watched" velocity is it that a single set of coefficients which achieved good control when it's at speed are too aggressive trying to bring it up out of stall. "Oh shit 0 RPM? 10 amps, right now!!" except the PSU size I needed to use for the project size not capable of that.

Maybe do reciprocal counting - measure the time between transitions of the encoder, and from this time difference generate a velocity estimate (and run the PID) on every edge from the encoder, with variable timesteps.

fredag den 5. oktober 2018 kl. 16.07.48 UTC+2 skrev Fitzgerald:

afaik an inner velocity loop and a slower outer position loop is how it is commonly done for CNC machines and such

estimation scheme, that uses time between encoder counts at low velocity. So, every time an encoder count arrives, it is time-stamped. When the servo loop checks position, it also samples the time stamp and the current number in the time stamp counter. Thus, it can determine how long ago the last encoder state transition came in. This greatly reduces the effect of "jumpy" velocity if you just compute velocity from difference in position between last two encoder samplings.

You can look at :

which is the software encoder component to see how it was implemented. I did a hardware implementation that has a 16-bit free-running counter for the time stamps, and then the rest of the interpretation is done in a software driver.

Jon

A question regarding terms: what is a "linear encoder with quatrature output" that produces "pulses"?

Hul

Fitzgerald wrote:

Isn't everyone? ;-)

In my case, the pid loops ran at the PWM frequency.

I ended up with three PID loops:

• the innermost one managed the current through each phase of the motor. I.e. this is a torque loop.

• the next one is the RPM loop

• the outermost one is the position loop.

For high RPM, you can drive the RPM loop directly. For low RPM, you can calculate the desired position vs time and drive the position loop instead. It will lag a bit according to the holding torque, but follow the desired RPM.

I can usually keep the motors within a few counts of the desired position, at 4000 counts/rot.

There are things called linear encoders which produce a pair of square wave signals that are 90 degrees out of phase with each other. The phase relationship allows you to determine direction of motion as well as distance. The signals are identical to rotary quadrature encoders. The 90 degree phase relationship is the definition of quadrature.

The individual signals consist of pulses.

Jon

Cassette deck motors solved this a while ago. IIRC they used a bit of negative resistance, no PID. You could switched-mode it.

NT

That's what I was picturing, a circle turned into a four quadrant square. As long as it doesn't spin too fast you can count and know where you are.

George H.

The ones I dissasembled when I was doing learn by destroying had centrifugal switches on the rotor. but a recent thread on SX had a circuit which did the negative resistance thing (for a record player). if you cancel the resistance of the windings you can command the back-emf, and thus the speed, directly.

vo

egative resistance, no PID. You could switched-mode it.

As NT has pointed out, Philips was doing that thirty years ago. I put it in to a circuit I put together back in 1992 and it worked fine. You do have to kill off the negative resistance at high frequencies, but that was obvous enough that I anticipated it at the design stage.

Talking about digital control, this has been bothering me:

Say we have a PWM controller running at 100kHz switching frequency, so the period is 10us

Say we then have a digital loop that samples the voltage at 1kHz and when i t samples it calculates new PWM duty in 1us, the we will have 36 degrees ph ase lag introduced by the sampling system

That?s how the classical books determine the phase corruption

But the loop is blind for a full 1000us before it actually sampled again, s o shouldn?t the phase corruption (phase lag introduced by digital l oop), be much more than 36 degrees?

Cheers

Klaus

e period is 10us

it samples it calculates new PWM duty in 1us, the we will have 36 degrees phase lag introduced by the sampling system

so shouldn?t the phase corruption (phase lag introduced by digital loop), be much more than 36 degrees?

The saving grace in motion control is that moving parts have inertia. You h ave to keep track of where they are, but they do move pretty smoothly at th e millisecond level, and getting them to change velocity takes quite a lot of joules.

Thanks Jon.

Hul

J> > A question regarding terms: what is a "linear encoder with quatrature

the period is 10us

en it samples it calculates new PWM duty in 1us, the we will have 36 degree s phase lag introduced by the sampling system

n, so shouldn?t the phase corruption (phase lag introduced by digit al loop), be much more than 36 degrees?

have to keep track of where they are, but they do move pretty smoothly at the millisecond level, and getting them to change velocity takes quite a lo t of joules.

I think that's right, as long as you're sampling faster than the time constant of the system, your model should give a good guess at the next position, and you adjust on the difference. (I do mostly analog loops.)

George H.

the period is 10us

en it samples it calculates new PWM duty in 1us, the we will have 36 degree s phase lag introduced by the sampling system

n, so shouldn?t the phase corruption (phase lag introduced by digit al loop), be much more than 36 degrees?

have to keep track of where they are, but they do move pretty smoothly at the millisecond level, and getting them to change velocity takes quite a lo t of joules.

True, but I was thinking about power supplies, where the crossover frequenc y is typically above 1kHz, so a 1000us delay would cause a 360 degrees phas e lag, which of course is not acceptable ;-)

Cheers

Klaus

Switching to absolute encoders with continuous PWM readout (US Digital and others) makes the problem go away.

Cheers

Phil Hobbs