Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #518413 > unrolled thread

PID loop frequency

Back to article view | Back to sci.electronics.design

Contents

  PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-05 16:07 +0200
    Re: PID loop frequency bill.sloman@ieee.org - 2018-10-05 07:53 -0700
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:08 +0200
        Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 00:11 -0700
    Re: PID loop frequency Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-05 10:58 -0400
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:12 +0200
    Re: PID loop frequency bitrex <user@example.net> - 2018-10-05 10:58 -0400
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:18 +0200
    Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-06 01:04 +1000
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:30 +0200
        Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 00:21 -0700
        Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-09 23:03 +1100
          Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 05:44 -0700
            Re: PID loop frequency Chris Jones <lugnut808@spam.yahoo.com> - 2018-10-10 00:01 +1100
              Re: PID loop frequency bill.sloman@ieee.org - 2018-10-09 07:33 -0700
    Re: PID loop frequency Lasse Langwadt Christensen <langwadt@fonz.dk> - 2018-10-05 08:49 -0700
    Re: PID loop frequency Jon Elson <elson@pico-systems.com> - 2018-10-05 13:59 -0500
    Re: PID loop frequency Hul Tytus <ht@panix.com> - 2018-10-05 19:52 +0000
      Re: PID loop frequency Jon Elson <elson@pico-systems.com> - 2018-10-05 15:46 -0500
        Re: PID loop frequency George Herold <gherold@teachspin.com> - 2018-10-05 18:05 -0700
        Re: PID loop frequency Hul Tytus <ht@panix.com> - 2018-10-06 18:49 +0000
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:38 +0200
    Re: PID loop frequency DJ Delorie <dj@delorie.com> - 2018-10-05 16:19 -0400
      Re: PID loop frequency Fitzgerald <john.smith@mailinator.com> - 2018-10-09 08:48 +0200
    Re: PID loop frequency tabbypurr@gmail.com - 2018-10-05 14:33 -0700
      Re: PID loop frequency Jasen Betts <jasen@xnet.co.nz> - 2018-10-06 02:14 +0000
        Re: PID loop frequency bill.sloman@ieee.org - 2018-10-05 19:49 -0700
          Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-06 01:19 -0700
            Re: PID loop frequency bill.sloman@ieee.org - 2018-10-06 03:26 -0700
              Re: PID loop frequency George Herold <gherold@teachspin.com> - 2018-10-06 11:56 -0700
              Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-08 06:27 -0700
                Re: PID loop frequency Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-08 10:22 -0400
                  Re: PID loop frequency Klaus Kragelund <klauskvik@hotmail.com> - 2018-10-09 14:46 -0700

Page 1 of 2  [1] 2  Next page →

#518413 — PID loop frequency

I'm working on a digital PID motion controller. The target/goal is to 
move at (very) constant velocity. Position feedback is from a linear 
encoder with quadrature output. The input to the controller is a linear 
ramp (i.e. constant velocity) and the PID changes the motor output to 
minimize the error. The system works, but I'm looking to improve its 
performance at low velocities.

At low velocities there are only a few pulses from the encoder per servo 
cycle. In the error signal I can clearly see this quantization. If I 
lower the frequency of the servo cycle; the controller performance 
increases (i.e. smaller velocity variations).

Two questions:
- Is there a method to determine optimal servo frequency?
- Would it be beneficial to separate the controller in two control 
loops; an inner velocity loop and an outer position loop. Perhaps with 
both running at different frequencies?

Any pointers to good documentation are appreciated.

Thanks,
Fitzgerald

[toc] | [next] | [standalone]

#518419

On Saturday, October 6, 2018 at 12:07:48 AM UTC+10, Fitzgerald wrote:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?
> 
> Any pointers to good documentation are appreciated.

If the target is to move at constant velocity, surely the control loop should 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 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 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-crossings in the frequency signal to which the loop is being locked, so quantisation is a well-known probelm. 

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

<https://www.wiley.com/en-au/Phaselock+Techniques%2C+3rd+Edition-p-9780471430636>

goes into loop control strategies at some length.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#518791

