Idea for a new LRS backup/cache management device

Hey y'all, Evan Freeman's post about his upside down fall with a Sulu Go convinced me to share an idea I've had for an LRS backup and cache management device. I backed the FreeBell project on Kickstarter, but because I'm impatient, waiting until September to (hopefully) receive mine made my mind start thinking of alternatives.

My idea is based on the principle found in the Traverse Rescue 540° Rescue Belay, which you can read more about here: http://www.verticalmuseum.com/VerticalDevicesPage/Belay/BelaySpoolPages/BelaySpool0756.php

Dr. Gary Storrick, operator of the Vertical Museum web page, has this to say about the operation Traverse Rescue 540° Rescue Belay:

The 540° is rigged by opening the front plate, wrapping the rope one and a half turns around the spool, and closing the front plate. The spool should be centered with the release lever if necessary. When a heavy load is encountered in use, the spool will rotate to one side and squeeze the trailing end of the rope between the spool and the wing bars. This provides a dramatic increase in friction (you do remember the snubbing formula, don't you?).  

The device works really well for what it is! I bought one off of eBay and played around with it. The rope runs smoothly around the spool with much less force than the Yomi, more force than a MicroTraxion, but not too much to be uncomfortable for single pitch climbing. The problem with using the Traverse Rescue 540° Rescue Belay as a backup and cache management device is this bit: 

The block [ed. spool] is free to rotate on the shaft to about 25° either side of center. A spring-loaded clutch holds the spool in one of three equilibrium positions: left, center, and right.

The spring loaded clutch is the problem. If the spool were free to rotate on the shaft, then the device would lock on whichever end of the rope was experiencing the most force. In our use case as a backup and cache management device, that means the weight of the dead rope would cause the device to lock on the dead rope, maintaining whatever cache loop we had. But when you pulled the cache loop side of the rope, three things could happen:

1. If you pull weakly, with less force than the weight of the dead rope, nothing would happen because the device would stay locked on the dead rope side.
2. If you pulled with exactly the force of the weight of the dead rope, then the device would unlock and you could pull out some additional cache loop; you've unlocked the device by balancing the forces on both sides of the device. Neither side of the device is locked in this scenario, but when you let go of the cache loop, the device would lock again because the weight of the dead rope would rotate the spool back into the dead rope locked position.
3. If you pulled with more force than the weight of the dead rope, you would rotate the spool so that it locks on the cache loop side.

As you can see, to get the cache loop side to feed, you have to pull with exactly the right amount of force, which will change when you have more dead rope hanging off the device as you climb up. This is not ideal; you don't want something with such a small and changing sweet spot to operate.

This is not too difficult to remedy; add a spring to the spool so that it holds the spool in the dead rope locked position by default. If the spring is set so that it only begins to act once the spool is rotated past about the center (unlocked) position, then you've given yourself a window where you can pull up with the force of the weight of the dead rope, then add more force. At some point of adding more force while pulling up the rope, you'll max the spring out and have rotated the device all the way into the cache loop braked position. But by finding the right spring tension, you can give yourself a wider window between not enough force and too much force when pulling up on the rope.

The real trick is this; the rope is always running around the spool because of the 1.5 turns. Regardless of the orientation of the device, when the rope moves through it, it is trying to rotate the spool. In the case of an upside down lead rope solo fall where your main belay device fails to catch you and you have this as your backup and cache management device, these things are happening:

1. The live rope is zipping though your main belay device with no resistance
2. The dead end of the rope is still held by this backup and cache management device in the dead side braking position
3. Your cache loop is getting smaller
4. Once your cache loop runs out, rope must begin passing through this backup and cache management device, from the dead side to the live side
5. Because of the 1.5 wraps of rope around the spool, as rope passes through the device, it rotates the spool, in the case from dead side braking position to the live side braking position. You may be wondering about the spring in the spool; I strongly suspect that the rope zipping through the device is a stronger force than the spring and the weight of the dead side of the rope and will overcome the spring force.
6. The spool has rotated to the live side braking position, either stopping you completely, or adding enough force to flip you back upright and allowing your main device to begin working again

I've drawn up a handful of prototypes and machined a couple different spools to find one that seems to work well on my 9.5mm rope without being as large as the one in the Traverse Rescue 540° Rescue Belay. I've sent off to have some of the sheet metal parts made by Send Cut Send because I'm not great at working with sheet metal. I plan on making a couple, then tweaking the design until I get something that has the right ergonomics. I plan on making the torsion springs for the spool myself until I find one that works right, then I'll order some proper springs. Once I'm happy with the design, I'll see if I can destructively test one at work on our big tensile tester. After that, I'll probably make a few more and see if anyone here wants to try it out on the ground (or heavens forbid, in the real world!)

Finally, here's a screenshot showing one of my early designs. I've since changed the design so that the spool axle is offset, just like the Traverse Rescue 540° Rescue Belay's. I've also changed the design so that it opens in a different manner, with all hardware captive and not loose, and also the slots allowing it to rotate open are positioned so that the forces always act to keep it closed tightly rather than what's shown here.

This is a pretty simple device, and hopefully an interesting addition to the FreeBell (which is a super neat design that I can't wait to try out!).

(The teal part is the rope, the magenta part is the spool, there's a torsion spring in the spool around its central hub, the golden part is the spool's axle, and the tan parts are the braking bars)

Anyway, let me know what y'all think, and especially let me know if you there are flows with my logic or design! (I'll clean up my Solidworks file  soon so I can get a screenshot of the latest iteration)

I am not a smart man. This would be more gooder than the freebell? 

Ricky Harline wrote:

I am not a smart man. This would be more gooder than the freebell? 

Nope, not at all! Just different, and crappier in a couple ways.

First, the FreeBell is only about one rope thickness thick, plus a little bit of material. My device is at least two rope thicknesses thick, plus a little bit of material. So mine's bigger in the more annoying direction.

I think they would have a similar action, in that you have to balance how much force it takes to engage in one direction (the oh shit, I'm falling upside down please god let my backup device catch direction) vs the other direction (hold my cache loop direction). I think the FreeBell achieves this by having the cache-loop-hold function be performed by that sprung little rotating piece at the bottom of it (which really doesn't need to be all that beefy), and the catching-a-fall function performed by the one way wheel with a sprag clutch (which does have to be beefy). My device doesn't discriminate between sides much, so wastes a lot of material being needlessly beefy on the cache-holding function.

Another way mine is different and probably worse, is that the device does need to overcome the dead rope force and a bit of spring tension before it locks on the cache rope side. So there's gonna be some amount of slip before it catches. I don't think it's nearly as much as a Revo or Silent Partner, but there will be a little bit of rope motion before it catches.

One way that it's better is that I can make mine right now!   Which is only good for me, unlike the FreeBell which will be available to everyone who preordered. Nah, I just really like making stuff and coming up with different things so this was me putting my stuff out there for others to see and critique.

I have another idea that I worked on for much longer to subtly modify several assisted belay devices to make them super nice for half rope belaying. But I'm keeping that one to myself for now, because I haven't seen anything else that functions like it either in collections of vintage climbing and rope work devices (like Vertical Museum) or in a few dozen patents I've looked through. And I really want a patent with my name on it   

Here's some screenshots giving a better idea of how my idea works. Note that no spring is shown in the spool. It's not important for the diagrams to be descriptive, but if you imagine a torsion spring constantly pushing the spool a bit to lock the dead rope side, that's kind of all there is to making the window of force required to pull the cache loop without locking larger. Also, I don't have a good way to draw ropes in Solidworks; forgive my noodly abomination. Also, when either side is locked/braked, so is the either side, so those descriptions are kinda weird. My b.

Edit: Man, on second thought, just ignore which "side" I say gets locked/braked. In reality when the device is locked/braked, it's holding both sides of the rope, both the cache loop and dead rope side. The weight of the dead rope pulls the device one way and locks it. 

1. When you pull the cache loop side, you must overcome the weight of the dead rope (like normal with a Microtrax and every other cache loop management device) which unlocks the device and lets you pull more cache loop through.
2. When you let go, the weight of the dead rope takes over again and locks the device back up. 
3. And if you fall and your main device fails, your cache loop runs out, you overcome the weight of the dead rope, but you also overcome that torsion spring you can't see in these screenshots and lock the device back up in the other direction (which brakes both sides of the rope).

I really need to figure out how to animate this.

Super cool Duncan!
Very much in a similar category of design to the freebell, but the extra turn of the rope seems like it will cause functionality issue.
Wrapping a rope around that center "bollard" adds lots of squeezing force and as the dead side gets heavier will squeeze even more.
My first reaction is that it won't feed well. Like pulling with one handed to the cache loop side, will it be easy enough to be functional.....especially as that dead end rope weight climbs.
Can you offer some insight around that conundrum I see with this design? Maybe I'm missing something, but it really seems like that extra turn is gonna provide engineering challenge for use as a solo backup/cache device.

Mr Rogers wrote:

Super cool Duncan!
Very much in a similar category of design to the freebell, but the extra turn of the rope seems like it will cause functionality issue.
Wrapping a rope around that center "bollard" adds lots of squeezing force and as the dead side gets heavier will squeeze even more.
My first reaction is that it won't feed well. Like pulling with one handed to the cache loop side, will it be easy enough to be functional.....especially as that dead end rope weight climbs.
Can you offer some insight around that conundrum I see with this design? Maybe I'm missing something, but it really seems like that extra turn is gonna provide engineering challenge for use as a solo backup/cache device.

Sure, I can definitely see that as the dead side of the rope gets heavier there would be greater friction around the spool/bollard. I hadn't yet tried it with a lot of dead rope weight.

While playing with the Rescue Traverse 540 device on the ground, the rope runs very smoothly through it, as well or better than a Silent Partner (it's been years since I used one, though). But that was without more than a few feet of dead rope hanging off of it.

The Rescue Traverse 540 is quite large, so I made a few prototypes of the spool/bollard that were smaller while still providing smooth feeding. I definitely found out what was too small with my 9.5mm rope and a few feet of dead rope. Hopefully the size I settled on for this latest full prototype isn't too small with a whole 35 meters of rope hanging off of it!

I'll test in the next couple of days to see how well the rope runs around the spool/bollard with varying amounts of dead rope weight. I might have to make the spool/bollard a bit bigger again!

What is meant by an upside down fall? 

Adam R wrote:

What is meant by an upside down fall? 

falling with your head towards the ground and feet towards the sky. Happens scary fast and easy if you happen to fall with the rope behind your leg, for example

Mr Rogers wrote:

Super cool Duncan!
Very much in a similar category of design to the freebell, but the extra turn of the rope seems like it will cause functionality issue.
Wrapping a rope around that center "bollard" adds lots of squeezing force and as the dead side gets heavier will squeeze even more.
My first reaction is that it won't feed well. Like pulling with one handed to the cache loop side, will it be easy enough to be functional.....especially as that dead end rope weight climbs.
Can you offer some insight around that conundrum I see with this design? Maybe I'm missing something, but it really seems like that extra turn is gonna provide engineering challenge for use as a solo backup/cache device.

I tried it with ~33 meters of rope hanging out of the Traverse Rescue 540 and it definitely sucks, it's way too hard to pull down with one hand for lead rope solo. So much for that idea! Thanks for bringing it up, I hadn't thought the extra weight of the full dead rope tightening the rope's grip that much.

Duncan Domingue wrote:

I tried it with ~33 meters of rope hanging out of the Traverse Rescue 540 and it definitely sucks, it's way too hard to pull down with one hand for lead rope solo. So much for that idea! Thanks for bringing it up, I hadn't thought the extra weight of the full dead rope tightening the rope's grip that much.

Duncan! Thank you for bringing this little quest of yours to this forum. I totally see why you were inspired, and honestly I was kinda hoping to be wrong!

I really enjoy engineering challenges and thinking outside the box with things that already exist, and applying them to new use cases.
You rock.

Thank you for the kind words! Thankfully, after that test, I had a couple of ideas in the shower, so there might be some juice left to squeeze out of this design yet. Also, I need to figure out what to do with the laser cut and bent sheet metal parts that arrived today   I'll keep sharing what I come up with; if it's worth pursuing I'll continue to work on it, and hopefully somebody can stop me before I get too far by pointing out the fatal flaws!

Alright, new idea. Gibbs makes a bidirectional ascender for arborists called the Gibbs Klimair, which you can read more about here: http://www.verticalmuseum.com/VerticalDevicesPage/Misc/Fliplines/Flipline3761.php

The device is very simple; the rope goes through the taco shell, in between the taco shell and the cam. When you pull one end of the rope, the rope tilts the taco shell and pinches the rope between the taco shell and the cam on the other side. To allow the device to be bidirectional, the cam is cut away in the middle of braking surface so that when the taco shell rotates from one side to the other (when pulling on the other side of the rope), there is a moment when the cam is no longer pinching the rope against the taco shell.

For arborists, that last fact is a minor nuisance; they can just reach down and flip the cam so it brakes on the appropriate side of the rope. For lead rope solo backup use, that's bad! We want something that doesn't need tending like that. I think there's a couple of ideas to fix this issue.

The first idea is to add a spring so the cam rotates back to one side all the time, making that the default braked side. If that default side is the dead rope side, when you pull on the cache loop, there'll be a bit of resistance (rope weight plus the spring tension), then the rope will pull through adding more cache. If you pull even harder, you could overcome the spring tension, and now brake the cache loop side. So there's some finesse required there. This isn't perfect for a backup, though, because in a fall there's a chance that the rope zipping through from the cache loop side will perfectly balance the spring tension and keep the taco shell and cam in the middle position where the cam doesn't pinch the rope against the taco shell. You could fall to the end of your rope.

Okay, so building off of that idea, what if you added a spring to the other side, and a two position clutch so that the cam and taco shell can never stay directly in the middle. This solves the problem of the device hanging out in the dreaded middle-no-pinching position letting you zip to the end of your rope. But now you have to design the clutch so that there's a fine balance between pulling hard enough to let rope slide out, but not so hard that you flip the clutch and have now locked the rope on the wrong side of the device. This is not ideal; if you pull cache side too hard and it locks on the cache side, you need enough weight on the dead rope to flip it back to locking on the dead rope side, or you have to pull on the dead rope side a bit to get the device to flip over.

Dang, alright, getting closer but not quite there. The big problem as I see it is the dreaded middle-no-pinching zone, made by the gap in the middle of the cam. I'm looking for something that keeps the cam always engaged with the rope, but doesn't pinch the rope against the taco shell in the middle of its travel enough to brake it.

One idea I have is to have the middle portion of the cam's travel be a spring loaded section, and be a little grabby (like the grooves on the Gibbs Klimair) or some ATC/clamcleat style grooves. That way, when the rope is being pulled through the device and the device is rotating from braking one side to the other, the rope always stays in contact with the cam, to keep it positively turning over from one side to the other. No more dreaded middle zone, but there is some friction pulling the rope through. But that seems like it could be tweaked with geometry changes. And still install a spring to keep the cam preferentially braked on the dead rope side all the time. Falling should be plenty of force to overcome that spring and get it to lock on the cache loop side.

I actually don't have any other good ideas for fixing the middle zone problem. Do y'all have any ideas?

I thought of cutting the middle of the taco shell away, and leaving the full profile of the cam, so that when the cam does rotate from one side to the other, the full "middle" of the cam just pushes the rope out of the cutout middle of the taco shell. But that seemed tricky to get right for a bunch of rope diameters, and also the risk of the rope making a bight through that slot was kinda spooky to me.

Here's a video that shows the Gibbs Klimair in use. You can see how the rope tilts the taco shell part of the device to lock the rope in either direction. You can also see how the arborist has to manually flip the cam around a couple of times, which is, again, not ideal for use as a LRS backup and cache management device.

https://youtu.be/NVRojSUFq4A?si=e_8o2qaaOXkrQ59G

Alright, I 3d printed a rough copy of the Gibbs Klimair. It's so simple! And it works great for what it is. It will not work for a backup and cache management device (it's really weird and hard to pull slack through for the cache), but now that I have something to play with, I'm going to keep making modifications. Each 3d print takes a couple hours, so I only get to do one print an evening after designing in Solidworks   I should have another prototype out by this weekend, hopefully this one works better than my last idea! The good news is this next idea does away with my "spring loaded section" I mentioned in the previous posts; it should be very simple.

Had an inspiration the other day on a long walk back from a climb. I feel a little silly still coming up with ideas, since the FreeBell device is in production now and should be in our hands in a few months. Also, Levi Tate, I haven't forgotten about you, and I'm still tinkering with ideas for you!

This idea is so silly, it's literally just hanging a Gibbs Klimair upside down with the addition of a carabiner hole to the housing. In the images below, the pink part is the housing, the blue part is the cam, and the grey bit is the rope. As I've drawn it, it's useless because it locks instantly in either direction. But by adding a couple of springs it should do what we want! Also, imagine an axle in the bottom hole, didn't model it in for reasons.

One spring needs to be added to keep the cam preferentially tilted to the dead rope side, to act as cache management. This spring is not shown in the model; it would likely be a toroidal spring hidden in the body of the cam.

This is what a lead rope soloist would feel as they begin to pull out slack:

1. They pull on the rope to gives themselves more cache loop, and there's some spring tension on the cam preferentially holding it on the dead rope side.
2. The climber overcomes that spring's tension, and the cam begins to move to the centered position.
3. Once the cam is at the centered position, the rope begins to move freely through the device, giving the climber more cache loop.
4. If the climber keeps pulling harder, the cam rotates even further around to the backup side, locking the rope again.
5. Once the climber has enough cache loop pulled through, they let go of the rope and the cam springs back to the dead rope side, where it cams and holds the weight of the dead rope.

In the event of a fall and the main self-belay device fails and this backup needs to be relied upon:

1. The ropes strands are initially facing the same direction, both pointing down, like shown in the above images.
2. The climber falls past their last piece of protection, and now the ropes are facing opposite directions: the dead side of the rope still pointing down, but the live side pointing up to the last piece of protection (shown in the image below).
3. The device is no longer hanging down freely, but it has also flipped upside down because of the rope going back up to the last piece of protection.

The risk here is that cam gets stuck in the centered position, where it can run freely, because there's enough rope drag to overcome the spring, but not enough rope drag from that point to continue the cam all the way around to the backup braking side. I can replicate this by playing with my 3d printed version and "simulating" this scenario by hand, but I haven't gotten a chance to try it out with actually falling equipment (I just 3d printed this today). 

I'm not sure how likely this actually is: because of the carabiner hole being offset from the axle hole and the rope path, I feel like even in a free fall situation, with the rope running straight down the housing of the device, the device probably wants to rotate anyway. And once there's any friction against the rope, it'll want to rotate even more, thus engaging the cam.

I think a simple fix to this is to make the rope path curved even in the worst case scenario of a free fall. So take that straight edge in the housing (pink) part, and curve it similar to the shape of the cam. You wouldn't notice any effects from the curve in the normal case of pulling slack for a cache loop, or the device holding the weight of the dead rope. But in a free fall situation, because of the now enforced curved rope path, the device gets rotated regardless just with friction against the housing, and would start working with the cam.

Also, I drew some little teeth on the cam, and they work fine. In the next iteration I'm going to add grooves to the edges of the housing where the rope exits, just like the grooves in an ATC, and I think that's going to add a lot more braking power.

Anyway, let me know if y'all have any thoughts! I'll try to draw up the changes and print out a new version during the week. I'd like to get to a point where I feel confident machining a version test by dropping from a tree to simulate the worst case scenario.

Printed out a version of the cam tonight without any grooves like in the previous images, and there's almost no braking power. So, it looks like the cam needs some grooves. I've tried a few times to draw some grooves on the cam (or other parts) in SolidWorks, but I'm struggling to get satisfactory results, mostly because I don't know what the "parameters", or design intent, of the grooves should be. I'd like to copy the groove design from the DMM Pivot, because I've found them to be satisfactory on a very wide range of rope diameters.

I'll try another print tomorrow with some simple stair step grooves, just to get a sense of how much "bite" is necessary.

This does lead me to believe that the braking action might be more akin to that of a Wild Country Ropeman ascender, where the teeth bite onto the sheath of the rope and that gives more friction than the camming action.This doesn't give me high hopes for high kilonewton falls where the rope might desheath rather than get pinched harder and harder by the cam.

On second thought, something I had thought about earlier was adding a deep groove to the far ends of the cam, much like the deep V groove of a DMM Pivot/BD ATC style tuber. That way, you have the rotating cam that starts pinching the rope. Then, you can have a feature/bump/fin in the housing that pushes the rope deeper into the V groove once the cam is rotated almost all the way it can go.

In fact, thinking about it further, if there's a spring that keeps the cam preferentially rotated towards the cache loop/dead rope side, then that side of the cam can have simple Wild Country Ropeman or Petzl Microtraxion style teeth, since they're only supposed to be holding the weight of the rope and not the force of a fall. Then, the other side can have the deep V groove like a tuber belay device to actually catch falls; this feels safe because it's already prove by the millions of falls caught by other grooved tuber devices :)

I'll see if I can draw up something over the next couple of days that makes that explanation a little clearer. Looks like I might have to machine a handful of "blanks" and get out the die grinder to try out different shapes of "teeth" and V grooves!

Have you seen the way I use the USHBA hand ascender as cache management and backup?

Mr Rogers wrote:

Have you seen the way I use the USHBA hand ascender as cache management and backup?

I had seen your post on it before, but didn't read into it too closely (that thread was going way into the weeds for me!). The supposed rarity of the device was a bit of a put-off, but it did lead me to look at devices like the CAMP Goblin fall arrestor and similar devices.

Am I barking up the wrong tree? Should I just buy the USHBA? I've got a keep going along working on this design, my curiosity won't let me stop. I think adding the two things I mentioned from my last post (teeth for cache management, deep V groove for backup fall protection) will get me 90% of the way there. Then I just need a small kink in the rope path to fix a rare possibility and I should be good then!

Duncan Domingue wrote:

Am I barking up the wrong tree? 

Not in my opinion.  Every other option has drawbacks or disadvantages, so any effort to come up with a better option is appreciated.

Duncan Domingue wrote:

I had seen your post on it before, but didn't read into it too closely (that thread was going way into the weeds for me!). The supposed rarity of the device was a bit of a put-off, but it did lead me to look at devices like the CAMP Goblin fall arrestor and similar devices.

Am I barking up the wrong tree? Should I just buy the USHBA? I've got a keep going along working on this design, my curiosity won't let me stop. I think adding the two things I mentioned from my last post (teeth for cache management, deep V groove for backup fall protection) will get me 90% of the way there. Then I just need a small kink in the rope path to fix a rare possibility and I should be good then!

More that its an inspiration and similar in function to the most recent device you have posted.
The rocker arm works wonderfully....with a few caveats to how it function because it was designed as a hand ascender. I use them as ascenders (theyre amazing for a few reasons), but I want to destroy one to make a more purpose device so I'm looking for another one or pair currently. I'm checking the Ural -alp website regularly.

Maybe when I get home after the holiday I'll share some of what ive been thinking around how to modify/repurpose it.