Cheap DRO Revisited

I thought it was time I revisited the cheap DRO, so I have put the files on github and made a video showing it all working. The files are very much a dump of my code and PCB files, there's no guarantee it will build.

DRO Github

It's a start though, if you want to have a go at making one. The video shows the physical arrangement and also shows the update rate.

I milled the PCBs on my CNC3020, so they were very cheap, if you were to have them made then you'd probably want to reduce the size quite a bit, or the cost could be quite high. They are all single sided.
I have not put it in a case, I have mounted it up high in the workshop so chips don't get to it (I only have a mini-lathe and mill, so they don't throw things about much).

I think the cost I gave of £150 is probably quite a bit on the high side, as I milled the PCBs, which is cheap and used cheap calipers. Some discrete components came from my parts bin, too.

Video of DRO Operating

Video of DRO Operating

I've made a little video of the DRO operating so you can see how fast the update rate is. It's several readings a second and easily fast enough for anything I do. The gauge data stream is pretty fast and all six channels are read by the main processor over I2C, only three are displayed.

The main TFT is quite slow with big updates, but just about responsive enough when I use the menus.


One thing I was worried about was the auto power-off that the gauges have. After a period of inactivity they shut down, but fortunately all they do is turn the display off. The data stream continues, which is perfect for a DRO like this. It also might explain why the batteries go flat so quickly...

DIY DRO

All Gauges Attached to DRO

The remaining gauges have been attached to the DRO. There's now 3 gauges on the lathe and three on the mill. All of the gauge channels are now populated and attached:

Each card has a PIC on it that converts from the gauge serial protocol to I2C. The main ARM processor then interrogates each of the relevant gauge channels over I2C and displays the values.

Each of the gauge channel PCBs is identical, the firmware is almost identical, the only difference is the I2C slave address, which is 0x30 and 0x40 for each pair of PCBs on the same I2C bus. There's three I2C busses.


The main DRO PCB has an ARM processor on a commercial LPExpresso card:

The TFT screen is a touch screen and there's a menu system running on it. The DRO can be set to display the lathe channels or the mill channels. The smaller OLED displays then show the appropriate axis tags. When running in lathe mode the two X axis values can be added together.

The gauges have been attached with 3D printed plastic mounts. I may re-make them in metal if they aren't rigid enough.

The gauges are held in clips that can have screws clamping them from the sides:

 I've removed the buttons from the gauges if they were pressed by the clips. The buttons aren't needed and you also don't need to read the displays as the DRO does that.

The batteries aren't needed either as the DRO channels all have a 1V5 power supply. The gauges run from that and are powered all the time the DRO is powered. The power down of the gauge display doesn't stop the serial data stream, either, which is nice.

 The mill X gauge is mounted in a similar way:

The Y as well:

And the Z gauge:

The lathe bed gauge was one of the more complicated mounting arrangements.

I've started to use the DRO and it certainly makes measuring things much easier. I need to check that the gauges are working correctly by comparing with a dial indicator.

Lathe DRO 

I've mounted the ARM based DRO on the wall and attached two gauges to the lathe. The Y axis isn't attached and the code mirrors the X axis, but apart from that it's working:

The gauges are here:

I've re-cased one PCB but left the other one with a display. I'm not sure what I'll do with the next ones, it depends on the space I have available. There's only two channels of gauge decoders plugged in at the moment, both decode the cheap Chinese gauge data streams (24 bit). For some reason I've not worked out I have a signal problem with the channel that attaches to the more expensive gauge that outputs the 2x24bit data stream. I need to build some more gauge channels and attach gauges to the mill and the third gauge to the lathe.

The TFT display isn't working at the moment, I have to get the SPI protocol working, I'm going to do that on a breadboard.

I'm going to try the DRO out as it is for a while and see how it goes.

Back Where I Started

With regard to the DRO PCB anyway, just this time it is using an ARM (LPC11U14 specifically) on an LCPXpresso board that I had floating round for another project.

As you can see, the code is ported over, well the OLED driving stuff anyway, and all is up and running. Just the TFT and LED displays to do, then I can attach the gauge boards and get it running. That's where it all started to go wrong with the PIC based PCB. The LPC stuff is much more solid. I've not seen the OLED problems I saw with the PIC, and it's the same code, so there was something odd going on with the PIC. The LPCXpresso board has a JTAG debugger on one end too, so the DRO has it's own debugger. That works perfectly too, I've managed to get a stack trace from it when I made  porting error, and it was easily debuggable. All in all, much better.