On 10/05/2018 04:53 PM, bill.sloman@ieee.org wrote:
> On Saturday, October 6, 2018 at 12:07:48 AM UTC+10, Fitzgerald wrote:
>> I'm working on a digital PID motion controller. The target/goal is to
>> move at (very) constant velocity. Position feedback is from a linear
>> encoder with quadrature output. The input to the controller is a linear
>> ramp (i.e. constant velocity) and the PID changes the motor output to
>> minimize the error. The system works, but I'm looking to improve its
>> performance at low velocities.
>>
>> At low velocities there are only a few pulses from the encoder per servo
>> cycle. In the error signal I can clearly see this quantization. If I
>> lower the frequency of the servo cycle; the controller performance
>> increases (i.e. smaller velocity variations).
>>
>> Two questions:
>> - Is there a method to determine optimal servo frequency?
>> - Would it be beneficial to separate the controller in two control
>> loops; an inner velocity loop and an outer position loop. Perhaps with
>> both running at different frequencies?
>>
>> Any pointers to good documentation are appreciated.
> 
> If the target is to move at constant velocity, surely the control loop should 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 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 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-crossings in the frequency signal to which the loop is being locked, so quantisation is a well-known probelm.
> 
> Floyd M. Gardner's "Phaselock Techniques" - my copy is ISBN 0-471-04294-3 but it's only the second edition and there's been a third one since
> 
> <https://www.wiley.com/en-au/Phaselock+Techniques%2C+3rd+Edition-p-9780471430636>
> 
> goes into loop control strategies at some length.
> 

Unfortunately a stepper motor doesn't fit the application, but I agree 
that it is a typical good solution for slow velocity applications.

Thanks for providing the link to the book; I have ordered a copy.

[toc] | [prev] | [next] | [standalone]

#518801

On Tuesday, October 9, 2018 at 5:08:32 PM UTC+11, Fitzgerald wrote:
> On 10/05/2018 04:53 PM, bill.sloman@ieee.org wrote:
> > On Saturday, October 6, 2018 at 12:07:48 AM UTC+10, Fitzgerald wrote:
> >> I'm working on a digital PID motion controller. The target/goal is to
> >> move at (very) constant velocity. Position feedback is from a linear
> >> encoder with quadrature output. The input to the controller is a linear
> >> ramp (i.e. constant velocity) and the PID changes the motor output to
> >> minimize the error. The system works, but I'm looking to improve its
> >> performance at low velocities.
> >>
> >> At low velocities there are only a few pulses from the encoder per servo
> >> cycle. In the error signal I can clearly see this quantization. If I
> >> lower the frequency of the servo cycle; the controller performance
> >> increases (i.e. smaller velocity variations).
> >>
> >> Two questions:
> >> - Is there a method to determine optimal servo frequency?
> >> - Would it be beneficial to separate the controller in two control
> >> loops; an inner velocity loop and an outer position loop. Perhaps with
> >> both running at different frequencies?
> >>
> >> Any pointers to good documentation are appreciated.
> > 
> > If the target is to move at constant velocity, surely the control loop should 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 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 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-crossings in the frequency signal to which the loop is being locked, so quantisation is a well-known probelm.
> > 
> > Floyd M. Gardner's "Phaselock Techniques" - my copy is ISBN 0-471-04294-3 but it's only the second edition and there's been a third one since
> > 
> > <https://www.wiley.com/en-au/Phaselock+Techniques%2C+3rd+Edition-p-9780471430636>
> > 
> > goes into loop control strategies at some length.
> > 
> 
> Unfortunately a stepper motor doesn't fit the application, but I agree 
> that it is a typical good solution for slow velocity applications.

Stepper motors are just synchronous motors, and micro-stepping them is essentially synthesising the sine and cosine waves that get applied to the windings to get a magnetic field that rotates at the right rate to keep the rotor moving smoothly. Obviously the magnetic field has to lead the rotor to generate the torque that copes with the friction in the bearings, so you need 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.
 
> Thanks for providing the link to the book; I have ordered a copy.

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 sequential phase detectors back around the time the book was being put together - we've seen Jim's version of the story here.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#518420

On 10/5/18 10:07 AM, Fitzgerald wrote:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?
> 
> Any pointers to good documentation are appreciated.
> 
> Thanks,
> Fitzgerald

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



-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

[toc] | [prev] | [next] | [standalone]

#518792

