Re: [CAD_CAM_EDM_DRO] Re: Optical mouse for DRO anyone? - not for WIRE!

I personally don't think an optical mouse will be accurate but if you
want to try it, the easiest way is to use the free CPNmouse drivers
<http://cpnmouse.sourceforge.net/>. These allow you to have multiple
mice and allow you to claim exclusive access to one or more of them. I
used them to make electronic handwheels for Mach2 before Art implemented
them with the parallel port.

Les

mrclicit wrote:

> Now I don't feel so bad - you are all (well, almost all) missing what
> I said about the medium, and coming up with the same ideas my
> co-workers offered...now...
>
> Imagine a shoelace, 100 ft long. Wire and flat strapping or webbing is
> child's play in comparison - been there, done all that 25 years ago.
> Woven cordage changes dimensionally when even the slightest mechanical
> pull, push or squeeze is applied. I have put various types of lacing
> (polyester, nylon, natural fiber, etc.) through wire measurement
> machines with all types of wheels of varying hardness, and they all
> performed horribly, losing or gaining as much as 10 inches in ten
> feet. The company that makes most of these machines even put together
> a custom unit for me that they swore would work, and it did no better.
>
> In theory, the optical mouse should be very accurate if used on a
> surface that has consistent chracteristics. On a Windoze PC, it would
> be difficult, since the pointer calls to the API do not seem to allow
> the low level of control one would expect - as I recall, the
> acceleration algorithm is tied to the travel distance in the available
> API function. Without being able to compile machine code, acceleration
> would be included with distance, hence raw distance throuh a PC would
> be an extremely difficult task.
>
> Reading the raw mouse output it seems, would be much easier to do with
> a PIC and a simple routine to read asynchronous serial. the velocity
> of mouse movement establishes the serial clock, and as long as the
> chip is clocked fast enough, distance should be a no-brainer. The
> problem I see with this approach is the storage and handling of so
> many variables - even if looped every inch.
>
> Time permitting, I'll put something together to try this.
>
>