The only thing is that the LPCXpresso board is much more expensive than a PIC chip, but I can probably make my own target board later and take the LPCXpresso board off the DRO. Maybe. I may just leave it there, it'll make programming easier later on.

Main DRO PCB 2.0

I've decided to put the entire Lexpresso card onto the DRO main board as it saves me the hassle of laying out a processor board, and I get the debugger/programmer half of the card as well. I can lay out a processor card later if I want to. The card also has nice 0.1inch holes for mounting on a PCB, which the Arduinos don't I thought about using and Arduino Mega, but mounting it was just too difficult.

New main PCB being milled:

I'm doing two passes, the first with a 0.6mm bit and the second with a 0.2mm bit. The first pass gives me more clearance around the tracks and pads and th eseocnd does th efine isolation. This should make it a bit easier to solder without shorts like I had on the first PCB. Of course, it means two 7 hour milling sessions, not one, but it's probably worth it.

Change of DRO Direction

 I've spent a lot of time recently trying to get the PIC16F18875 working as the main controller on the DRO. It's sort of working but there's problems. Whenever I make a simple code change (something like changing a /1000 to a /10) the code sometimes just fails to run. This would be fine, as it's probably a bug, well maybe, but as the Microchip debugger also doesn't seem to work, it's all a bit of a disaster. Looking on the web it seems this is a fairly common experience. It's a shame as I've used PICs a lot in the past and they were useful little devices. Anyway, I've decided to ditch the PIC and try something else. At the moment he plan is to use an LPC1114 ARM based device. This has the added advantage of more flash (32K), similar clock speed and lots of GPIO. Unfortunately it is a 3V3 device and that means I will have to deal with level shifting and add a regulator.  Anyway that's all OK, just a bit more complexity and if it works I can lay out a mostly 3V3 PCB with the LPC on it.

The other thing about the LPC chips is that they don't come in any DIP packages. Not that are available to buy anyway. So I have tried to mill a QFP48 footprint that is one of those used by the LPC1114. Once I used a 0.1mm cutter and a shallow depth of cut, I managed this:

It's not perfect, there's a bit of copper that hasn't been milled away. I think I may be able to sort that with either a second milling or slightly more depth. Anyway, it looks to be possible, so that's the plan.
Those pads are 0.5mm between centres, by the way.

DRO Display Running

The main display PCB has now got some firmware that does something. The code can talk to all three OLED displays and also to the three LED readouts.

It can also get pixels on the TFT, but the range of co-ordinates seems limited in some way. There's also some spurious pixels on the OLED displays, but it seems deterministic so I don't think it's noise.
I need to get the touch screen code in a fit state to register keypresses.

I've also routed a couple of gauge channel daughter boards:

