Timing belt measuring bench

[krista]

Edit in 2020: seems the pics all went away. There is another write up here with pics https://bit.ly/2YtZYGB

____________________________________________________________

My business sells aftermarket components for Ducati motorcycles and I always strive for the best quality possible. With the timing belts being such a critical component, I wanted a way to accurately measure their length, which became a long and entertaining process in understanding the fundamentals.

The finished product: The plastic box next to the control panel is also bolted to the bench and holds the various springs and "blocks" used to tension the belts of different lengths. Conveniently, the power pack (or wall wart) for the bench fits in there, too!




And its display:


The display is an Adafruit 1.8" TFT "shield" for the Arduino Uno. Everything you see is based on the "encoder position", which is the current center to center (c-2-c) length in microns. That gets converted to mm, which then gets converted to both inch c-2-c as well as belt length. The units are somewhat mixed because that's how different vendors and I communicate about these things. From the belt length, we can divide by the HTD spec of 9.525 mm pitch between teeth and get a fixed number. That's the "89T" in the screen. Then we can know that it's a 999 belt and finally divide the calculated length by the tooth count to get actual tooth pitch for this belt of 9.559 mm. Let's see, 9.559 - 9.525 x 89 teeth = this belt is 3.4 mm too long?? Nope, the belts Gates makes for Ducati do not conform to Gates' HTD pitch specification. When we made our belts the correct length, they were too tight...

The sliding block is attached to the CNC/DRO glass scale with 1 micron resolution. Life might have been simpler if I just settled on the 5 micron resolution scale, but we always want the best, yes? After 4 or 5 attempts at reading the quadrature output from the scale directly with my Arduino, I ended up with the best (or 2nd best) possible option, the LS7166 Quadrature Counter IC, which is also possible the most complicated IC to set up. These folks' notes helped me find out I could skip some steps setting up and that a couple inputs shown as optional required setting to +5V or GND. This still wouldn't have been possible without an o'scope to help!

I used the single trigger mode to capture all the signals using D7 as the trigger. D7 happened only once and consistently when I ran my init_7166() function.


Then I compiled a master timing sheet for the initializing of the 7166, which by the way is not correct final desired result. Once I got it working, I didn't repeat the misery of setting this up:


Ultimately, the bottom two data lines, D1 and D0, should stay at a steady value until transitioning to something else. So D0 should start off HI, switch to LO right away and then on the 6th and 7th purple dividers later, switch to HI. And so on. I played with this in photoshop until the background was white and the waveforms would show up on the printer. Printed it, made notes and adjustments, then got it to read values from the glass scale.

With careful measuring, I was able to determine the minimum center-to-center ( c-2-c ) length of the sprockets on the bench. Of course, the best hand tools can only guess to about a 20th of a mm (or 50 microns). But after measuring it a dozen or so times and different ways, I came up with 8.616", so went with that.

At about the same time the LS7166 came in, I also got in the Freetronics Eleven, an Arduino Uno compatible clone that has a prototyping area on it, which is where I mounted the 7166 in a socket. BTW, the guy at Freetronics is about as crazy for quality as I am. His boards have gold plated pads so people like me can solder on it reliably! Boards with tin traces can have the trace accidentally lifted off and removed if not careful enough. BTDT.

7166 mounted in the Arduino Eleven with my crazy wiring (yes I soldered all those wires):


Wiring diagram for the setup: (note that the chip is mounted to the bottom of the Arduino Eleven so pin locations are flipped on the Arduino diagram)



The big breakthrough was Friday night, when I tied pins 3 and 4 to +5 and ground. I reset it, moved the block, and it started measuring shorter distances. So I swapped the A and B inputs from the encoder, the yellow and green wires going to pins 6 and 7 of the LS7166.

To help model the bench, I made CAD drawings of the acrylic food box, the Freetronics eleven, and the Adafruit 1.8" TFT shield.

The sketch code for the Arduino is here. It's all open source, so now you can make one, too!  

[krista]

The work leading up to the finished product:

