CAD CAM EDM DRO - Yahoo Group Archive

Encoders

Posted by Ted Robbins
on 1999-07-15 10:16:02 UTC
The purpose of that long transmission on encoders was to give interested
folks a feel for the kinds of decisions they have to make when they get
that deep into DRO's. This will expand on some of the decisions and the
information you need to make them.

First let's look at one method of increasing the resolution of encoders
using differential amplifiers. It's a pretty simple method, but there are
some limitations. If the encoder has high resolution and uses moire fringe
sensing, ie; there is a mask with one more (or less? I forget) line on the
mask over the photosensor, the photosensor will see a sine wave once per
slot. It really is a sine wave, but it has some problems. The amplitude
changes with rotation speed. This means you must either compare each
differential amplifier with a reference voltage which is itself the result
of averaging the last few peaks as the waveforms pass by, use only the
quadrature information until the encoder is turning quite slowly, or add
another sensor in each channel which will be 180 degrees out of phase to
give you something to compare which is sized to the speed. I am not really
sure how to nmake this double sensor method work.) The easiest way is to
use quadrature until you are moving slowly. You generally don't need the
fine resolution until you are nearly stopped anyway.

Hot line, the method where the sensor looks through a few lines of the same
resolution as the disk, or a single aperature smaller than the slots in the
disk, just switches the photo device on and off at the edges. When moved
slowly it approximates a square wave so you can't use differential
amplifiers to set sine wave voltage switch points to increase resolution.
At higher speeds it approximates a square wave, but that is a result of
reaching the turn-on and turn-off delays of the photosensor.

Noise problems include electrical noise normal in a machine shop, and
vibration on a counting edge when the machine is stopped and the spindle is
shaking the table as it turns(for instance.) Schmidt triggers and other
debouncing circuits are absolutely necesary to avoid false counts. In
addition, it is useful to reduce noise sensitivity by using relatively slow
logic families and devices. They are fast enough to get the information
you need, but slow enough to ignore electrical noise. The adjustable
debouncing circuits that are based on internal counters work very well for
mechanical vibration miscounts. Ferrite beads help keep noise from
spreading on Vcc and Ground, but decent layout techniques are still
required.

The designer must control the speed of response of each circuit and be
aware of all circuit delays and latencies. The gating circuits must be
faster than the edge sensing circuits, or errors will be introduced. If
you are going to drive seven segment readouts or their equivilant
directly, you must include enough speed in the zero detection circuits to
switch the pulse steering circuits ahead of the first pulse coming after
the mechanical zero point you have set by zeroing the counter.

Switching, steering, and counting circuits depend on the logic families
used, and the state of development of appropriate algorithms. I developed
the first encoder driven product with DTL- That's Diode-Transistor-Logic,
the next one with TTL and MSI- thats Medium Scale Integration, and the last
one with CMOS. If I were to do one today, I would probably use a PLA of
some sort. Of course, the point of my last diatribe on this subject is
that I wouldn't. There are much better dedicated products you can use.
Red Lion Controls probably still makes some inexpensive devices. The
opposite approach, which offers a different set of tradeoffs, allows you to
use a PC. ie; Dan Mauch's approach. I chose that one for a couple of
current projects. It has the right set of tradeoffs for those particular
projects.

If you really want to design the circuits that come after the encoders, get
the (free) applications manuals from the manufacturers of current logic
devices.

When I started, we designed circuits from tubes, transistors, resistors and
capacitors. Today physicists design the passive and active components and
hybrid physicist/EE's design the circuits they are used in. We get them as
black boxes. In general this makes us more productive. When this process
gets top heavy or too proprietary, as it has in Bill's and other software,
people get fed up. Linux and other open software is the delightful result.
Microcoding of microprocessors was a similar process. It led to reduced
instruction set microprocessors when it got too topheavy. Still Bill
satisfies a lot of people's needs, and increasingly rich instruction sets
statisfy a lot of microprocessor application needs.

If your need is to build from scratch for its own sake, enjoy. I don't
believe it will save you any money. Putting together surplus stuff with a
judicious mixture of current stuff will give you a decent trade off between
time and dollars. Some of the people on this list are making or pointing
us toward, some of the missing links many of us need. If you want to
provide some of those missing links, that would be valuable to many of us,
and hopefully profitable to you. If you want to make chips in the
forseeable future, try this middle ground between discreet devices and
store bought complete systems.

