Searching \ for 'optical encoders to PIC to LPT port adv' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=encoder
Search entire site for: 'optical encoders to PIC to LPT port adv'.

Truncated match.
PICList Thread
'optical encoders to PIC to LPT port adv'
1997\08\19@152621 by Berg, Russ: SAS

flavicon
face
Hi, quick background then my question:
I am currently plowing away through a project that uses a 16c55 @ 4mhz takes
input of 2 pins each from 2 high precision encoders (PORTA), one encoder per
axis on a telescope, each encoder puts out about 4048 codes / revolution,
what I am doing is reading the encoder pins with the PIC and keeping track
of a 2 byte variable per axis (Right Ascention and Declination) as part of
the routine I am polling a pin from the LPT port that acts like an interrupt
to the PIC so that the 2 byte variable can be placed on the 0-3 pins of
PORTC one nibble at a time, (I am restricted to 4 pins to 0x379 for input to
the pc) then the pic goes back to tracking the transitions of each encoder,
the goal for me here is to be able to manually rotate the telescope at a
reasonable rate and not loose accuracy as well as update my computer program
in quasi real time, for me a reasonable rate would be 90 degrees in 1 to 2
seconds which would be roughly 1012 codes per 1.5 seconds.

Question:
given the above information does this sound like the proper way to approach
this project or is there a better / easier or more efficient way of
attaining my goal. Maybe I have missed something obvious?

Thanks very much in advance.
-Russ

1997\08\19@155639 by Mike

flavicon
face
At 03:04 PM 8/19/97 -0400, you wrote:

>Question:
> given the above information does this sound like the proper way to approach
>this project or is there a better / easier or more efficient way of
>attaining my goal. Maybe I have missed something obvious?

The most reliable method IMHO is a set of up/down counters with PIC
reading these via I2C. Its a bit problematic trying to debug a software
based quadrature encoder etc...

Rgds

mike
Perth, Western Australia

1997\08\19@164743 by Bob Blick

flavicon
face
Hi Russ,

Sounds like no problem. I have read optical encoders before, and my
approach has been slightly different, but not so far off that I wounldn't
say that your method is quite do-able.

I've done it with PICs that have timers, so I always have a timer-based
interrupt, and test the encoders each time. you could also test the LPT
port at the same time to see if the PC was wanting data.

If you aren't doing much else with the PIC, you can set your timer to
interrupt 10000 times per second, which will give you some headroom for
mechanical glitches.

There's an example of reading optical encoders on the Parallax ftp site,
it's a simple task.

If you are using a 16c55 just make the whole program run in a loop, polling
the encoders, inc/decrementing the count, and polling/serviceing the LPT
port each loop.

Do your encoders have an index, or are you using some other method of
initial alignment?

Also, out of curiosity, whose encoders are you using?

Cheers,

Bob


At 03:04 PM 8/19/97 -0400, you wrote:
{Quote hidden}

http://www.bobblick.com/

1997\08\19@173712 by Walter Banks

picon face
> Question:
>  given the above information does this sound like the proper way to
approach
> this project or is there a better / easier or more efficient way of
> attaining my goal. Maybe I have missed something obvious?
>
> Thanks very much in advance.
>  -Russ



I assume that the encoders are in quadrature. The speed should be no
problem. The simplest way I have seen this done is to take last reading
current one and do a 8bit index into a jump table of actions (256 entries)
although large is very fast and can handle several times the data rate you
are suggesting. There are 9 possible actions all very short.

for each axis you need a

inc  dec, or no action

Three actions on each encoder gives 9 posibilities.

There is another choice and that is buy a very cheap mouse and
and replace the signals from the photo transistors with 4 logic lines.
Read the data on a serial port of your PC. (If is is cloudy outside
you can always use your telescope as a mouse :))

Walter Banks

1997\08\19@211216 by Mike Keitz
picon face
On Tue, 19 Aug 1997 15:04:40 -0400 "Berg, Russ: SAS" <spam_OUTBerg.RussTakeThisOuTspamIC.GC.CA>
writes:
>Hi, quick background then my question:
>I am currently plowing away through a project that uses a 16c55 @ 4mhz
>takes
>input of 2 pins each from 2 high precision encoders (PORTA), one
>encoder per
>axis on a telescope, each encoder puts out about 4048 codes /
>revolution,
>what I am doing is reading the encoder pins with the PIC and keeping
>track
>of a 2 byte variable per axis (Right Ascention and Declination) as
[rest of project description deleted]
For this kind of project, write the program as a loop that takes a
constant amount of time (perhaps by synchronizing itself to RTCC every
loop) and services all possible functions of the device such as polling
the encoders, keeping count, and outputting the data.  There will be no
interruption in counting whether the PC is receiving data or idle.  But
this brings up another problem: since the count is output in small
pieces, it will be received incorrectly if it changes.  For example, if
the count is 01FF and rolls over to 200 inbetween sending the 01 and the
00, the PC will receive 0100.  To prevent this, make a copy of the entire
count before sending it.  After sending, a flag bit could be transmitted
if the count changed during transmission, indicating the need to read an
updated count.

There should be a button or some other means to reset the absolute count
to calibrate the encoders.  Place the telescope in a known position, then
press the button to set the counter to a known count.  Otherwise the PC
software will need to deal with the possibility of the count rolling
over.

I'd strongly consider serial rather than parallel interface to the
computer.  This will give you more options on the computer end (Windows
NT or Unix would be no problem since it doesn't need a direct nonstandard
control of the hardware).  It would also simplify extending the cable
between the encoder and computer or sending the data simultaneously to
several computers.  Unless speed is ultra-critical, output the counts as
ASCII decimal or hexadecimal rather than raw binary.  This will allow you
to test the unit using any ordinary serial terminal emulator.   The only
cost of this is a level converter such as a MAX232, 14C88, or various
transistor circuits.

The PIC could output to the computer constantly e.g. "nn nn \n" or
intermittently controlled by the RTS line from the computer.  If RTS is
sensed inactive (- volts),  the PIC would immediately stop any
transmission.  When RTS returns active, the PIC would load up the most
recent data and send it from the beginning.  With this mode, the hardware
flow control in the computer's OS would prevent the PIC from sending when
the computer isn't ready.  The DTR line could be used as a way to reset
the absolute count via the PC's user interface.

For a completely different approach, consider disassembling a (serial)
mouse and connecting your precise encoders in place of the stock mouse
ones.  This cuts hardware and firmware development to almost zero.
However, the computer will need to monitor the data from the mouse
encoder constantly and keep the absolute count itself.

-Mike

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...