I made a tool to help you compare cams

Kyle Tarry wrote:

Agreed.  Not only that, but the percentage rules are probably (no, definitely) not the same for all sizes of cams in all placements.  60% might be as far as you want to go on a small cam in uneven rock or rock that is crumbly on the surface, whereas 80% or more might be reasonable on a perfect granite splitter with a big cam.  Comparing overall range is really the only sensible way to do this.

Are you sure about that?  The Metolius numbers definitely do not match the UIAA testing requirements.  It's possible that Metolius has specifically tesed their cams at these sizes, and that they work are these sizes and don't work outside of them, but I think that is highly unlikely.  For example, in a lab environment, there is no reason to expect that a nearly tipped out cam (say, 95%) won't pass a load test; it almost definitely will.  We don't place cams fully tipped out for other more practical reasons (walking, rock fracture, etc.).  I think it's very unlikely that the Metolius (or other) "usable range" sizes correspond specifically with test data, and far more likely that it is subjective guidance about where they think the cams should be used.

FYI, the UIAA requires testing at 25% and 75% of the total range for larger cams, and only requires testing at the midpoint for small cams (<5mm range).  I would be very cautious about assuming that load testing correlates with usable range in real rock.

I wasn't talking about the UIAA tests. The UIAA tests are fairly minimal. One would hope that cam manufacturers are doing more testing on their products than just the minimum required by the UIAA.

I don't know how Metolius arrived at their useable range numbers. I don't see any reason you're so sure that they didn't test that the cams work at those ranges. It's certainly not difficult to test.

In any case, my point is that just because the usable range is unknown to us doesn't mean it's ambiguous. "Ambiguous" means there's data but it doesn't indicate a consistent conclusion. In this case there isn't inconsistency in the data, we simply don't have access to the data. If cam manufacturers run tests on their products' usable ranges, I don't see a reason to believe the results are any more ambiguous than any other tests we know they run on cams.

EDIT: Alternatively Metolius may have based their ranges on a mathematical model for some specific stone. Maybe I'm being naive, but I very much doubt they simply made up those numbers.

David Kerkeslager wrote:

One would hope that cam manufacturers are doing more testing on their products than just the minimum required by the UIAA.

They might, but I don't think we should make any assumptions about what testing they may or may not do, unless we're familiar with their QC practices.

I don't know how Metolius arrived at their useable range numbers. I don't see any reason you're so sure that they didn't test that the cams work at those ranges. It's certainly not difficult to test.

I'm not suggesting that the cams don't work in those ranges.  I am strongly doubting that there is any test data that says they don't work outside of those ranges; here are two reasons why:

• The UIAA requires that you test cams at 75% of range.  Metolius' recommended max size is around 60-70% of range.  If they pass the UIAA test, this already "proves" that they work outside of the suggested operation range, if pull tests were the determining factor in this range as you suggest.  A cam cannot be UIAA tested to 75% and have a usable range at 60%, unless you completely ignore the passed UIAA test for some reason.
• In a lab/test environment, a cam should pass a pull test even if it's 90-95% open.  Yet, their suggested maximum size is around 60-65% of range.  As such, this simply cannot be based on a load test, it doesn't make any sense.  No cam would pass a load test at 60% and fail the same test at 70%, in a lab environment.  If cam range was based on lab load testing, they would be good up to very close to fully tipped out.

I think you're trying to draw a link between suggested usable range and rigorous scientific test data that doesn't exist.

In any case, my point is that just because the usable range is unknown to us doesn't mean it's ambiguous. "Ambiguous" means there's data but it doesn't indicate a consistent conclusion. In this case there isn't inconsistency in the data, we simply don't have access to the data. If cam manufacturers run tests on their products' usable ranges, I don't see a reason to believe the results are any more ambiguous than any other tests we know they run on cams.