On 10/05/2018 04:58 PM, Phil Hobbs wrote:
> On 10/5/18 10:07 AM, Fitzgerald wrote:
>> I'm working on a digital PID motion controller. The target/goal is to 
>> move at (very) constant velocity. Position feedback is from a linear 
>> encoder with quadrature output. The input to the controller is a 
>> linear ramp (i.e. constant velocity) and the PID changes the motor 
>> output to minimize the error. The system works, but I'm looking to 
>> improve its performance at low velocities.
>>
>> At low velocities there are only a few pulses from the encoder per 
>> servo cycle. In the error signal I can clearly see this quantization. 
>> If I lower the frequency of the servo cycle; the controller 
>> performance increases (i.e. smaller velocity variations).
>>
>> Two questions:
>> - Is there a method to determine optimal servo frequency?
>> - Would it be beneficial to separate the controller in two control 
>> loops; an inner velocity loop and an outer position loop. Perhaps with 
>> both running at different frequencies?
>>
>> Any pointers to good documentation are appreciated.
>>
>> Thanks,
>> Fitzgerald
> 
> 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
> 
> 
> 

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.

[toc] | [prev] | [next] | [standalone]

#518421

On 10/05/2018 10:07 AM, Fitzgerald wrote:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?
> 
> Any pointers to good documentation are appreciated.
> 
> Thanks,
> Fitzgerald


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.

<https://controlguru.com/the-cascade-control-architecture/>

[toc] | [prev] | [next] | [standalone]

#518794

On 10/05/2018 04:58 PM, bitrex wrote:
> On 10/05/2018 10:07 AM, Fitzgerald wrote:
>> I'm working on a digital PID motion controller. The target/goal is to 
>> move at (very) constant velocity. Position feedback is from a linear 
>> encoder with quadrature output. The input to the controller is a 
>> linear ramp (i.e. constant velocity) and the PID changes the motor 
>> output to minimize the error. The system works, but I'm looking to 
>> improve its performance at low velocities.
>>
>> At low velocities there are only a few pulses from the encoder per 
>> servo cycle. In the error signal I can clearly see this quantization. 
>> If I lower the frequency of the servo cycle; the controller 
>> performance increases (i.e. smaller velocity variations).
>>
>> Two questions:
>> - Is there a method to determine optimal servo frequency?
>> - Would it be beneficial to separate the controller in two control 
>> loops; an inner velocity loop and an outer position loop. Perhaps with 
>> both running at different frequencies?
>>
>> Any pointers to good documentation are appreciated.
>>
>> Thanks,
>> Fitzgerald
> 
> 
> 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.
> 
> <https://controlguru.com/the-cascade-control-architecture/>
> 
> 

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

[toc] | [prev] | [next] | [standalone]

#518422

On 06/10/2018 00:07, Fitzgerald wrote:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?
> 
> Any pointers to good documentation are appreciated.
> 
> Thanks,
> Fitzgerald

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.

[toc] | [prev] | [next] | [standalone]

#518795

On 10/05/2018 05:04 PM, Chris Jones wrote:
> On 06/10/2018 00:07, Fitzgerald wrote:
>> I'm working on a digital PID motion controller. The target/goal is to 
>> move at (very) constant velocity. Position feedback is from a linear 
>> encoder with quadrature output. The input to the controller is a 
>> linear ramp (i.e. constant velocity) and the PID changes the motor 
>> output to minimize the error. The system works, but I'm looking to 
>> improve its performance at low velocities.
>>
>> At low velocities there are only a few pulses from the encoder per 
>> servo cycle. In the error signal I can clearly see this quantization. 
>> If I lower the frequency of the servo cycle; the controller 
>> performance increases (i.e. smaller velocity variations).
>>
>> Two questions:
>> - Is there a method to determine optimal servo frequency?
>> - Would it be beneficial to separate the controller in two control 
>> loops; an inner velocity loop and an outer position loop. Perhaps with 
>> both running at different frequencies?
>>
>> Any pointers to good documentation are appreciated.
>>
>> Thanks,
>> Fitzgerald
> 
> 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.
> 

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].

[1] https://www.embeddedrelated.com/showarticle/444.php

[toc] | [prev] | [next] | [standalone]

#518803

On Tuesday, October 9, 2018 at 5:31:02 PM UTC+11, Fitzgerald wrote:
> On 10/05/2018 05:04 PM, Chris Jones wrote:
> > On 06/10/2018 00:07, Fitzgerald wrote:
> >> I'm working on a digital PID motion controller. The target/goal is to 
> >> move at (very) constant velocity. Position feedback is from a linear 
> >> encoder with quadrature output. The input to the controller is a 
> >> linear ramp (i.e. constant velocity) and the PID changes the motor 
> >> output to minimize the error. The system works, but I'm looking to 
> >> improve its performance at low velocities.
> >>
> >> At low velocities there are only a few pulses from the encoder per 
> >> servo cycle. In the error signal I can clearly see this quantization. 
> >> If I lower the frequency of the servo cycle; the controller 
> >> performance increases (i.e. smaller velocity variations).
> >>
> >> Two questions:
> >> - Is there a method to determine optimal servo frequency?
> >> - Would it be beneficial to separate the controller in two control 
> >> loops; an inner velocity loop and an outer position loop. Perhaps with 
> >> both running at different frequencies?
> >>
> >> Any pointers to good documentation are appreciated.
> >>
> >> Thanks,
> >> Fitzgerald
> > 
> > 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.
> > 
> 
> 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].
> 
> [1] https://www.embeddedrelated.com/showarticle/444.php