Discussion Thread

Jon Elson 1999-06-28 23:31:30 UTC Re: Encoders Tim Goldstein 1999-06-29 16:27:22 UTC Re: Encoders Jon Elson 1999-06-29 23:25:29 UTC Re: Encoders Tim Goldstein 1999-06-30 08:08:50 UTC Re: Encoders Dan Mauch 1999-06-30 08:40:01 UTC Re: Encoders Jon Elson 1999-06-30 23:04:21 UTC Re: Encoders Laverne Karras 1999-07-01 18:26:50 UTC Re: Encoders Ron Brown 1999-07-11 07:03:23 UTC Encoders Ted Robbins 1999-07-15 10:16:02 UTC Encoders William Scalione 2000-06-15 18:40:55 UTC Encoders Ian Wright 2001-08-27 05:27:33 UTC Encoders Jon Elson 2001-08-27 11:46:07 UTC Re: [CAD_CAM_EDM_DRO] Encoders Ian Wright 2001-08-27 12:47:29 UTC Re: [CAD_CAM_EDM_DRO] Encoders Alan Marconett KM6VV 2001-08-27 12:51:11 UTC Re: [CAD_CAM_EDM_DRO] Encoders Jon Elson 2001-08-27 21:15:03 UTC Re: [CAD_CAM_EDM_DRO] Encoders Joseph 2001-08-27 22:47:10 UTC Re: Encoders Frank Cohn 2001-10-16 01:46:03 UTC Encoders Alan Marconett KM6VV 2001-10-16 10:41:19 UTC Re: [CAD_CAM_EDM_DRO] Encoders marble_h 2002-02-02 19:21:24 UTC Encoders Lew 2002-02-02 19:29:54 UTC RE: [CAD_CAM_EDM_DRO] Encoders marble_h 2002-02-02 19:53:40 UTC Re: Encoders Francisco Simon 2002-10-11 02:56:36 UTC Encoders dakota8833 2002-10-11 06:43:24 UTC Re: Encoders marc_e_davis 2002-11-20 11:23:29 UTC Encoders deanc500 2002-11-20 11:55:35 UTC Re: Encoders Tim Goldstein 2002-11-20 12:44:25 UTC Re: [CAD_CAM_EDM_DRO] Encoders Bob Simon 2002-11-20 16:52:46 UTC Re: [CAD_CAM_EDM_DRO] Encoders Jon Elson 2002-11-20 21:26:39 UTC Re: [CAD_CAM_EDM_DRO] Encoders Tim Goldstein 2003-12-24 21:45:45 UTC Re:Re: Encoders Tony Jeffree 2003-12-25 00:02:39 UTC Re: [CAD_CAM_EDM_DRO] Re:Re: Encoders Tim Goldstein 2003-12-25 09:02:30 UTC RE: [CAD_CAM_EDM_DRO] Encoders Jon Elson 2003-12-25 11:21:06 UTC Re: [CAD_CAM_EDM_DRO] Re:Re: Encoders Gregory Kamysz 2003-12-25 13:57:57 UTC Re: [CAD_CAM_EDM_DRO] Re:Re: Encoders Tony Jeffree 2003-12-25 15:20:36 UTC RE: [CAD_CAM_EDM_DRO] Encoders Bruce Pigeon 2005-02-15 09:07:58 UTC Encoders Ron Kline 2005-02-15 18:01:48 UTC Caps ?? Dave Fisher 2005-02-15 18:19:20 UTC RE: [CAD_CAM_EDM_DRO] Caps ?? R Rogers 2005-02-15 18:19:59 UTC Re: [CAD_CAM_EDM_DRO] Caps ?? JanRwl@A... 2005-02-16 16:41:40 UTC Re: [CAD_CAM_EDM_DRO] Caps ?? Robert Campbell 2005-02-16 16:48:34 UTC Re: [CAD_CAM_EDM_DRO] Caps ?? JanRwl@A... 2005-02-16 22:40:17 UTC Re: [CAD_CAM_EDM_DRO] Caps ?? pwshahood 2005-02-17 10:45:30 UTC Re: Caps ??