Subject: Re: DRO on PC

From: [email-masked] (Ray Spinhirne)
Date: Wed, 11 Jan 1995 17:24:13 GMT

Steve Lindsay ([email-masked]) wrote:
: In article <[email-masked]>, MadMat9 <[email-masked]> 
: rote:
: >Hi everyone:
: >
: >I saw the ad in HSM about Digital Read Out (DRO) on the PC (I forget the
: >company).  I guess I'm wondering if anyone out there can tell me what ki
: d
: >of signal is being sent out of a linear digital spar.
: >
[cut ]
: >Regards,
: >Mat

: I have been working on a windows program
: to do what you are describing.  It will read
: a rotary encoder.  The encoder I am using to write
: the program puts out 360 blips every rotation.
: I am using a lpt port.  Ultimately I want to hook
: it to a mill and just use the computer for a digital
: readout.  Later on I want to also write in so it can
: be used to control some stepper motors.  I have a dream
: of being able to make a closed loop system where as
: the stepper motors move the encoder hooked to the table
: will put input back into the computer.  In other words as it executes
: it will be constantly checking itself that it is where it is suppose
: to be and if not it will compensate until it gets input that it did.  
: This way it may be possible to get some accuracy
: without using ball screws in the mill.  It would be like the program
: is watching the digital readout to mill rather than just telling the
: stepper
: motors to turn so far and hope they did.  

: The program is working but still pretty crude.  When you click
: on the menu it will place the port reading within the main windows
: loop so that as long as you are doing anything else on the computer
: it will catch all the data on the port.  I realize it almost needs to be
: buffered
: and maybe I should be on a com port.  If you do move the mouse or start
: another program while it is suppose to be watching the port it may
: miss some data on the port and losse count.  On the lpt port I did get it
: to 
: not to miss any data as long as you are not moving your mouse or
: something.  
: I can spin it as fast as I can with my hand and
: all the blips are showing up.  I did run into problems because it takes
: some time to display the numbers on the screen every blip.  I fit in 
: another loop that will time how fast the blips are coming and it they
: are slow enough it will go ahead and display the numbers.  So what
: you seen on the screen if you spin it real fast is that they will stop
: updating until it slows back down, although it does not loose count this
: way. 
: I have it counting that something happened if a data pin is on or off so
: that the 360 blip encoder is putting out 720 blips (kind of).  It will
: read up
: or down on X, Y, and Z.  The X is hooked to pin 2 and 3 the Y is to 
: 4 and 5 and the Z is 6 and 7.  Also, every pin has a common that
: is hooked to ground which is pins 18 or 25.  

: If you would like to play with the program let me know and I will UUE it
: and email it to you.  You don't need an encoder to try it out.  Hook
: a 25 pin cable to your lpt port and bring it around to the front of the
: computer
: and place two batteries together 2.5v and hook the - to one of the ground
: pins 
: 18 - 25 and the + just touch on and off any of the data lines and it will
: count. 
: I still need to make more of the variables user accessible so you can 
: change scaling and such so it is not to useful yet.  Also, if you want to
: try it tell me what lpt port you are using as I don't have a way for you to
: change that either.

: Steve

------ Sounds pretty neat.  I think you can solve the timing/speed
       problem by using interupts.  The lpt port has an interupt that
       could be used to just advance a counter ( or decrement?? how
       do you know which way you are going).  This then makes the
       recording of "where we are" independent of the display of the
       data.  It really makes thinks much simplier once you get the
       interupts vectors and handlers figured out.  I did this once
       for a project for an assembler class.  It's been quite a while
       so I don't remember all of the detail but it went something
       like this.

	1.  Disable the interupts.
        2.  Put code to handle the interupt in a know location in memory.
        3.  Modify the interupt vector to point to this location.
        4.  Inable interupts.

	After this is done you just have a memory location always has
	the current position and you can use "regular" programming
	to read this location and process it as you wish without having
	to worry about updating it, or how much time your display program
	takes.

	I have considered playing around with some kind of CNC for my
	old milling machine.  But each time I think about doing it
        it seems that I will be doing 90% programming and 10% making
        chips.  I do 90% programming at work and I'm not sure that
        I want to do it as a hobby also.  

	Good luck on your project.