The moire fringe encoders I've worked with

http://what-when-how.com/metrology/moire-scales-and-moire-fringes-metrology/

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.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#518811

On 09/10/2018 17:30, Fitzgerald wrote:
> On 10/05/2018 05:04 PM, Chris Jones wrote:
>> On 06/10/2018 00:07, Fitzgerald wrote:
>>> I'm working on a digital PID motion controller. The target/goal is to 
>>> move at (very) constant velocity. Position feedback is from a linear 
>>> encoder with quadrature output. The input to the controller is a 
>>> linear ramp (i.e. constant velocity) and the PID changes the motor 
>>> output to minimize the error. The system works, but I'm looking to 
>>> improve its performance at low velocities.
>>>
>>> At low velocities there are only a few pulses from the encoder per 
>>> servo cycle. In the error signal I can clearly see this quantization. 
>>> If I lower the frequency of the servo cycle; the controller 
>>> performance increases (i.e. smaller velocity variations).
>>>
>>> Two questions:
>>> - Is there a method to determine optimal servo frequency?
>>> - Would it be beneficial to separate the controller in two control 
>>> loops; an inner velocity loop and an outer position loop. Perhaps 
>>> with both running at different frequencies?
>>>
>>> Any pointers to good documentation are appreciated.
>>>
>>> Thanks,
>>> Fitzgerald
>>
>> 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.
>>
> 
> 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].
> 
> [1] https://www.embeddedrelated.com/showarticle/444.php

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.

[toc] | [prev] | [next] | [standalone]

#518815

On Tuesday, October 9, 2018 at 11:03:39 PM UTC+11, Chris Jones wrote:
> On 09/10/2018 17:30, Fitzgerald wrote:
> > On 10/05/2018 05:04 PM, Chris Jones wrote:
> >> On 06/10/2018 00:07, Fitzgerald wrote:
> >>> I'm working on a digital PID motion controller. The target/goal is to 
> >>> move at (very) constant velocity. Position feedback is from a linear 
> >>> encoder with quadrature output. The input to the controller is a 
> >>> linear ramp (i.e. constant velocity) and the PID changes the motor 
> >>> output to minimize the error. The system works, but I'm looking to 
> >>> improve its performance at low velocities.
> >>>
> >>> At low velocities there are only a few pulses from the encoder per 
> >>> servo cycle. In the error signal I can clearly see this quantization. 
> >>> If I lower the frequency of the servo cycle; the controller 
> >>> performance increases (i.e. smaller velocity variations).
> >>>
> >>> Two questions:
> >>> - Is there a method to determine optimal servo frequency?
> >>> - Would it be beneficial to separate the controller in two control 
> >>> loops; an inner velocity loop and an outer position loop. Perhaps 
> >>> with both running at different frequencies?
> >>>
> >>> Any pointers to good documentation are appreciated.
> >>
> >> 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.
> > 
> > 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].
> > 
> > [1] https://www.embeddedrelated.com/showarticle/444.php
> 
> Whatever algorithm you use, if the encoder is inaccurate, the controlled 
> motion will be inacurate. 

Moire fringe encoders average over a bunch of lines on both the moving array 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 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 systems aren't popular.

You only need one single point light source to illuminate the back of the 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.

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 to get more, if necessary.

> 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. 

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

> 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.

You obviously aren't limited to time averaging. Moire fringe detection normally does an appreciable amount of spatial averaging, and you could fudge it to do more if that turned out to be helpful.
 
> 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,

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

> in addition to any error in the encoder manufacturing.

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

> 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.

It usually is, but is it worth the trouble?
 
> 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.

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

<https://www.laserfocusworld.com/articles/print/volume-32/issue-10/departments/design-and-applications/diffractive-techniques-improve-encoder-performance.html>

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

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#518816

