This is getting stupendously interesting, I'm learning lots of new stuff. Whether it will stay in the ageing grey matter is debatable!

BobMc code of 05/08 seems to have lots of spare curly braces in the setup() routine, and SoD code of 06/08 has several #include lines which don't seem to include anything. Can these erudite gents put me wise?

Hi Duncan../..Dave..

Duncan..Yes you are right...! there are a lot of curly braces in the setup and to be honest I don't know why! but this prog was copied off the www. and since it worked I didn't see any reason to alter it apart from making it read two calipers.. I must admit again that I am certainly not an expert with programming these things, Dave seems to have a far better understanding of programming.

Dave.... you say you have fitted a capacitor to get rid of sporadic readings... I fitted mine at the caliper end which stopped a similar problem... which Neil has done as well.

..Bob..

This all looks very interesting and I can feel a project coming on to fit scales to my VMB, especially as I'm just getting into Arduino. Bob, are you thinking about adding a 3rd axis by any chance please?

And Neil, any chance of being able to post other file types here? Or should we just use Github?

Hi Duncan,

Bob's extra curly brackets can be removed if you like. (I haven't bothered.) They're usually a sign of a program that's been developed but not tidied up once it works. The brackets probably contained unwanted code like debugging statements now removed.

Posting source code on the forum is fraught with danger because the forum editor has a mind of its own! It destroys indentation by removing 'superfluous' white space, converts certain character combinations into smileys, and - new one on me - removes anything between '<' and '>' brackets.

The missing #includes in my post of Nick Gammon's scan sketch are Wire.h and LiquidCrystal_I2C.h (The third missing #include in the scanner code is an unnecessary repeat of Wire.h that can be deleted.)

Dave

Well we have certainly covered a lot of ground since my first question.

I have said before that I am always amazed by the amount of information, comments, help and advice freely given on these forms.

Bob/Silly Old Duffer Any chance of giving links to the sites where you found the code?

My Tail Stock and Vertical Slide are both fitted with calipers.

I am trying to get my head around making a read out that would allow them to be plugged as required.

Ken

After a few tweaks last night chaos ensued; the caliper displayed weird values and refused to zero; the oscilloscope triggered erratically and the caliper clock waveform looked like it was charging a capacitor. Suspecting a short in my birds nest lash-up I pulled everything apart this morning. After reducing the project to a pile of bits I noticed that the power plug had fallen out of my USB hub...

I'm out today and won't make much progress.

Dave

Hi all ...John/Ken

John Haine asks about a 3rd axis display...

the program I posted could be altered for this purpose, but I can only give an indication of what would need to be done, which is to copy one of the sub programs for example 'void Read Y' and change all the Y's & y's to Z & z's

then insert an instruction to 'Read Z' after 'Read Y' was finished...and back to 'Read X' after 'Read Z' is finished, you would also have to alter the Setup & definition parts to include the inputs/outputs etc... I am not able to provide much more info as I am busy making a readout for my mill using a rotary encoder.. you would also need to find a bigger display than I used in my build.. mine could show 3 readings but only on two rows...

Hi Ken... "come a long way" .....yes I only wanted to show it could be done..! to be honest I can't remember exactly where I got the program from perhaps it would be better to wait and see what Dave comes up with as the program I posted has got a lot of superfluous material and wants thinning down, there are certainly a number of people on the www giving programs for this and it does seem the case that most of the cheap calipers are using the BCD format...Binary Coded Decimal.

One of the things that could be done in the meantime is to get an LCD display, mine is a 16x2 character lcd and find out how to write to it... that would be a good start and it is quite simple, if you can get that up and running using an arduino you are half way there... lcd's are about £5 quid on ebay.

Bob...

I found these two sites helpful

This one has a layout including the LCD and code for a 3 axis dro using calipers.

https://www.thingiverse.com/thing:1731982

This one shows using a

SparkFun Logic Level Converter - Bi-Directional

as the interface between the arduino and the caliper.

wei48221.blogspot.co.uk/2016/01/using-digital-caliper-for-digital-read_21.html

I contacted the first site and he says the logic level converter could be used in place of his board circuits

Ken

A lot of this, particularly noise issues with the capacitive scales and different coding systems, was covered extensively some years ago in the Shumatech Yahoo group, and is reinventing the wheel a bit here. It may be more trouble than it's worth to search there though (particularly if you are not a member) - it is Yahoo after all.

A better alternative might be to have a look at Rick Barber's Page covering the Shumatech DROs.

More fun due to duff equipment. My oldest oscilloscope probe has an intermittent fault, doh! Very time wasting as I spent an hour looking for a non-existent circuit or caliper fault.

It appears I have more than one problem. The Arduino isn't catching pulses from the Caliper 100% correctly. For 4.89mm I expect to get 1000 0101 1001. As can be seen from the log below, I quite often do. Unfortunately as can also be seen, it's not unusual to get up to three bits wrong as well.