Keen observers will notice in the CAD drawing of the Freetronics eleven that it is shown with a HCTL-2000 quadrature decoder & counter chip used. And the required wiring even looks pretty. The HCTL-2000 has a 12 bit counter, so the number of microns in the scale's 6+ inches of travel exceeds 12 bits. So I ordered in more ICs from the HCTL family, the 2016 and the 2020.

Well, see they have this pin labeled "CLK". That means clock. I was already looking at having to use an IC because the Arduino all by itself couldn't read the quadrature signals fast enough!! Initially, I set the Arduino to trigger an interrupt on CH A "falling" of the glass scale. Then if CH B is 1, the scale just moved a micron one way. If it's 0, the scale moved a micron the other way. Technically, only reading on CH A falling means I get an interrupt every 4th micron... There's lots of discussion on the intarwebs when it comes to Arduinos and quadrature decoding, sadly all of it to do with reading the output from CNC motors to keep track of position.

I quickly found the scale could be moved fast enough that the Arduino would skip some of the instances of CH A falling!! Grrrr. People said on the internet that the Arduino's interrupt would only take about 5 microseconds.

Out comes the oscilloscope (o'scope):


What you can't see is that I was barely moving the sliding block to the left! And the scope is set to 1 milisecond per division, so that's about 1000 microseconds per trigger. When I move it faster but not trying to go really fast, I can tell it gets down to 5 microseconds pretty handily.

So what's next? The Arduino can't hang with reading the quadrature input directly. I read on the intarwebs that one can use a pair of D flip-flops to read the encoder, which then just sends UP or DOWN outputs to the Arduino. Sweet! I know I've got some 7474 ICs left from when I was a BSEE student... Yep, wasn't too hard to wire up on the breadboard and hook it up. MUCH better performance. I was almost convinced... until one time releasing the springs testing a belt, the block moved super-quickly. Sure enough, the readout was about 0.004" wrong. It managed to skip about 100 down pulses from the D-FF.

I Google, read intarwebs, and find out about the HCTL family of quadrature decoder and counter ICs!! Nice, there I go!! I get in a HCTL-2000 from Amazon or eBay and start setting it up. Oh, yeah, here's where we started this crap out... the CLOCK. Effing clock. So I work on getting the Arduino to output a clock from one of the few remaining pins on the poor damn thing. Turns out data pin 9 is connected to one of the onboard timers AND is also unused in my design! Sweet. Google, read, interwebs, blah blah. I can set up a timer that uses interrupts and route it to pin 9. I get that going, upload the code.... wait.... oh, this is too slow.... I watch the screen draw at like 10 pixels a second. The poor Arduino is fully taxed trying to run a 1 MHz clock.

Google, read, interwebs, blah blah, you can route the Arduino's onboard 16 MHz crystal to a pin but that requires burning new firmware into the processor, could ruin it, blah blah, need a FTDI blah blah. Open the data sheet for the HCTL family again. Oh, it only wants 14MHz. So that won't work.

The BSEE part of my brain was starting to come back to life and I knew we used 555 timer ICs for clocks. Thing is, they're only good to somewhere south of 1MHz... and 1MHz corresponds to a period of 1 microsecond. That's cutting it close! I tweak this 555 timer to very reliably get near 500kHz, or a 2 microsecond period. That took a whole day. And that is about the time that I realized I was going to need a better IC because the HCTL-2000's 12 bits weren't enough. Google, read, interwebs, blah blah, and I see that I can probably get a crystal of my own and then use a D-FF to step down its speed to clock the HCTL. Now I've got 3 components to add to the breadboard.

That was when "Google, read, interwebs, blah blah" showed me the LSI corp LS7166. Datasheet comes up and hmmmm, no clock input?! Sweet! Because it is asynchronous, it is autonomous and can just sit there counting. Hmmm, 20 pins. 6 control pins(!) wth, I don't have that many outputs available. 8 data pins, Ah, ok 4 control pins, phew!

[krista]

"So Chris, why didn't you just use Calipers like everyone else on the intarweebs?"

After lots of    and NO 

Well, actually, I did:


Shown is a 21 bit "Chinese scale" that needs a 9kHz clock of 21 pulses and replies with a binary number. This actually worked really well. Only over about 10 minutes of reading belts, it would develop an error of 0.001" to 0.002". Continued use continued the error growth. Because these are capacitive, they're not 100% positionally accurate. It's just like the cheapy DRO readout on my lathe. I always measure, double check, and reset the numbers before a final cut. Or it'll be a little bit off.

What about the DRO on my vertical milling machine... the Mitotoyo DRO is like forever accurate. Google, read interwebs, blah blah. That's called a glass scale...

I hope you enjoyed it and if you actually read all of this!
Chris

[SpikeC]

 Um.... what was that again??

[jaxduc]

This is intense.
I just looked at the pictures.

[suzyj]

Mitutoyo gear is very nice. I have a set of Mitutoyo verniers at work, and they never seem to need zeroing. When I worked in Sydney, we had a measuring microscope with Mitutoyo readouts that were good to like 0.1 thou. Seriously nice stuff.

Your belts can't be too far off, as my bike quite likes them.

[lazylightnin717]

Your belts can't be too far off, as my bike quite likes them.

Agreed

Nice read Chris and keep up the good work!!

[ChrisK]

Whatever just happened above... I think it confirmed why it's worth it to purchase from Ca-Cycleworks. True dedication to product.

[krista]

Heheheh, thanks y'all

Your belts can't be too far off, as my bike quite likes them.

Thankfully, we are talking about convenience and minutia. Timing belt technology is old news. Anyone making belts knows what it takes to make a quality belt and knows tricks of the trade and shortcuts to make. It took a couple years of research and discussions with a top tier US importer-manufacturer for me to become comfortable enough that I could sell timing belts and wouldn't be the cause of engines breaking. I'm my own toughest critic and it wasn't easy to convince me to take this on.

I know the cheaper-than-ours OEM 900 belt isn't made to the same specification as OEM 1198 belts or Cycleworks' ExactFitTB 900 belts. BUT I don't know how much I'm allowed to compromise, so all of our belts are manufactured the same way that the 999 and 1098 belts are made: full-on aggro with no corners cut. In 2003, when I first held testastretta belts in my hands, it was obvious they were made to higher specification than the 900 and 916 belts I previously had bought from Ducati.

Back to the above aggro measuring machine; we were told of a certain length variance from our manufacturer. And then we get feedback from mechanics at shops which occasionally contradicts what we were told by the manufacturer. And given how the OEM parts are waaaaaaaaay off what would be Gates' own HTD specification, I needed something to quantify the difference between two belts accurately. And "close" isn't going to work.

This is also why we're on a quest to get used belts. I really like some used belts from S4 and S4Rs (and ST4s and 2002 748s). These are the 93 tooth ones for the droopy head desmoquattro. It's the latest (and hopefully last) belt that shops have been talking about. We've already stretched out the 996 and 748R belts by 2mm so they wouldn't be too tight.

Knowing how long used OEM belts are tells us what the end goal is for our belts' lengths. Since ours don't stretch as much as OEM, they need to be created with a longer length.
 
-Chris

[bond0087]

Nice work, and kudos on open-sourcing it!

So in the spirit of open source collaboration, here is a question:

When you calculate the belt length, you use

Code:

	mmLength=(mmLength*2)+(beltDiameter*3.14159);

where

Code:

float beltDiameter = 55.7000;  // diameter of belt cords on sprocket, in mm measured by hand

Shouldn't you be using the pulley pitch diameter there rather than a hand measurement of the cord diameter? See http://www.gatesmectrol.com/eng_asst/Belt_Theory.pdf for where I'm coming from. Normally, I wouldn't bother mentioning the distinction, but with the precision that you have here, I think it would make a difference.

I think that I saw in your code that it is a 3/8" nominal belt pitch, and by my counting on your picture, there are 18 teeth, which would make the pulley pitch diameter (.375*18*25.4)/(3.14159) = 54.57mm

I don't do much with rotating machinery, so you have more experience than I do with how belt lengths are specified, but I would think that they would be specified along the neutral axis, in which case I'm fairly sure that you would want to use the pulley pitch diameter.

PS: If you ever are working on a more accurate belt tension measurement via free response natural frequencies, get a hold of me; my research area is health monitoring with vibration analysis.

PPS: Check out the beaglebone black for future projects; it has quite a lot more horsepower than the arduino; you can run a full linux desktop environment, with io connectivity like the arduino. Probably a steeper learning curve for this type of stuff, though, and not nearly as lightweight as this is. Still, worth a look.

[krista]

Yaaaay! Someone noticed! I kind of forgot this part, but it was the most mathematically enjoyable portion of all my little adventure into what is belt length.

I got this figure out of a technical PDF about measuring timing belt length:


But nowhere do they say how belt pitch and sprocket pitch are determined. They kind of gloss over that. As does the industry about ACTUAL belt pitch. "oh, yeah, those are 9.525, so your 95T belt is 904.9 mm long." And they're wrong because those are not the 95T HTD belts made for the 916.

So... I know that our belts are greater than 9.525" pitch by fact that the 916 95T belt is actually a standardized belt used for automotive and industrial applications. The TB996 belts we started making were properly made. But were tight. And the 748R, which is a 996 belt that's wider simply would not install. At all.

Out comes my Romer metrology arm & two TB1198 belts we got back from a shop were clamped to the table. This is exactly what actually "started it all"... they said one belt was too tight to install because at the loosest belt tension, it was over 150 Hz. And the other belt would install OK. I got both of those belts back.


OK, fine, so I measured a belt...
... I put the numbers into a spreadsheet:


And then I actually started the setup of the measuring bench and put the 1198 belts into it. Looking at the diagram from the manual (I forget if that was Gates or Continental material) and having measured the pitch of two belts, I now could find how to equate center to center to belt length. It is along the cord's path. I spent a few hours playing with this with a few different belts (especially once I had the Chinese slide scale working and was computing the diameter v belt length).

See the r1 x1 stuff, that was measuring the belt with CMM arm while the belt was stretched on the measuring bench. 55.70 mm was arrived at as the best pitch diameter to match the measured belt pitch via the CMM arm to the measured belt c-2-c on the new measuring bench. The bolts for the sprockets were put in the lathe, squared off and 1/2" rounded divots added in their centers so the CMM arm's 1/2" NIST calibration ball would fit into them nicely.

Because ALL of our belts are made the same way, the cords are the same distance away from the center of the sprocket. Thinner belts, like the inexpensive OEM 900 ones, would need the diameter variable adjusted. This is something my software could account for, since it "knows" which belt it is measuring at any time.

BUT, going back to the reality of my situation, I am not changing the sprockets on my bench and with them, the diameter is 55.70mm with the ExactFit belts. Given all that, if the center to center distance is greater on one belt than another with the same springs pulling on them, then one belt is going to be longer than the other. The c-2-c won't ever be in question.

There is no absolute reality about a belt's length. I am probably the first near-to-end user to give any thought to it.

Thanks,
Chris

PS - yeah, actually, I was looking at the Raspberry Pi but since I have experience with Arduino and I know how it works with IO, I'm kinda all over that. I thought this would be a quickie project.

[Privateer]

[krista]

 

[krista]

So in the spirit of open source collaboration, here is a question...

Dang it, now I want to get out some belts, the CMM, and have a little math party... Need to find the parts to calibrate the CMM arm first. Through all this, I was able to prove a 0.003" error in 24" wide measurements...

"What is 1?"

[bond0087]

Haha, sounds like I've opened a can of worms!

That's interesting on how you worked out the effective pitch diameter based on CMM readings.  I agree that in your situation, when you're comparing apples to apples, as long as you are consistent, you'll be able to distinguish between belts well because you have good precision. For quality assurance, that's more important than absolute accuracy.

I'll have to take a look at the belt section of my copy of Shigley's Mechanical Engineering Design when I have a chance at work tomorrow, and see what that has to say about timing belts.