On 09/10/2018 23:44, bill.sloman@ieee.org wrote:
> On Tuesday, October 9, 2018 at 11:03:39 PM UTC+11, Chris Jones wrote:
>> On 09/10/2018 17:30, Fitzgerald wrote:
>>> On 10/05/2018 05:04 PM, Chris Jones wrote:
>>>> On 06/10/2018 00:07, Fitzgerald wrote:
>>>>> I'm working on a digital PID motion controller. The target/goal is to
>>>>> move at (very) constant velocity. Position feedback is from a linear
>>>>> encoder with quadrature output. The input to the controller is a
>>>>> linear ramp (i.e. constant velocity) and the PID changes the motor
>>>>> output to minimize the error. The system works, but I'm looking to
>>>>> improve its performance at low velocities.
>>>>>
>>>>> At low velocities there are only a few pulses from the encoder per
>>>>> servo cycle. In the error signal I can clearly see this quantization.
>>>>> If I lower the frequency of the servo cycle; the controller
>>>>> performance increases (i.e. smaller velocity variations).
>>>>>
>>>>> Two questions:
>>>>> - Is there a method to determine optimal servo frequency?
>>>>> - Would it be beneficial to separate the controller in two control
>>>>> loops; an inner velocity loop and an outer position loop. Perhaps
>>>>> with both running at different frequencies?
>>>>>
>>>>> Any pointers to good documentation are appreciated.
>>>>
>>>> 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.
>>>
>>> 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].
>>>
>>> [1] https://www.embeddedrelated.com/showarticle/444.php
>>
>> Whatever algorithm you use, if the encoder is inaccurate, the controlled
>> motion will be inacurate.
> 
> Moire fringe encoders average over a bunch of lines on both the moving array 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 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 systems aren't popular.
> 
> You only need one single point light source to illuminate the back of the 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.
> 
> 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 to get more, if necessary.
> 
>> 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.
> 
> You shouldn't ever be able to see the error on an individual edge.
> 
>> 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.
> 
> You obviously aren't limited to time averaging. Moire fringe detection normally does an appreciable amount of spatial averaging, and you could fudge it to do more if that turned out to be helpful.
>   
>> 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,
> 
> The edges coming out of a moire detector aren't all that sharp (and can be made less sharp by playing with the optics).
> 
>> in addition to any error in the encoder manufacturing.
> 
> The gratings are made by a photographic process, and could be spectacularly accurate.
> 
>> 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.
> 
> It usually is, but is it worth the trouble?
>   
>> 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.
> 
> There are a lot of different ways of making position encodes.
> 
> <https://www.laserfocusworld.com/articles/print/volume-32/issue-10/departments/design-and-applications/diffractive-techniques-improve-encoder-performance.html>
> 
> Some of them do a lot of spatial averaging. Don't waste time reinventing the 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.

[toc] | [prev] | [next] | [standalone]

#518824

On Wednesday, October 10, 2018 at 12:02:01 AM UTC+11, Chris Jones wrote:
> On 09/10/2018 23:44, bill.sloman@ieee.org wrote:
> > On Tuesday, October 9, 2018 at 11:03:39 PM UTC+11, Chris Jones wrote:
> >> On 09/10/2018 17:30, Fitzgerald wrote:
> >>> On 10/05/2018 05:04 PM, Chris Jones wrote:
> >>>> On 06/10/2018 00:07, Fitzgerald wrote:
> >>>>> I'm working on a digital PID motion controller. The target/goal is to
> >>>>> move at (very) constant velocity. Position feedback is from a linear
> >>>>> encoder with quadrature output. The input to the controller is a
> >>>>> linear ramp (i.e. constant velocity) and the PID changes the motor
> >>>>> output to minimize the error. The system works, but I'm looking to
> >>>>> improve its performance at low velocities.
> >>>>>
> >>>>> At low velocities there are only a few pulses from the encoder per
> >>>>> servo cycle. In the error signal I can clearly see this quantization.
> >>>>> If I lower the frequency of the servo cycle; the controller
> >>>>> performance increases (i.e. smaller velocity variations).
> >>>>>
> >>>>> Two questions:
> >>>>> - Is there a method to determine optimal servo frequency?
> >>>>> - Would it be beneficial to separate the controller in two control
> >>>>> loops; an inner velocity loop and an outer position loop. Perhaps
> >>>>> with both running at different frequencies?
> >>>>>
> >>>>> Any pointers to good documentation are appreciated.
> >>>>
> >>>> 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.
> >>>
> >>> 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].
> >>>
> >>> [1] https://www.embeddedrelated.com/showarticle/444.php
> >>
> >> Whatever algorithm you use, if the encoder is inaccurate, the controlled
> >> motion will be inacurate.
> > 
> > Moire fringe encoders average over a bunch of lines on both the moving array 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 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 systems aren't popular.
> > 
> > You only need one single point light source to illuminate the back of the 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.
> > 
> > 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 to get more, if necessary.
> > 
> >> 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.
> > 
> > You shouldn't ever be able to see the error on an individual edge.
> > 
> >> 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.
> > 
> > You obviously aren't limited to time averaging. Moire fringe detection normally does an appreciable amount of spatial averaging, and you could fudge it to do more if that turned out to be helpful.
> >   
> >> 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,
> > 
> > The edges coming out of a moire detector aren't all that sharp (and can be made less sharp by playing with the optics).
> > 
> >> in addition to any error in the encoder manufacturing.
> > 
> > The gratings are made by a photographic process, and could be spectacularly accurate.
> > 
> >> 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.
> > 
> > It usually is, but is it worth the trouble?
> >   
> >> 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.
> > 
> > There are a lot of different ways of making position encodes.
> > 
> > <https://www.laserfocusworld.com/articles/print/volume-32/issue-10/departments/design-and-applications/diffractive-techniques-improve-encoder-performance.html>
> > 
> > Some of them do a lot of spatial averaging. Don't waste time reinventing the 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,

