Encoders - API??? (possibly of interest only to programmers)
Posted by
The AntiYuppie
on 2001-04-04 22:24:34 UTC
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
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....
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 thinkYou 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....
Discussion Thread
The AntiYuppie
2001-04-04 22:24:34 UTC
Encoders - API??? (possibly of interest only to programmers)
Larry Edington
2001-04-05 00:21:12 UTC
Re: [CAD_CAM_EDM_DRO] Encoders - API??? (possibly of interest only to programmers)
Tony Jeffree
2001-04-05 00:30:47 UTC
Re: Encoders - API??? (possibly of interest only to programmers)
Ray
2001-04-05 09:39:06 UTC
Re: Re: Encoders - API??? (possibly of interest only to programmers)
Hugh Prescott
2001-04-05 10:12:15 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: Encoders - API??? (possibly of interest only to programmers)
mariss92705@y...
2001-04-05 10:28:12 UTC
Re: Encoders - API??? (possibly of interest only to programmers)
Hugh Prescott
2001-04-05 16:07:24 UTC
Re: [CAD_CAM_EDM_DRO] Re: Encoders - API??? (possibly of interest only to programmers)