Categories

# My method of measuring pulley efficiency

Tuomas Pöysti 2020

In the realm of rock climbing, rope access and other disciplines that use fairly similar equipment, there seems to be no “industrial standard” for measuring pulley efficiency. Surely the whole thing is not that big a deal, even though every textbook that has something about pulley systems tend to mention that pulleys and pulley systems are far from 100% efficient. At least Petzl has published some values for their devices, but nothing specific about the method they used to measure them.

## Other methods

I’m not sure why I got interested in pulley efficiencies. Probably because it is one of the most obvious “science” thing one can do with a couple of load cells. Of course I started with more spirit than reason. I should had at least read about Richard Delaney’s method (it’s behind pay wall, but if you are interested in my stuff, you should support Richard!), but as I said, more spirit than reason.

Richard’s method is clever. It is based on a weight as the means of putting the rope under tension. This is also what most people expect, because this is usually what pulleys and pulley systems are used for. Additionally, this method only takes one load cell, even partly compensating for some accuracy issues. I’m not going into details to respect Richard’s immaterial rights – and if it’s not Richard’s invention, then it should be searchable elsewhere.

## Definition of efficiency

This is actually a surprisingly messy subject. I admit making many mistakes by assuming that pulley efficiency is simply the ratio of rope tensions on different sides of the pulley. Let’s say we have the input side and the output side, input side being the one the rope is pulled from – that is, where the energy goes inside the pulley.

Energy is the product of distance and force, and both ropes move the same distance. So efficiency is simply force ratio

eff = Fo/Fi,

where Fi is the input force and Fo is the output force, right?

Of course that is not enough. The rope needs to be moving to tackle possible difference between static and dynamic friction. But even more so to make sure the force ratio measures the rope-sheave combination’s reluctance to roll because of friction. Any ratios won’t do, just the one that is enough to make them roll.

## Weight or what?

The idea of using a weight is of course to measure what force is needed to steadily hoist it. The hoist needs to be steady, because otherwise it would be a false assumption that only G (weight) affects on the left side. There would be also ma, mass times acceleration – or in everyday language, “all kinds of bumps and other dynamic stuff”.

I have always been a bit against using a weight. I have to admit the most likely real cause is that I don’t have a lab where I could easily hang a 100 kg weight. I have nice trees and bolted rocks around in the neighborhood woods, but this is something I want to be able to do at home.

I used to blame the dynamic effects. They are real, but one gets quite feasible results by hoisting a weight. This is something I have measured afterwards. This is a plot of force ratio (top) and actual forces (bottom) on two sides of a pulley, when a 15 kg weight was hoisted by hand:

This is how the actual data looks like. It is noisy from different reasons, but one could read a credible efficiency value there. 81% maybe? We must remember that all measurements have certain errors in them, and it’s better to be aware of them and face them proudly.

## Nuisances

There are other obstacles, too. Not all load cells are able to produce the accuracy/precision needed. If we want to squeeze the results inside error limits of +/- 1% , the load cells should be both precise enough and, especially in this application, accurate.

But that’s a simple one.

If some other thing than measuring error affects the measured forces even at the 0.5% level, the end result is as bad. Anything touching the load cells or even their cables might produce a 10N difference that ruins the measurement. My 10kN load cells weigh about 1.7kg each, so re-zeroing has to be done when the cells are in position. Etc.

## Using springs

So, no weights for me. I used a lot of time searching through hydraulic dampers, auto belay devices like Trublue (which are essentially dampers), tested whether I could use a rock climbing belay device to produce a constant braking effect. Anything that would brake smoothly at about 1kN force.

Then I thought about a long piece of rope. They are some kind of spring-damper combinations. Little by little I noticed the rope does not even need to be that long nor dynamic one (EN982). A couple of meters of EN1891 rope will stretch enough under 1 kN load to actually keep pulleys rolling. Not fast, but enough to make it a “dynamic friction” situation without a doubt.

## The outcome

Surely the load increases while pulling, but I have not found any flaws in that. I have two load cells for which I have written some code to be able to log both synchronously, calculate ratio in real time etc. This is a typical output:

The last graph is important. The first two have time (unspecified units) at the horizontal axis. The third, final graph, instead, is plotted against Fo, the output force. Thus, we can read in it the efficiency value at the point when output force exceeded 1kN or what ever we might be interested in. In this case, I’m happy to call 75%@1kN.

I routinely do three tests per pulley, use the average value and monitor average deviation.

## Self-criticism

Hopefully I’m aware of the weakest points of my method. I think the main one is it’s sensitivity to measuring errors, especially bad accuracy between the cells.

I tend to do a test pull before and after each test series, putting the cells in series so that they should give the same result. This would fail catastrophically if the load cell pair was hanging vertically, one below the other, since the 1.7kg weight of (especially) the lower cell would grossly ruin the result. Thus is, I do all my measurements in horizontal direction.

Typically the “calibration” test looks something like this

Notice the scale: the value that should be 1.000 varies between 0.995 and 1.001. The two drops might have something to do with the A/D converter of my homemade cell amplifier. Some day I will purchase a really good one. But anyway, I find this reasonable error for now. There are plenty of other variables involved, and this serves the purpose well enough.