Laser DRO sensor

Oh well. Another seven years on the back burner, then!

John

Sorry John, we seem to have hijacked the thread, not intentionally, just lost sight of the discussion.

Ian, accessories? I guess so, but I made my own.

A rear "post" that supports a drilled plate that allows for both the main bore and valve bore of the cylinder block (7.25" guage) to be line bored, actually jig pinned for exact copies. Shows clearly in the photo, boring bars fitted with Microbore adjustable tooling.

I know this is prolonging this off-topic discussion, but is the rear 'post' bolted straight down to the cross slide or does it in some way locate on the side dovetails?

Either way the cylinder block looks a lovely bit of work.

After seeing yours, I must make a swarf tray to fit between the ways, one thing that I noticed when I changed from a Boxford lathe was that cleaning up (or finding dropped parts!) was much more of a pain.

I dont have any microbit tooling but its nice stuff.

Ian P

By using a suitable computer it may not be necessary to sink deep into techy detail. You could just use the mouse as a mouse - remove the buttons and wheel, but retain it's built-in wireless connection, whether Bluetooth or USB dongle. Provided the host recognises mice for you, mouse movements can be detected without worrying about quadrature decoding, wifi protocols, & event management etc.

My choice for this would be a Raspberry Pi 4 running Linux (Raspbian). In UNIX almost everything is a file, including the mouse, so all the DRO program need do is read a file. In Linux the mouse (and keyboard etc) appear as devices in the /dev/input directory. Each mouse appears as a separate file named 'mouse0', 'mouse1' etc.

As working out which one is yours can be tricky they all feed into one device ie "/dev/input/mice", which captures all mouse events whether touchpad, USB, wireless or Bluetooth.

The mouse sends a stream of 3 byte binary records (24 bits long) where:

• First byte, as an 8 bit unsigned integer, reports button presses
• Second byte, as an 8 bit signed integer, reports relative movement in the X direction
• Third byte, also an 8 bit signed integer, reports relative movement in Y

Mouse data read this way is 'raw', ie unconstrained by the size of the screen or windows. When mouse position is read by software working in a graphical context, the windowing system unhelpfully converts raw mouse readings into absolute X,Y coordinates fixed between window 0,0 and window width, height. Equally unhelpfully for a DRO developer, it scales pointer and cursor movement to suit the GUI's human interface )

GUI programming looks hard - raw is what's needed for a DRO.

Testing /dev/input/mice on my Ubuntu workstation, a slowly moving mouse reports X,Y in steps of 1 or -1. However, fast movement is reported in bigger increments, eg -16. Ordinary mice as owned by me aren't very accurate, and I can't comment on the accuracy of a laser mouse, especially if it's moved quickly.

A basic python program that just prints x, y as the mouse is moved:

Whether or not an ordinary user is allowed to read /dev/input/mouse seems to vary. If not, run with sudo.

The output is a stream of positive and negative numbers showing how the mouse is moving:

Seems to work.

I'm testing on a Workstation with a wireless mouse and USB receiver dongle. A RaspberryPi 4, which has Bluetooth, should work the same way and/or with a Bluetooth mouse. So much for the input problem.

Output: Raspberries can serve X to a remote client over Wifi or Ethernet, or a plug in HDMI TV, HDMI monitor, or small HDMI screen, or the GPIO can be used to drive a I2c LCD, LED or TFT device as commonly done in Arduino projects.

So, I'm suggesting a mouse DRO could be a simple file read file, data format, and display application not needing any complicated programming or deep understanding of computer and electronic innards. Lots of unknowns about accuracy and response times but it looks achievable to me in principle.

Dave

Edit Typos galore

Edited By SillyOldDuffer on 09/07/2020 15:12:27

Ian,

It has a dovetail on both sides, one side fixed and the other side has has a captive block (just like a gib) with cap head screws to lock it, just the same as you can lock your cross slide, but pulled vertically. The vertical part (against which the jig plate is presently mounted) can also be used for other things such as back toolholder and is fixed to a T slot across the top edge.

Harrison called it a Single toolpost and auxiliary rear slide .

Edited By KWIL on 09/07/2020 15:22:09

One issue with mouse sensors is that their intended use has a human in the control loop by definition. This means that even faily gross error are corrected subconsiously. In the machine application even small errors will accumulate. A good high contrast, regular pattern for the sensor to look a would help but you may still accumulate errors.

Robert G8RPI.

Edited By Robert Atkinson 2 on 09/07/2020 16:19:04

Kwil,

No need to apologise - that's what happens in a tea/bar room conversation!

Despite Dave (SOD)'s comprehensive reply - for which many thanks - I'm inclined to think it's not going to be worth the effort. I was trying to think when I last did any programming and came to the conclusion it was when I went to evening classes (aged 37) and studied GCE "O" level computer studies. That was 36 years ago! Yes, I got an A grade but we've all passed a lot of water since then and I'm not about to start re-learning that particular skill..

John

.

That should give you plenty of time to read this, John

**LINK**

http://www.dicklyon.com/tech/OMouse/OpticalMouse-Lyon.pdf

MichaelG.

Too late to edit:

This is a useful reference to Avago sensors: **LINK**

https://www.bidouille.org/files/hack/mousecam/Understanding%20Optical%20Mice%20White%20Paper.pdf

Dated 2006 ... so there may be a newer version available

MichaelG.