Why? 

> and I treat the encoder as a black box with whatever errors it 
> has, for the purposes of this thread.

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

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

There's a link to a scheme for dealing with them if they do exist and are big 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 they are coming from before you start working on minimising them.

-- 
Bill Sloman, Sydney

[toc] | [prev] | [next] | [standalone]

#518427

fredag den 5. oktober 2018 kl. 16.07.48 UTC+2 skrev Fitzgerald:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?
> 
> Any pointers to good documentation are appreciated.
> 
> Thanks,
> Fitzgerald

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

[toc] | [prev] | [next] | [standalone]

#518449

On Fri, 05 Oct 2018 16:07:41 +0200, Fitzgerald wrote:

> I'm working on a digital PID motion controller. The target/goal is to
> move at (very) constant velocity. Position feedback is from a linear
> encoder with quadrature output. The input to the controller is a linear
> ramp (i.e. constant velocity) and the PID changes the motor output to
> minimize the error. The system works, but I'm looking to improve its
> performance at low velocities.
> 
> At low velocities there are only a few pulses from the encoder per servo
> cycle. In the error signal I can clearly see this quantization. If I
> lower the frequency of the servo cycle; the controller performance
> increases (i.e. smaller velocity variations).
> 
> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control
> loops; an inner velocity loop and an outer position loop. Perhaps with
> both running at different frequencies?
>We do this in LinuxCNC.  Many of the encoder counters use a velocity 
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 :
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/
encoder.c

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

[toc] | [prev] | [next] | [standalone]

#518454

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

Hul

Fitzgerald <john.smith@mailinator.com> wrote:
> I'm working on a digital PID motion controller. The target/goal is to 
> move at (very) constant velocity. Position feedback is from a linear 
> encoder with quadrature output. The input to the controller is a linear 
> ramp (i.e. constant velocity) and the PID changes the motor output to 
> minimize the error. The system works, but I'm looking to improve its 
> performance at low velocities.

> At low velocities there are only a few pulses from the encoder per servo 
> cycle. In the error signal I can clearly see this quantization. If I 
> lower the frequency of the servo cycle; the controller performance 
> increases (i.e. smaller velocity variations).

> Two questions:
> - Is there a method to determine optimal servo frequency?
> - Would it be beneficial to separate the controller in two control 
> loops; an inner velocity loop and an outer position loop. Perhaps with 
> both running at different frequencies?

> Any pointers to good documentation are appreciated.

> Thanks,
> Fitzgerald

[toc] | [prev] | [next] | [standalone]

#518458

On Fri, 05 Oct 2018 19:52:00 +0000, Hul Tytus wrote:

> A question regarding terms: what is a "linear encoder with quatrature
> output" that produces "pulses"?
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

[toc] | [prev] | [next] | [standalone]

#518490

On Friday, October 5, 2018 at 4:46:19 PM UTC-4, Jon Elson wrote:
> On Fri, 05 Oct 2018 19:52:00 +0000, Hul Tytus wrote:
> 
> > A question regarding terms: what is a "linear encoder with quatrature
> > output" that produces "pulses"?
> 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

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. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.electronics.design

csiph-web