1000 0101 1001
1000 0101 0001
1000 0101 0000
1000 0101 0000
1100 1101 0000
1000 0101 1000
1000 1101 0000
1000 0100 1000
1000 0101 1000
1000 0101 0001
1000 0101 0000
1000 0101 1001
1000 0101 1001

The bit errors are probably due to poorly shaped pulses coming out of the caliper compounded by my simplistic level shifter circuit. It may be possible to fix this in software, otherwise I shall have to install pulse shaping hardware.

The other problem is that Bob's code doesn't quite match the protocol my caliper is sending. His decode logic assumes the caliper is sending a binary number; mine is sending binary coded decimal. Negatives are handled differently too. I think a few lines of extra code added to Bob's program will fix it for me.

The way Bob's program works isn't ideal for decoding more than one DRO scale. There are a few places where the code waits for data whilst reading an axis. It means the X axis has to complete before the Y axis gets a chance. This means there's some risk of missing some readings. Adding a Z axis will make this worse. When I've got my caliper decoding correctly I'll give some thought to using interrupts to handle more than one axis safely. (Unless someone else has already done it.)

Dave

Edit typos...

Edited By SillyOldDuffer on 09/08/2017 19:04:31

Edited By SillyOldDuffer on 09/08/2017 19:05:12

Dave,

Check out this page on the Shumatech Website, it's where I got my information from when I made my readout.

It details the differences between the BCD and signed integer formats.

If your scale sends absolute and relative data, make sure it's reading the right one of the two!

I wimped and made three units - you could use interrupts but if three pulses arrive together your code would have to be very light-footed (probably written in assembler).

Neil

Thanks Neil. Spotted another possibility on the Shumatech pages 'The data and clock pins also function as mode and zero buttons, respectively '. I hadn't thought it might be possible to control the Caliper with an Arduino. Something else to try.

The protocol used by my Powerfix Caliper seems to be a variant of BCD7. As Les said 'The waveform looks like 7 BCD protocol but the data is inverted.' It sends a single reading in the first five nibbles, each nibble being a Binary Coded Decimal number. The last nibble looks as if it contains the sign, and I'm hoping it decodes as described by Les.

I agree about interrupts. They're a challenge in lots of ways. Apart from the need to write tight fast code the Uno only supports 2 external interrupt pins, so pin change interrupts will have to be used to take on a third axis caliper. More new territory for me to get lost in!

Dave

I just wired switches across the lines, works fine. Despite what that site says, callipers and scales often have hidden features and mine go into 'fast' mode when you prod the right bits. Although 300ms is fast enough for most things the very brave could use fast mode to implement a closed loop servo CNC system.

Hi Dave,
It is only the 2 x 24 bit protocol scales that can be zeroed via the data and clock signals.Also they are the only ones that can be set to fast sample node. (Fast 40 samples per second normal 3 samples per second)
You need extra hardware in the interface to zero or set fast sample mode on 2 x 24 bit scales. The components in the grey area of my interface schematic are those that are only required to zero or set fast mode of 2 x 24 bit scales. I have only recently noticed that I have not put the resistor values (All 100R) and multiplexor part number (CD4051) on that part of the schematic.

Here are my notes on 2 x 24 bit protocol.

-------------------------------------------------------------------------
Scale protocol information.

2 * 24 bit scales

Data is sent as two groups of 24 bits.
Each group is a 24 bit binary number. The first bit received is the least significant bit.

Bits
are transferred LSB first! Also, data is 2's complement. (ie inverted Data signal at 0 volts = 1 at +1.5 volts = 0)

Static state of clock signal between frames Low
Time between start of frames 330 mS Normal mode 25 mS fast mode
Length of data frame 860 uS
Length of clock cycle about 14 uS
Time clock pulse is negative about 7 uS
Time clock pulse is positive about 7 uS
Initial high at start of frame about 52 uS
High in the middle of frame about 110 uS
High at end of frame about 80 uS

Clock in the data on the negative going edge.

The first group is the absolute position. It has some arbitary value at power on.
The second group is the relative position. This will be zero after the zero button is pressed.
Its value will be the difference between the absolute value when the zero button was pressed and
and the current absolute value.

48 bits in a frame of data

CPI 20480

-------------------------------------------------------------------------

Les.

Edited By Les Jones 1 on 09/08/2017 22:46:02

Edited By Les Jones 1 on 09/08/2017 22:48:20

AVR interrupts are very good, you have lots and they are well behaved, but you do have to manually save and restore any registers you use, it only saves the program counter to the stack automatically. But with lots of registers*, you can use a few for key variables rather than using normal RAM (advantage of assembler over C) and speed things up a lot.

*They aren't really registers, just privileged memory locations, sort of half way between real registers and the 6502's zero page.

Hi Neil,
I like the fact that the AVR chips have vectored interrups so that you don't have to sort out which type of event caused the interrupt as you have to do with a PIC. If you are interested in the source code for my interface that uses an ATtiny4313 then let me know and I will email it to you. (The current version is the one that also works with the Wixey type angle gauges. It supports 2 x 24 bit, 7-BCD, Bin6 and iGaging scales) It also gives the option of enabling fast sample mode on 2 x 24 bit scales.

