Expedition GeForce Cable Snaps

Wednesday, October 7, 2009 12:22 AM

Around 3:30pm on October 4th, there are reports of EGF's cable snapping with the train near the top of the hill. The catch car, from what the reports say, rolled back into the station along with there being damage to the track. Pictures can be found on most other forums. Does anyone know what part of the cable snapped? Could it be possible that the link that attaches the cable to the catch car is breaking as opposed to the cables themselves being the source of the issues?

+0
Wednesday, October 7, 2009 12:44 AM

Can we please stop with this "other forum" stuff and actually link to websites that have pictures of these things? Some of us aren't on 35 other coaster forums every day.

+0
Wednesday, October 7, 2009 11:46 AM

Holiday Parks website is showing the coaster closed.

http://holidaypark.de/en/park-attractions/rides/expedition-geforce/

It also appears that the park is giving pass holders a discount for day passes for the following season to make up for their star attraction being down indefinitely.

Makes me very concerned about Intamin rides. There are too many incidents all with the same issue, cables breaking. At this point I would say that a mandatory shutdown and inspection of all the rides would be not only wise, but should be required.

+0
Wednesday, October 7, 2009 11:50 AM

Cables fail, and that doesn't concern me. What concerns me is what happens to the cable when it breaks. We've seen Millennium Force get banged up pretty bad when its cable broke (to make more of an apples comparison). It seems when the catch cars on the big rides like these slide back down the lift, they don't gracefully land somewhere. Instead they get jammed up with the cable flailing around and, in the case of MF, mangle the channel with the anti-roll notches.

You can see in the case of MF what they would like to happen. The bottom of the catch car channel has S-shaped rails that should (in theory) divert it to ground level where it can land in the gravel under the station. But so far, it jammed at the base of the lift in the first case, and then at the start of this year, it actually went out over the top of the lift and ended up dangling there.

+0
Wednesday, October 7, 2009 12:09 PM

I couldn't find any definitive pictures anywhere. At least they could walk down the lift in this case instead of needing to use an elevator lift.

+0
Wednesday, October 7, 2009 12:25 PM

Why can't they give the catch car conditional anti-rollbacks just like the trains?

+0
Wednesday, October 7, 2009 12:59 PM

Probably because the catch car is supposed to go in reverse, every 90 seconds or so. The train never does.

+0
Wednesday, October 7, 2009 1:08 PM

They could put in some type of stop that would drop in place after the catch car passes certain points in the lift. They would then relese when the catch car starts to come back down.

Just an idea....

+0
Wednesday, October 7, 2009 1:35 PM

They could also use limited mag braking so it would never go above the speed of the lift.

Edit: Me no typey so goodly.

Last edited by ApolloAndy, Wednesday, October 7, 2009 1:35 PM
+0
Wednesday, October 7, 2009 1:46 PM

Since we are throwing out idea here, why not an over-speed brake like what is found on elevators?

Last edited by Fun, Wednesday, October 7, 2009 1:46 PM
+0
Wednesday, October 7, 2009 1:54 PM

Elevators go up and down as well. But, if a cable snaps and it goes into free fall it has devices installed that prevent it from falling any further than it takes for the devices to react. I would think the catch car is moving much faster when it's falling after a cable snap versus when it's being lowered to the station to get the next train. These might be harder to implement in this situation because the catch car wouldn't ever really be in free fall. I'm not sure if the devices have a sensitivity level that can be adjusted.

<edit>

Fun, you beat me to it. I need to learn how to type faster. :-)

Last edited by Jason Hammond, Wednesday, October 7, 2009 1:56 PM
+0
Wednesday, October 7, 2009 3:33 PM

^ Those devices are really simple and could definitely be used for the catch car.

"

+0
Wednesday, October 7, 2009 4:07 PM

I wouldn't say they're that simple. If I recall correctly, they are clamps that hold the rails, and release only when there's tension on the pulley lifting the elevator. So you'd need something for the catch car to clamp down on, but the varying tension on the cables would be a pain to deal with. If you don't believe it, watch the counterweight pulleys under the base of the lift bob up and down when it reverses direction.

+0
Wednesday, October 7, 2009 5:55 PM

I was thinking along the lines of a centrifugal brake that trips if the speed is too high.

+0
Wednesday, October 7, 2009 6:03 PM

The basic Otis mechanism is essentially a diamond-shaped frame where the top point is attached to the hoisting rope, the bottom point is attached to the elevator car, and the outer points hold brake shoes or (in the original embodiment) levers to engage with teeth on the sides of the shaft. Gravity is used to hold the frame in its squashed configuration such that the brake shoes or levers will engage, or that could also be handled with a heavy spring. When there is tension on the hoisting rope, the frame stretches out, thus disengaging the brakes. This means that the hoisting rope has to be under tension at all times for the car to move, regardless of whether the car is going up or down.

Some form of this has been standard on cable hoist elevators since the 1850's.

The problem with this is that the catch car on the Intamin coaster has to proceed past the lift peak. As Jeff suggests, that probably complicates the problem of maintaining tension on the hoist rope. I suppose the mechanism could be positioned in the middle of the catch car, but that gets even more complicated. It's a lot easier to just assume that the ropes are going to fail, and design the system to minimize the risk of (1) injury to riders, (2) injury to staff, and (3) other equipment damage. It seems that Intamin's systems tend to sacrifice (3) in favor of (1) and (2), although occasionally it doesn't work that way (see Xcelerator).

--Dave Althoff, Jr.

+0

You must be logged in to post

POP Forums - ©2018, POP World Media, LLC
Loading...