The bottom one is milled using a 0.2mm bit as I have done with most of my PCBs so far. After the problems with shorts on the display PCB (which turned pout to be soldering problems, as there's no solder resist), I have tried a double stage milling process in the second PCB. The first stage is a mill with a 0.6mm bit, followed by one with a 0.2mm bit to cut away the final detail. This leaves a larger gap around most of the tracks, which I hope will act as a sort of solder resist.

Here's a populated gauge channel PCB:

The socket is for the PIC12F1822 which reads the gauge data stream. The transistors are used for level shifting the data to 5V and also for driving the data and clock lines in order to put some gauges in to fast mode.
There's also a 1V5 supply generated with a simple voltage divider.

First DRO PCBs

 I've routed the first DRO PCBs. This is the main display PCB with one gauge interface daughter board:

There's the three LED axis displays and the OLED axis label displays. The larger display at the bottom is the TFT that I want to use for diagrams etc.

This is the gauge interface board:

it plugs in like this:

The partially populated display PCB from the rear:

Unfortunately I have a short between the supply rails on the display board, so I'm going to remove the excess copper to try to isolate it.

DRO Electronics

I have breadboarded the DRO electronics now. I've settled on three 8digit LED displays for axis position and three 0.96" OLED displays as labels for the axes. These will show whether the axis is X,Y, Z or whatever, plus summed axes and any other information for the axes that may be needed.

I'm also having a 2.4" TFT touchscreen LCD as the main keypad instead of separate keys. This means I can change the layout of the keys and have firmware controlled keypads as required. I've added one hardware key per axis though as an axis zero button.

The TFT LCD can also be used to display various more complicated modes like centre finding and so on.

This is a couple of the displays breadboarded as I tried to get the TFT displays to work. This is a bit of a nightmare as I've had boards that look identical to each other but which seem to have completely different controller chips on them. The touch screen functionality isn';t the most advanced int he world either, requiring voltages to be set up with GPIO lines and then and ADC reading to determine each axis position. Finally got it working though. The OLED display was easy, I just ported the OLED watch code...

The PIC at the moment is a 16F18875. I think I may end up running out of flash space, well, maybe, but that's not a huge problem as there are PICs with the same pinout and more flash space. I'll move to one of them if I need to.
I'm in the middle of routing a PCB with the main displays and big PIC on it. The circuits for each gauge I've decided to put on separate daughter boards. It means I have to lay out just one PCB and I can also adjust the gauge circuit to match any future gauges I find that have slightly different interfaces. Each of these interfaces has it's own PIC12F1822 which captures the gauge digital output and acts as an I2C slave which the main processor then polls. I have done most of that code already. This means that there are seven processors in total and an idle loop for polling each gauge, the main processor doesn't then have to worry about polling six data streams. It should all work...

The main display PCB being routed:

Well, the start of it anyway.

Second DRO Gauge

The second gauge has been fitted to the lathe. This one was a cut down 'hardened stainless' gauge I got off ebay:

I'm not sure what was hardened or stainless, this machined like butter on the mill. I'm not complaining, it made my job easier.

The mounts are 3d printed, the gauge display unit fits neatly into the metalwork, I added a copper shim to remove the last 0.1mm of movement, now there's no measurable movement.

This metal gauge works better than the plastic 0.1mm resolution one I put on the compound. Even though you can get 0.01mm resolution on the data output, it doesn't stay very stable.  I think I may use one on the compound as well, if I can buy one. I'm going to experiment with other calipers, I need another 4 for the mill and the gauge on the lathe ways.

DRO Displays

The displays for the axes of the DRO are going to be LED digits. I have some modules that use the MAX7219 chip and have 8 seven segment digits plus decimal points. One Arduino UNO and some code and we have a trial display:

So now I have a display and a gauge attached to the lathe. I thought it would be a good  idea to check the DRO gauge and see if it would be useful. It's not worth going through the hassle of building all the gauge channels if it doesn't work very well.

The first attempt was OK, but the gauge didn't slide very freely. Some adjustment of the gauge mounts might be a good idea. After some gentle filing the gauge freed up and all worked quite well.

I set the lathe dials to zero and the gauge to zero as well to check the calibration between the two measurement systems.



After moving a distance from the zero, I noticed that the gauge didn't match the scale. I finally found that when the gauge read a round number of millimetres:

The scale on the handwheel isn't at zero. I was about to give up on the DRO until I noticed that the ball on the handwheel was in the zero position.



So the dial had slipped when moving the handwheel. It looks like the DRO was more reliable than the dials in this case. Looks like it is worth continuing.

Mini Lathe DRO

I'm looking at building a DRO for the mini lathe and mini mill. The electronics isn't much of a problem, but the mechanical aspect of fixing gauges to the lathe and mill is another matter. I've decided to have a go with the cheap plastic digital calipers that you can get from China for a very cheap price. They have a data output that can be attached to a processor of some kind, which is very useful. The plan at the moment is to have a processor per gauge to handle the data stream and then have a larger master processor that handles the LED displays and does the keypad and clever stuff.

After hacksawing a caliper apart and 3D printing some parts I have the first version of a mounted caliper:

There's a couple of problems with the 3D printed parts, but it all seems to fit and work. It also doesn't seem to interfere with the operation of the compound. I need to put the PCB back on the gauge and wire up to the electronics, but it's looking hopeful. I'm not going to replace the LCD or buttons one the caliper PCB, I'll just use the data output.

From the data output it looks like there may be better resolution than the 0.1mm resolution that the caliper itself displays.