PID loop frequency

That's interesting. I didn't know encoders existed with a PWM output. The absolute encoders from US Digital are (unfortunately) only available in rotary form; I need a linear encoder. I'll do some searching if I can find an alternative.

The stage will be used for both point-to-point moves as well as constant velocity operation. I needed the position loop anyway; so I started using that. I will implement a cascaded loop to see if that improves performance.

Thanks for providing the link

I'll see if I can implement and test this easily; may be worth a shot but I don't expect much of it.

Measuring the time between the encoder edges doesn't seem a good solution as the time between encoder edges varies due to manufacturing errors in the encoder, see [1].

The encoder has two 50% duty cycle square wave outputs A and B. Depending on the direction of travel the A output either leads or lags the B output by 90 degrees. E.g. clockwise is AB = 10 > 11 > 01 > 00 and counter-clockwise is AB = 10 > 00 > 01 > 11.

Each edge/pulse corresponds to a fixed distance traveled by the stage. Hence, the frequency of the square wave is a measure for its velocity.

At which RPM is that? I have about 50k pulses/s input from the encoder; so that's equivalent to 750 RPM at 4000 counts/rot.

vo

should be aimed at doing that.

per motor would be getting in-phase and quadrature sinusoidal components to do what you want, and the control loop becomes phase-locked loop, with mot or drives taken from a divided-down voltage-controlled oscillator, and the steps from the position sensor as the phase signal you are trying to lock t o.

se, but most realisations lock the voltage-controlled oscillator to the zer o-crossings in the frequency signal to which the loop is being locked, so q uantisation is a well-known probelm.

-3 but it's only the second edition and there's been a third one since

Stepper motors are just synchronous motors, and micro-stepping them is esse ntially synthesising the sine and cosine waves that get applied to the wind ings to get a magnetic field that rotates at the right rate to keep the rot or moving smoothly. Obviously the magnetic field has to lead the rotor to g enerate the torque that copes with the friction in the bearings, so you nee d a position sensor to keep track of what's actually happening.

Linear synchronous motors are also interesting. I've proposed them a couple of times, and Cambridge Instruments had a photo-plotting system that moved the light source around in two dimensions with a two dimension syncrhonous motor floated off an array of permanent magnets with an air-bearing fed by compressed pumped in via a long, flexible tube.

It's a bit old, but lays out the problems neatly and systematically.

Jim Thompson seems to have had a spat with Floyd M. Gardner about sequentia l phase detectors back around the time the book was being put together - we 've seen Jim's version of the story here.

The moire fringe encoders I've worked with

had two fixed fringes on the static part, on the same substrate, to give the in-phase and quadrature outputs.

You illuminated both through the moving array of slots, and detected the light coming through the two different fixed fringes with separate light detectors.

Both average over enough slots to smooth out any difference between individual slots.

There are fancier solutions.

Whatever algorithm you use, if the encoder is inaccurate, the controlled motion will be inacurate. The only way I can see out of this is to average over a long time period (or a lot of pulses so a long distance) as you may be doing now, or with heroic effort, you could characterise and store in memory the positional error of each edge on the encoder, and use that later to correct for the encoder's manufacturing errors. Using a good encoder might be easier. Averaging over a long time period will mean that short-term perturbations will not be corrected as well as with a faster control loop.

With your existing algorithm, if you are just looking at the number of edges that you have counted at each sampling instant, then your error in the position estimate at each sampling instant can be up to +/- 90 degrees of the quadrature waveforms, in addition to any error in the encoder manufacturing. If you also timestamp the edges using hardware each time they occur, and then figure out the velocity from the time between edges, you should be able to get rid of most of the first part, so that you know pretty much exactly where in the encoder cycle you are at the time instants where an edge is detected. Only the manufacturing errors (and imperfections due to finite clock frequency of your logic) remain. I would suggest it might be a lot easier and more robust to use an FPGA than a microcontroller to do this though.

Given the choice, an encoder with a much finer pitch of lines, or one with analogue sine and cosine outputs fed to ADCs may be a better option, if a fixed sampling rate is preferred.

Moire fringe encoders average over a bunch of lines on both the moving arra y of slots and the two fixed arrays of slots that extract the in-phase and quadrature outputs.

The two fixed arrays of slots are written onto the same substrate so they s tay 90 degrees out of phase even if the mounting gets jogged - this isn't g uaranteed and idiot systems have been known to miss this, but such systems aren't popular.

You only need one single point light source to illuminate the back of the m oving array, so it casts fairly sharp shadows on the two fixed arrays. Two photodetectors - one behind the in-phase array and the other behind the qua drature array - pick up the light that gets through both.

This averages over of the order of ten slots in each set of arrays, so you aren't counting discrete edges but rather the sum over the order of ten or so sets of edges. You can play with the dimensions and the optical set up t o get more, if necessary.

You shouldn't ever be able to see the error on an individual edge.

You obviously aren't limited to time averaging. Moire fringe detection norm ally does an appreciable amount of spatial averaging, and you could fudge i t to do more if that turned out to be helpful.

The edges coming out of a moire detector aren't all that sharp (and can be made less sharp by playing with the optics).

The gratings are made by a photographic process, and could be spectacularly accurate.

It usually is, but is it worth the trouble?

There are a lot of different ways of making position encodes.

Some of them do a lot of spatial averaging. Don't waste time reinventing th e wheel.

The OP raised the issue of the encoder having inaccuracy in its edges, and posted a link to an article that speculates about this.

I said that this was not a good reason not to measure the time between the edges, and I suggested that if it is a problem, rather than my work-arounds, "Using a good encoder might be easier". I guessed that he might say that he no longer has a choice about the encoder, and so I also discussed ways to mitigate it.

I know about the spatial averaging in the moire fringe type encoders, but I assume that there will be some residual imperfection in spite of this, and I treat the encoder as a black box with whatever errors it has, for the purposes of this thread.

to

n.

of

ed

array of slots and the two fixed arrays of slots that extract the in-phase and quadrature outputs.

ey stay 90 degrees out of phase even if the mounting gets jogged - this isn 't guaranteed and idiot systems have been known to miss this, but such syst ems aren't popular.

he moving array, so it casts fairly sharp shadows on the two fixed arrays. Two photodetectors - one behind the in-phase array and the other behind the quadrature array - pick up the light that gets through both.

you aren't counting discrete edges but rather the sum over the order of ten or so sets of edges. You can play with the dimensions and the optical set up to get more, if necessary.

as

normally does an appreciable amount of spatial averaging, and you could fud ge it to do more if that turned out to be helpful.

in

be made less sharp by playing with the optics).

arly accurate.

g the wheel.

Why?

Thinking about devices as black boxes does simplify life, but it also throw s a lot of baby out with the bath-water.

Nobody has actually quantified the systematic edge-to-edge errors on any po sition encoder mentioned in this thread.

There's a link to a scheme for dealing with them if they do exist and are b ig enough to worry about, but getting excited about hypothetical errors is a well known device for getting published. It's not all that useful in real life, where you are better off working out what the errors are and where t hey are coming from before you start working on minimising them.

ote:

te:

o the period is 10us

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

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

You 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 lot of joules.

uency is typically above 1kHz, so a 1000us delay would cause a 360 degrees phase lag, which of course is not acceptable ;-)

Encoders are not used in switch mode power supplies :-)