Digital caliper remote display

So... I finally finished it...

(I can't post all of this in one go on the forum) this is Part 1. Program is Part 2.

Ken did mention an IC level shifter which is a better idea, but I had a load of small signal transistors in me junk box and I was getting impatient... so just cobbled it together.

The 1.5v supplies for the calipers were simply taken from a potential divider which has a 6k2 connected to the 3v3 output of the Arduino and a 4k7 down to ground 0v ... gives about 1.4v at the mid point.

The wiring to the Arduino is best followed using the program inputs .. you will see clockpinx and datapinx and clockpiny and datapiny defined.

I used a D type connector for the two calipers.. there is not much wiring to do, I did however wire reset to zero switches in the box which just ground the reset buttons in the calipers, you would have to take the calipers apart to fit wiring and I must say it is a bit fiddly, there is not much room for manouver... or is is manouvre sorry can't spell.

One thing which was different with the Lcd I purchased was that the I2C address was slightly different but there seem to be only two addresses used.... either 0x3F of 0x27.

The program below is for use with two calipers which I just put together with a minimal knowledge of programming and copying what was on the www.

Hope you might find some of the build info useful.. if you have any questions let me know ... just don't ask me difficult questions about programming..!!

Part 2.

int i;
int sign;
long value;
float resultx;
float resulty;
int clockpinx = A2;
int datapinx = A0;
int clockpiny = 7;
int datapiny = 9;
unsigned long tempmicrosx;
unsigned long tempmicrosy;

#include <Wire.h>

#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

void setup()
{
{pinMode(clockpinx, INPUT);
pinMode(datapinx, INPUT);
}
{
pinMode(clockpiny, INPUT);
pinMode(datapiny, INPUT);
}

Serial.begin(9600);

lcd.begin(16,2);
lcd.backlight();

{ lcd.setCursor(0,0);
lcd.print("X val mm";

lcd.setCursor(0,1);
lcd.print("Y val mm";
}

}

void loop() {
ReadX();

}

void ReadX(){

//This is for reading the caliper x data.

while (digitalRead(clockpinx)==HIGH) {} //if clock is LOW wait until it turns to HIGH
tempmicrosx=micros();

while (digitalRead(clockpinx)==LOW) {} //wait for the end of the HIGH pulse

if ((micros()-tempmicrosx)>1000) { //if the HIGH pulse was longer than 1000 micros we are at the start of a new bit sequence
decodex(); //decode the bit sequence

}
}

void decodex()
{
//this turns the binary code of x data into a decimal value.
sign=1;
value=0;
for (i=0;i<23;i++) {

while (digitalRead(clockpinx)==HIGH) { } //wait until clock returns to HIGH- the first bit is not needed
while (digitalRead(clockpinx)==LOW) {} //wait until clock returns to LOW
if (digitalRead(datapinx)==LOW)

{
if (i<20)

{
value|= 1<<i;
}
if (i==20)

{
sign=-1;
}
}
}
resultx = ((value*sign)/100.0);
lcd. setCursor(10,0);

lcd.print(resultx,4);

ReadY();
} ///END

void ReadY(){

//This is for reading the caliper Y data.

while (digitalRead(clockpiny)==HIGH) {} //if clock is LOW wait until it turns to HIGH
tempmicrosy=micros();

while (digitalRead(clockpiny)==LOW) {} //wait for the end of the HIGH pulse

if ((micros()-tempmicrosy)>1000) { //if the HIGH pulse was longer than 1000 micros we are at the start of a new bit sequence
decodey(); //decode the bit sequence

}
}

void decodey()
{

sign=1;
value=0;
for (i=0;i<23;i++) {

while (digitalRead(clockpiny)==HIGH) { } //wait until clock returns to HIGH- the first bit is not needed
while (digitalRead(clockpiny)==LOW) {} //wait until clock returns to LOW
if (digitalRead(datapiny)==LOW)

{
if (i<20)

{
value|= 1<<i;
}
if (i==20)

{
sign=-1;
}
}
}
resulty = ((value*sign)/100.0);

lcd. setCursor(10,1);
lcd.print(resulty,4);

ReadX();
}

Thanks for publishing the program Bob.

Poking my calipers with an oscilloscope revealed this:

The first problem to overcome is the connector, which I've described as a 'Caliper Plug'. I don't think it's a standard fitting so my first problem will be to make one! It has to fit into the rectangular hole ringed red in the photo, which is normally hidden under a cover.

Anyway, the table shows that one of my calipers won't play, but the other three probably will. The Dasqua has a 5 pin socket (ground on the left) and will need a different plug. Although the height gauge has a real USB socket, it's not computer compatible USB. I expect to find when I've had time to break out the USB connector that the signalling is the same as the other calipers. If so, then not a good idea to plug the height gauge into a computer because the higher voltage computer could damage the caliper and perhaps itself in the process.

Dave

0x27 and 0x3F seem to be the most common but others are used. If anyone gets stuck with an IC2 display that won't work with one of Bob's values, I found this sketch on the web. It scans the LCD for a valid IC2 address and tells you what it is.

Apologies for the indentation; the forum software removes it!

#include
#include
LiquidCrystal_I2C* lcd;

// UNO : SDA=A4 SCL=A5
// I2C Scanner
// Written by Nick Gammon
// Date: 20th April 2011

#include

void setup() {
Serial.begin (115200);

// Leonardo: wait for serial port to connect
while (!Serial)
{
}

Serial.println ();
Serial.println ("I2C scanner. Scanning ..." )   ;
byte count = 0;

Wire.begin();
for (byte i = 8; i < 120; i++)
{
Wire.beginTransmission (i);
if (Wire.endTransmission () == 0)
{
Serial.print ("Found address: " )  ;
Serial.print (i, DEC);
Serial.print (" (0x" )  ;
Serial.print (i, HEX);
Serial.println (" "  )   ;
count++;
delay (1); // maybe unneeded?
} // end of good response
} // end of for loop
Serial.println ("Done." )   ;
Serial.print ("Found " )  ;
Serial.print (count, DEC);
Serial.println (" device(s)." ) ;
lcd = new LiquidCrystal_I2C( 0x3f, 16, 2 );
setup1();
} // end of setup

void setup1()
{
lcd->init(); // initialize the lcd
// Print a message to the LCD.
lcd->backlight();
lcd->print("Hello, worldy!" ) ;
}
void loop()
{
}

Lots of edits to remove poxy automatic smileys

Edited By SillyOldDuffer on 06/08/2017 13:11:05

Edited By SillyOldDuffer on 06/08/2017 13:14:21

Edited By SillyOldDuffer on 06/08/2017 13:15:28

Edited By SillyOldDuffer on 06/08/2017 13:16:40

I soldered my wires in place. The standard caliper connectors are a joke...

Neil

Hi Ken, Dave, Neil ... and all...

Just a short digression... as some of you may know I have an interest in astronomy .. my scope is a 6inch binocular reflector... I have a need for a remote digital azimuth angle readout and wondered if anyone has any information for these things.... see pic.. I can't even get into the thing... or if there are any other types which have a remote readout...

below..pic of scope and below that with angle gauge in question... sorry its blurry but I think you will know the type..

rgds..Bob..

Back in the day of the Shumatech DRO's and the use of calipers and other capacitive scales, this connector and its improvised and adapted mates were the source of extensive reliability problems. The general consensus was that directly soldering connecting wires to the pads was a much better way to go - either a short run to a reliable external connector pair or simply the whole run up to the the connector that mates at the readout end.

Edited By Bandersnatch on 06/08/2017 18:55:11

Hi Bob,
I have not taken that type of angle guage apart but I have just had a look at the on I have. If you peel the label off on top of the locking knob there is an alen screw which I suspect will allow yo to dismantle it. Have you considered the "Wixey" type angle gauges ? It is possible to display the data from these remotely and it should be possible to mechanically to the encoder. There is some information on these angle gauges on my website here.

Les.

Les got there first

Thanks Dave for the lcd address program .... will definately have a look at that one.

Thanks Banders who agrees with Neil that the connector is not a good idea, I soldered mine which is a pita as the case needs taking off otherwise the plastic case will suffer...perhaps Dave will find a better solution.

Also thanks Les... I didn't know the label hides the screw...and the hack for getting a remote display from the Wixey is what I want....can't understand how I missed that... I think I will be using a rotary encoder for the azimuth display..

Anyroad up.. I have just been using my new dro and there is a small problem as it seems I selected a couple of resistors for a divider network to give the ~1.5v supply for the calipers, it now transpires that when the battery gets lower in voltage then the caliper voltage goes down as well ...obvious! ...and the readings dissapear..! so I will be removing the bottom resistor and fitting a zener perhaps or could use an LED as a regulator .. not a big problem.

Here is a pic of the dro..

...Bob..

I used LEDs as regulator for mine, but found that using an LM317 or similar gave me fewer glitches.

I replaced the batteries in the units with sub-miniature 10uF caps.

Edited By Neil Wyatt on 06/08/2017 21:43:35

Wonderful. I log in after a lazy day out to find everyone else has been hard at work!

I'd hoped to plug a bigger remote display into an unmodified caliper but the advice about those connectors being unsatisfactory rings true. I could have wasted a lot of time trying to make a satisfactory plug. So I'll solder a caliper up instead. Good job calipers are cheap - being Mr Wobbly with an iron I'll probably melt a few.

Les : excellent info on interfacing to a Wixey. I can have a play with one of those now as well. I was going to suggest Bob try an Accelerometer on his binoculars but they aren't as accurate as a level gauge, so double brownie points to you.

Cheers,

Dave

Edited By SillyOldDuffer on 06/08/2017 21:59:15

Hi Bob,
I think the rorary encoder is a better solution than either of the angle gauge types. I have a design to display the output of a rotary encoder on an LCD display using a PIC16F690. Let me know if you want the schematic and code for the PIC. I have seen some 600 counts per rev encoders on ebay for less than £10.00 so one of them geared 6:1 to the telescope axis would give 0.1 degree resolution.

Les.

I took the Yuriy's Toys approach for the DRO on my Mini Mill that uses Igaging scales but built my own circuit board based on an atTiny85 and some USB connectors (total cost less than £5.00). This runs Yuriy's firmware with a couple of minor tweaks for the atTiny chip.

This interfaces via Bluetooth to a cheap 10" Android tablet, but any Andriod device would work just as well.

The Igaging scales use mini USB cables, but use +3v, Clk, Data, Gnd on the pins

Edited By Zebethyal on 08/08/2017 11:05:24

Many moons ago I bought a carbon fibre caliper off eBay because it was silly cheap as a 'hack'. Didn't notice it was only 0.01"/0.1mm. this thread reminded me of it, so I've fitted it to my pillar drill as a depth gauge after cutting most of it to pieces. No sense trying for 1-thou accuracy on a drill, if I need that I can us the mill.

Goes nicely with a laser centring device from Machine DRO so I'll put some pics in the next MEW.

Neil

Lack of progress report!

Good news, my old Powerfix Caliper came apart easily after exposing the screws behind the sticky label on the back.

Even better, a signal appeared on the 4 pin interface after I cleaned out the swarf so I shakily soldered on some wires. (I was surprised how much muck was inside the case.)

Reassembled I detected this output on the clock and data pins. The yellow trace is the clock, and the blue is the data. As expected I found the caliper never switches off. The ON/OFF button disables the display but everything else carries on working.

After this promising start the project's gone pear-shaped. The NPN transistor level shifter quickly drains the caliper's battery. I've been unable to decode the data with any of the Arduino sketches available on the web. I can't see any difference between positive and negative numbers on the oscilloscope trace. This might indicate this caliper has an unusual variation on the usual protocol. Or that I'm a bit thick.

Perhaps a mug of strong coffee and an hour on the lathe will sort me out. Electronics and computers have lost their appeal.

Dave

Hi Dave,
The waveform looks like 7 BCD protocol but the data is inverted. I can't remember if any versions of Yuriy's code support this protocol. This is a link to a website that shows the 7 BCD code. I have a powerfix caliper (From Lidle) but the one I have looks like 2 x 24 bit protocol.

This is some notes I made on the 7 BCD protocol on a set of calipers bought from Neto many years ago.

-------------------------------------------------------------------------
7 BCD Scales
LSB Sent first.

Static state of clock line between frames Low
Time between start of frames 330 mS
Length of data frame 820 uS
Interrecord gap 329 mS
Time between stat of nibbles within frame 110 uS
Length of clock cycle about 12 uS
Time clock pulse is negative about 6 uS
Time clock pulse is positive about 6 uS
High level at start of frame about 55 uS
High level between nibbles about 60 uS
High level at end of frame about 60 uS

Clock in the data on the negative going edge.

Top nibble
Bit 0: sign. L = +, H = -
Bit 1: in inch-mode H means +0,0005 inch, unused in mm-mode.
Bit 2: unit: mm/inch. H= mm; L= inch
Bit 3: unknown.

28 bits in a frame of data

CPI 2540 (Metric)
-------------------------------------------------------------------------

My interface design using an ATtiny4313 worked with this 7 BCD caliper. Let me know if you would like a copy of the source code (Written in assembler.) It may give you some ideas to write a version in "C" to run on the arduino.

Les.

Hi Dave...

I can certainly commiserate with you "electronics & computers losing their appeal" .

Les is right...the trace definitely looks like a BCD format see .. http://robotroom.com/Caliper-Digital-Data-Port-3.html ...

which means you will be able to use my code..as posted.

I also didn't use the battery in the calipers rather using the +5v from the Arduino for the level shifter... and potting down the 3v3 from the Arduino for the caliper 1.5v supply using two 6k2 resistors.

The LCD I originally powered using the +5v Arduino supply but I found it caused the screen to be a bit dim....the maximum LCD volts is 7v, so rather that making a power supply circuit for this, I found a 3.3v zener and put it in series with the LCD and the 9v Battery... now its as bright as needed.

rgds..Bob..

Hi Bob and Les,

I can confirm that this caliper is using BCD. This screenshot is of 4.56mm and you can see the first three nibbles are 6, 5 and 4. Hurrah!

At the moment I'm using a slightly modified version of Bob's sketch. The main differences are: I've commented out the I2C LCD stuff and am using the Serial Monitor instead; I've also inverted the start logic in ReadX()

The start logic change is because my caliper appears to be upside down. After making the change I started receiving numbers and was able to confirm that the delay between each transmission is correctly detected by the Arduino.

Trouble is that the decoded numbers jump about and don't have any relationship to the input. I'd be much happier if the output numbers were stable even if wrong. As it is, looks like the Arduino and/or Sketch aren't detecting bits properly.

It may be noise on the caliper's "power supply". I'm running a LED off the 3.3V line and tapping 1.5V off that smoothed with 6.8uF. I don't think the erratic numbers are due to logic inversion or Bob's code, but might be. My main suspect at the moment is the level shifter: the clock signals in particular are suspiciously round-shouldered!

Many thanks for the advice. I have a way to go yet!

Dave

My digital scales don't send the data in the BCD form, instead they use this:

"The 48-bit serial stream contains two 24-bit words that are the absolute and relative positions of the scale in binary format, not BCD format like the Digimatic protocol. Each 24-bit word is sent least significant bit (LSB) first, which is opposite from most serial protocols that send the most significant bit (MSB) first. The units of each word are in 20,480 positions per inch or 0x5000 in hexadecimal. The first word is the absolute position of the scale with an arbitrary origin that remains fixed until the scale loses power. The second word is the relative position of the scale with an origin that is reset with every press of the zero button on the scale. The positions are signed values so negative values are expressed in two's complement notation. A diagram of the data format is given below."

You can see this potentially allows you to read the scale to a tenth of a thou or even a micro-metre. This is so the same protocol can be use with micrometers and other higher precision devices. In practice I found that 0.0005" or 0.01mm were practical. I used 3x oversampling which helped minimise display flicker.

Neil