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

Hi,

Sounds like some nice parts if they are cheap. You mention that the
user would "know" the direction, but if you are implementing a counter
in the PIC, then the PIC would have to know which direction too! I
guess you could run a line from the direction line going to each driver
(step/dir). I think I'd try to emulate the DRO boards that Dan has.
Just a thought. Protocol would be useable, I'd add a "sync" char to the
read format, and possibly a "checksum". Still trying to decide if I'd
like a "trap". If I commanded a location I wanted to move to, I'd need
to decelerate BEFORE I got there, and I wouldn't want to "feel around"
to get to the target.

Just some thoughts, hope you can use them!

Alan KM6VV
(still looking for a third HP HEDS 6100 encoder).

The AntiYuppie wrote:

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