Les.

Another progress report. Yesterday was another baffling waste of time. Despite careful checks of the program and wiring, and trying different ideas, I finished the day still getting incomprehensible readings off the caliper. I went to bed thinking 'very strange' and decided to start again this morning from first principles. Alas, if only I'd done that first! Or taken any notice of the clues!

I wrote a simple program this morning to prove that the Arduino was catching the pulses sent by the caliper. It looks like this:

The oscilloscope output from the program reveals a big problem:

There should be a yellow pulse each time the blue line drops. It can be seen that I got 1,3,2 and 2 yellow pulses rather than 1,4,4,4. Also it can be seen that the first yellow pulse doesn't appear until 9μS after the blue drop that triggered it. The root cause of this failure lies in the speed my particular caliper sends data. Roughly 3 times a second, it sends a frame containing 7 bursts of 4 bits. The whole frame is sent in 780μS and the all important blue pulses are only 6μS long.

The problem is that the Arduino digitalRead() function takes about 5μS to do its stuff. As the pulse it's trying to read is only 6μS long, there's a good chance that pulses will be missed. And they are!

The good news is that the problem can be circumvented I hope. Turns out that digitalRead() is slow because it hides a lot of complexity from the programmer. 5μS is fast enough for most purposes and the function keeps life simple. However, there are faster alternatives, which is what I need.

In general the alternatives to digitalRead are much harder to understand. Assembler, Macros, Bit Twiddling and other advanced under the bonnet stuff. However I've found a library called DigitalIO that looks like a good compromise. Provided the programmer guarantees not to change pin numbers at compile time, PinIO is much faster than digitalRead().

The revised program looks like this:

Running the PinIO version shows that it's fast enough to keep up with the caliper:

The moral of the story is not to make assumptions. As Bob's caliper is somewhat similar to mine, I assumed that tweaking his logic would work. I also assumed that the Arduino would easily be fast enough to keep up with my caliper. There's nothing wrong with Bob's logic, but using digitalRead() makes it too slow for the protocol used by my Powerfix caliper. No wonder I couldn't understand why nothing I tried worked! Arghh!

I've high hopes that my next report will be success. Don't bet the farm on it though, I keep underestimating this problem. It ain't over until the fat lady sings.

Dave

A different approach might be to read the ports directly. Reading the guff, the A2 pin is bit 2 of PORTC, so putting

value = PORTC & 0b00000100

will return 0b00000100 if A2 was high and 0 if A2 was low. At least it works with PICs (which I used to mess with), and reading the literature suggests it works in Arduino.

Whether this is faster is beyond my pay grade, but actually addressing or reading ports means you can do a lot in one line, and it doesn't make your head hurt once you've got the hang of binary arithmetic

I think you can cheat and put

value = PORTC & 4

and the return would be 4 or 0, but it might be slower, it would have to convert the 4 into binary, and anyway it makes more sense to me the first way.

Hi Duncan,

Yes it would be a lot faster but it's not as easy, at least on an Arduino, as your example implies. There are 3 registers to set up with the possibility of squishing something else. (The blurb says 'Note that some bits of a port may be used for things other than i/o; be careful not to change the values of the register bits corresponding to them.' ) Low-level stuff is often a right fiddle to get going and, being lazy, I avoid it if I can.

I made much better progress today and can now display caliper values correctly! That fat lady isn't singing though. My sketch loses the most significant digit on readings above 99.99 and can't detect negatives. Sounds like a small bug but I fear it's a nasty one. As the sketch goes wrong reading bits late in the frame I infer the timing is drifting off so that data reads half way through the frame are mistimed. Close but no coconut.

This is what the code looks like now:

Just as well I'm busy this weekend. I need to sleep on it.

Dave

Just to finish this one off, in case anyone needs such a thing I've put two working Arduino sketches for decoding a BCD7 caliper in this Dropbox folder.

caliper_int.ino captures data from the caliper with interrupts generated by the caliper's clock signal. This code is can easily be extended to read more than one axis. (An Arduino Uno has two external interrupt pins, enough for X and Y. If Z (or more) measurements are needed, the easiest solution is to change to an Arduino Mega because it supports 6 external interrupts. )

caliper_bob_mcN.ino captures data from the caliper by waiting in a loop until the clock changes. It's based on Bob's program, altered to decode BCD7 protocol.

I made a mistake about why 'My sketch loses the most significant digit on readings above 99.99 and can't detect negatives.' Not a timing error as I thought. C programmers will enjoy my discomfort. It was due to writing:

value |= 1 << i;

when, because value is a long integer, I should have said:

value |= 1L << i;

Subtle eh. Most C/C++ compilers issue a Warning, the Arduino IDE doesn't. Not sure why not!

Dave