RE: [CAD_CAM_EDM_DRO] PIC based DRO

From: beer@...

OK, a few things to clarify here.

1. I HAVE built a PIC based DRO. The electronics DO work. It's
actually a fairly simple programming task.

[Paul Devey]
What language/compiler/assembler did you use?

The unit displays absolute and relative positions, with a reset for
both. No other fancyness, because I just don't care. ( Metric
conversion, lathe "X2" mode, etc. )

[Paul Devey]
Simple key/keyboard input I presume?

The DRO is not yet in use because the mechanicals are a bit of a
problem. I can't get ABSOLUTELY reliable repeatability out of my
rotary encoder setup. But the electronics work just fine.

[Paul Devey]
I am sure many on this list may benefit from any of your experience. I know
I would appreciate hearing about it.

2. It IS inexpensive. A mid-level PIC, an LCD and not much else. And
LCDs are pretty cheap these days. I bought some backlit ones for $7.00
USD

I used LCDs instead of LEDs because

my shop is BRIGHT, 32 feet of flourescents in 70 sq feet and I was
worried about the LEDs washing out
it's actually cheaper ! when the cost of PCB real estate is considered
I could display text messages, like ERROR

[Paul Devey]
I like non-cryptic messaging.

3. The "problem" with a PIC based controller is that there is no easy
way to input all the possible the scale parameters. That is, I have
written code for use with a 2000 cpr codewheel. I cannot now take this
device and use it with the 360 cpi linear strip. I'd have to write new
code and program a new PIC.

In a strange twist, the above "problem" actually solves the floating
point "problem", since there is no way to enter "unusual" resolutions.
Things are simply custom coded for a particular resolution using integer
math.

( The PIC could contain code for the most "common" scale settings, I
suppose. )

4. Even with the math being integer math, I wimped out when doing the
DRO/Stepper controller. I used a second small PIC to convert quadrature
to clock/dir info. This relieved the main PIC of some processing. I
was a bit worried about race conditions, determinism, and my ability to
be SURE that no counts would be missed doing it all in a single PIC.

SOLVING the problem by adding a one dollar part seemed like a good
design choice.

I got a lot of "advice" (trans: crap) on RCM from people who had never
programmed offering advice on their better ideas for solving my
problem. NONE of them offered any actual code, of course, just abuse.

[Paul Devey]
Never accept free advice. Trust me on this.

5. Scales are a problem, and as attractive as those Goldmine rotary
encoders are, I keep being drawn to linear strips, even though the
resolution is lower than I would like.

Both have problems, especially below .001"/count. With linear strips, a
person is relying pretty heavily on the linearity of the ballscrews in
the photoplotter that created them in the first place.

Rotary encoders have the problem of both slippage and scale. A person
cannot, by definition, machine a pulley to precisely the right diameter
(that pesky PI thing). And even if he can get it "close enough", how can
he be SURE that it's close.

Every technique I've encountered for testing the accuracy once on the
machine ( no sense testing it off the machine ) has some fundamental
assumption that makes me uncomfortable.

Frankly, my standard eBay search these days is for "+DRO +scale".



Alan


P.S. I believe that the Sherline DRO uses an 8051.

[Paul Devey]
It would be interesting to hear from anyone who has this beastie. What type
of encoders/CPU/chips are they using? Does this device have repeatability
etc.

Alan, you have put much thought and effort into your DRO. Many of us could
benefit from more info on your experiences. Of course I am buttering you
up. Do you feel comfortable contributing your DRO design to this community?
It probably would not be long before others contribute their efforts in
ways that will also benefit you.

Paul