I don't know, I think ambiguous is an appropriate term, along with possibly "inconsistent."  The reason for this is that they is no standardization, official or unofficial, on how to determine a cam's functional, usable range.  Not only that, but you could very justifiably have different ranges for different scenarios and different kinds of rock.  What if BD is assuming you're climbing on clean solid granite and extended every piece, and Metolius is assuming you're climbing on soft sandstone and clipped short so they might walk?  What would the test requirements even be?  What maximum force on the cam would you require?  Would you load the cam slowly (like in a lab fixture) or quickly (like in a real fall)?  There are so many variables that the ranges would be different for the same cam, and you'd be comparing apples to oranges, and you wouldn't even know it.

EDIT: Alternatively Metolius may have based their ranges on a mathematical model for some specific stone. Maybe I'm being naive, but I very much doubt they simply made up those numbers.

I think there is a lot of gray area between "test results or mathematical model" and "made up" that you're skipping over.  I highly doubt they have robust test regimens or robust math models, but the numbers aren't just made up either.  I think they are a judgement call, based on some internal standards they have, based on some combination of experience, gut feel, testing, and internal consensus.

Is there a way to search for all cams in a certain max/usable range?

Looks great! Can you add big bros and ball nuts too? :)

Cool web-app.  What technologies did you use (e.g., React, Angular, Webpack, etc.)?

Also, where does your app get its data from?  Do you pull from several databases?  How authentic/trustworthy is the data?  For example, if you're not pulling BD info from a BD-sanctioned database source, then you'll have to put some kind of disclaimer on the page.  In any case, BD and other companies wouldn't want just anyone speaking for them anyway.

I'm a web-app developer-noob.  Here's a crappy looking web-app I recently wrote...

https://the-game-of-go.herokuapp.com/

No, it doesn't have anything to do with rock climbing.

Here's another thought...  It might be nice if the ruler at the top stayed at the top, even if you scrolled the window.  I think that CSS3 calls this the "sticky" display style.

Taylor Parkin wrote:

Cool web-app.  What technologies did you use (e.g., React, Angular, Webpack, etc.)?

Also, where does your app get its data from?  Do you pull from several databases?  How authentic/trustworthy is the data?  For example, if you're not pulling BD info from a BD-sanctioned database source, then you'll have to put some kind of disclaimer on the page.  In any case, BD and other companies wouldn't want just anyone speaking for them anyway.

I'm a web-app developer-noob.  Here's a crappy looking web-app I recently wrote...

https://the-game-of-go.herokuapp.com/

No, it doesn't have anything to do with rock climbing.

Black diamond sanctioned database? lol this public info is available on almost any "specs" page that sells cams.  He probably puts the data in by hand into a flat database/file.  How would that even be remotely considered a liability?

Seth Monteleone wrote:

Black diamond sanctioned database? lol this public info is available on almost any "specs" page that sells cams.  He probably puts the data in by hand into a flat database/file.  How would that even be remotely considered a liability?

The reason is clear.  DB changes their specs page, which in turn invalidates his hand-edited flat database file.  Now he is misrepresenting BD until he updates his file.

Read about the concept here: https://en.wikipedia.org/wiki/Single_source_of_truth

My point is that he should have a disclaimer that reads in effect: Use this info at your own risk.  My opinion on cam sizes and ranges is not necessarily that of BD's or other cam manufacturer's.

Now, if BD exposed read-only access to a database that they maintain, then he could read from that to populate his page.  And yes, it is laughable that BD would even do such a thing, but that's what I imagined would be an ideal scenario.

I suppose my argument is still dumb when you consider that this information just doesn't change ever...  In any case, I'd still like to know where he got the original information.  Sounds like a lot of work to gather it off of a bunch of different web-sites by hand.

Taylor, your concerns would seem appropriate if cam-parison.com were made by a big company with deep pockets.  I've seen nothing on this thread to suggest that.

Serge Smirnov wrote:

Taylor, your concerns would seem appropriate if cam-parison.com were made by a big company with deep pockets.  I've seen nothing on this thread to suggest that.

Your right, it was a dumb suggestion, but something I thought about when I saw his visualization.

I'm new to web app programming.  It looks like he might be rendering a bunch of SVG elements.

By the way, I think JavaScript is a horrible language.  It might be getting better with ES6 though.

Taylor Parkin wrote:

By the way, I think JavaScript is a horrible language.  It might be getting better with ES6 though.