Ray Spinhirne				[email-masked]
Director Computer Services
St. Edwards University

---

From: [email-masked] (Mark Fraser)
Date: 13 Jan 1995 14:07:57 GMT

Dunno if I posted this before, but I just picked up some [Chinese
but getting a LOT better quality] digital calipers, that have 
contacts for serial output; these can be had for just over
40 USDollars these days, even a surplus rotary encoder is 15,
and new are 30-50.  Direct readout as the calipers come out of
the box, or with appropriate [synch data plus clock plus a
"gimme the data" pulse] interfacing micro, and feed to a PC or
other [bigger] display.

I'm waiting for someone with the coding skills to put the
latter part into a 68HC11 or 8051.......
Advantage: set the zero point, readout IS DIRECT and in
inches or mm from the zero'd reference point, to .5 thou.

Ideas? /Mark

[email-masked] wrote:
: Someone (not sure who wrote):

: :I have been working on a windows program
: : to do what you are describing.  It will read
: : a rotary encoder.  The encoder I am using to write
: : the program puts out 360 blips every rotation.
: : I am using a lpt port.  Ultimately I want to hook
: : it to a mill and just use the computer for a digital
: : readout.  Later on I want to also write in so it can
: : be used to control some stepper motors.

: Not meaning to rain on your parade, but having played around with
: similar rotary encoders I can tell you this approach is going to be
: troublesome.  Even with dedicated counting electronics (I tried
: various TTL circuits) I always observed missed counts within a few
: turns, especially if you're changing directions often (the direction
: change can cause a very fast transient).  You may have slightly
: better luck at only 360 ticks per-rev, I had 1024/2048 ticks per rev.
: You may want to check if your encoder has a "reference pulse" - a pulse you
: get every time you move through "zero" that you can use to reset your
: counter.  This makes life a little better, as your errors
: don't accumulate over time.  If you've got software doing this, you
: can add some sophisticated logic to detect lost reference pulses
: too.

: What you really want is an absolute encoder - basically a binary
: number wheel that is read with 1 photo tranistor per bit so that you
: know exactly where you are in any revolution.  The ones I used were
: sort of pricey (this info is about 5-10 yrs old) around $2K for 16 bit
: resolution (65,536 ticks per rev).  If you can really get by with
: aprox 1 degree resolution (9 bit resolutoin) the price may get down to
: a few $100 each.

: Don

---

From: [email-masked]
Date: Thu, 12 Jan 1995 15:11:51 -0500

Someone (not sure who wrote):

:I have been working on a windows program
: to do what you are describing.  It will read
: a rotary encoder.  The encoder I am using to write
: the program puts out 360 blips every rotation.
: I am using a lpt port.  Ultimately I want to hook
: it to a mill and just use the computer for a digital
: readout.  Later on I want to also write in so it can
: be used to control some stepper motors.

Not meaning to rain on your parade, but having played around with
similar rotary encoders I can tell you this approach is going to be
troublesome.  Even with dedicated counting electronics (I tried
various TTL circuits) I always observed missed counts within a few
turns, especially if you're changing directions often (the direction
change can cause a very fast transient).  You may have slightly
better luck at only 360 ticks per-rev, I had 1024/2048 ticks per rev.
You may want to check if your encoder has a "reference pulse" - a pulse you
get every time you move through "zero" that you can use to reset your
counter.  This makes life a little better, as your errors
don't accumulate over time.  If you've got software doing this, you
can add some sophisticated logic to detect lost reference pulses
too.

What you really want is an absolute encoder - basically a binary
number wheel that is read with 1 photo tranistor per bit so that you
know exactly where you are in any revolution.  The ones I used were
sort of pricey (this info is about 5-10 yrs old) around $2K for 16 bit
resolution (65,536 ticks per rev).  If you can really get by with
aprox 1 degree resolution (9 bit resolutoin) the price may get down to
a few $100 each.

Don