Re: [CAD_CAM_EDM_DRO] Encoders - API??? (possibly of interest only to programmers)

As I see it the micro must have a way of knowing which direction the encoder
is turning to increment and decrement a counter. The stepper drivers's
direction signal would be one way. But I don't see how a non quadrature
encoder can be reliable. Let's say you are using this as an encoder on a
stepper motor. The stepper is commanded to move clockwise 100 steps. Let's
also say clockwise is incrementing the counter. Now let's say the stepper
moves 98 steps clockwise and the axis is bound due to some increased load
( like a cutter just contacted metal to be cut ). Now the stepper fails to
move the additional two steps and due to twisting in the lead screw actually
backs up 2 steps. Your counter is 2 steps off with that one command because
the encoder doesn't know it just turned backwards and the step signal was
still saying clockwise. Add a few hundred thousand of these type cycles and
your position value becomes hopelessly inaccurate.

What you could do with these encoders is measure velocity. I just don't see
how you'll get practical direction sensing with the realities of mechanical
devices.

One thing I've thought about trying with an encoder and a PIC is monitor the
step and direction pulses and read an encoder. Using a PIC with an interrupt
on PORTB change feature could control 2 steppers per chip as any change on
PORTB generates an interrupt. The idea is the PIC counts the number of steps
commanded, the direction commanded, and monitors the encoder to ensure the
command motion actually happened. If the encoder gets out of sync with the
commanded motion a fault signal is asserted. You could also hang an LCD
display off it and show which direction the error is in and how many steps
it's off. That would allow manual intervention. Add a little creeping
elegance and it might even attempt to issue step and direction commands to
fix the determined error. A self correction circuit so to speak.
An automatic backlash compensator? Another waste of a lot of code?

Maybe a worthless device but maybe not. Maybe I'm just too tired to think
clearly?

later,
Larry E.

----- Original Message -----
From: "The AntiYuppie" <sloboyko@...>
To: <CAD_CAM_EDM_DRO@yahoogroups.com>
Sent: Wednesday, April 04, 2001 11:24 PM
Subject: [CAD_CAM_EDM_DRO] Encoders - API??? (possibly of interest only to
programmers)


> I just found a supply of super quality, small, ball bearing, 1000
> count shaft encoders at a really good price. But, there is a catch.
> They are not quadrature encoded (meaning, that you can't really
> detect direction).They just put out A TTL pulse when the encoder
> moves.
>
> However, if you already know what direction you are going in, this
> might not really matter. I've been considering writing a PIC or
> Scenix program with an RS232 based API that might interface to PC
> type programs (yes, I know that you could do interrupts via the
> serial port on a PC (the RI line, for example), but this is a pain to
> write and most PC's are awfully busy for this...
>
> Questions:
>
> 1. Does a kinda sorta industry standard API exist for this sort of
> application?
>
> 2. If not, what would you think of the following API (rs232, 9600
> baud)
>
> R - resets all counters (up to 3 (axes)) to zero. Also used to
> initialize.
>
> S<XXXX><XXXX><XXXX> (see below for description of <XXXX>)
>
> Sets a "trap" to each counter at a certain number of counts. 0 turns
> this capability off. upon count, you get:
>
> T<bitpattern>
> where the first 3 LSB bits represent the count above being hit.
>
> Note that it would be a BAD IDEA to set the counts to 1, and then
> spin the motor at 3600 rpm (for instance). Although I intend to have
> some "buffer" depth, eventually, traps would be lost, because of the
> 9600 baud communication limits.
>
> The S command remains in effect until any other command is sent.
>
> R
>
> Reads as follows
>
> <XXXX><XXXX><XXXX>
>
> Also sets all counters to zero (but note that counts are NOT lost -
> the PIC firmware will be interrupt driven, and should be good for
> >5000 counts per second, adequate for steppers, I think
>
>
> You must NOT send a command requiring a response unless you have
> received a complete return from the previous command (due to my non-
> brilliant coding and RAM limitations within the PIC/Scenix)
>
> <XXXX> above, from 0-65535, are four bytes representing:
>
> LOW WORD HIGH WORD
> LOW BYTE HIGH BYTE LOW BYTE HIGH BYTE
>
> An unsigned, 32 bit integer, which just happens to be the native
> internal format of many machines, and if not, it's easy to swap words
> and bytes.
>
> I am also researching this for one of my myriad other hobbies,
> astronomy (telescope control with steppers and computers).
>
> Comments welcomed....
>
>
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the
discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
> Addresses:
> Post message: CAD_CAM_EDM_DRO@yahoogroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@yahoogroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@yahoogroups.com
> List owner: CAD_CAM_EDM_DRO-owner@yahoogroups.com, wanliker@...
> Moderator: jmelson@... timg@... [Moderator]
> URL to this page: http://groups.yahoo.com/group/CAD_CAM_EDM_DRO
> bill,
> List Manager
>
> FAQ: http://www.ktmarketing.com/faq.html
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>