ES6 is worse IMO. It's JS for Java programmers who couldn't be bothered to learn prototypical inheritance or callbacks. It still has all the terrible "error handling" of JS, but now there are a whole new set of weird differences between class-based and prototypical objects, and promises and callbacks. Class-based objects don't even fix "this", which would be the only reason I would complicate the language with that. They're just bolting new features onto JS without much thought for whether they work with existing features, and without fixing the existing problems.

David Kerkeslager wrote:

ES6 is worse IMO. It's JS for Java programmers who couldn't be bothered to learn prototypical inheritance or callbacks. It still has all the terrible "error handling" of JS, but now there are a whole new set of weird differences between class-based and prototypical objects, and promises and callbacks. Class-based objects don't even fix "this", which would be the only reason I would complicate the language with that. They're just bolting new features onto JS without much thought for whether they work with existing features, and without fixing the existing problems.

All I know is that trying to make classes in JS (without the "class" keyword) is absolutely horrible and confusing to me.  (I still don't understand the "prototype" function.)  I think ES6 officially adds the "class" keyword.  But before they had it, apparently TypeScript (a superset of JS) was invented to overcome this limitation.  You know a language is bad if someone wants to come up with their own language that compiles into your language so that they don't have to deal directly with it.  That wasn't the case, however, with early C++ compilers.  They compiled down to C initially, but C wasn't a bad language.  Modern C++ compilers go straight to assembly.

I wonder if any browser will one day support a different embedded scripting language's interpreter.  Python?  That might be nice.

Really useful and well-designed. Love the filtering options, and ability to sort on size/brand/weight. Great contribution, thanks.

I updated the site.  Still haven't figured out how to deal with usable ranges, but I added a few things:

• Added the BD ultralight camalots
• Added the ability to visualize the cam weights
• Added a link to the data spreadsheet
• Added an option for log scale

I like the sticky scale at the top. My biggest want, though:

Build your own rack: click on/off cams and have a rack at the top or bottom that fills up with the selected cams, so that you could see where gaps are in your range, even if it's a frankenack!

Josh Gates wrote:

I like the sticky scale at the top. My biggest want, though:

Build your own rack: click on/off cams and have a rack at the top or bottom that fills up with the selected cams, so that you could see where gaps are in your range, even if it's a frankenack!

Use the sort by size to get basically that.

David Kerkeslager wrote:

Use the sort by size to get basically that.

Yeah, I'm not seeing that when I do the sort. It's far from easy to find an individual cam when sorted by size, much less compare three or four that are on different pages. 

Josh Gates wrote:

Yeah, I'm not seeing that when I do the sort. It's far from easy to find an individual cam when sorted by size, much less compare three or four that are on different pages. 

Are you not filtering out the pieces in your rack? Using the filter it seems like you can do exactly what you're asking. You can also change the coloring to use the cam color which makes it easier to find things.

Is there really a big gap between x4 .4/.5? 

As far as the Log scale goes, what's gained from using that? I'm not nitpicking I'm genuinely curious.

Edit: Would be cool to be able to click on a cam on the graph to temporarily highlight it. That way as you change sorting you can follow one or more cams around.

Andy Lei wrote:

I updated the site.  Still haven't figured out how to deal with usable ranges, 

Andy

I pretty sure Metolius is the only company using usable range and total range. The usable range that Metolius is using is really huge especially in the small sizes. Even what BD suggests in the instruction manual is ludicrous.

My suggestion is use the total range for all the cams and then do the math accordingly:

Below fingers 60%, fingers to off-finger up to 67% and hands up 75%

Chris Reyes wrote:

As far as the Log scale goes, what's gained from using that? I'm not nitpicking I'm genuinely curious.

A Log scale would allow you to more easily see the differences between the small cams on the graph (when both large and small cams are included in the graph).  A Log scale effectively stretches the scale for small values, and contracts it for large values.  It is especially suited to cams, because cams use the logarithmic spiral and therefore the range of each cam is proportional to how the large the cam is.

That said, I think a Log scale could be confusing for a lot of people, and probably shouldn't be the default scale.  Log scales can also be difficult to read in some cases.