The trains on Firehawk and Batwing are different than Borg.
Borg uses a mechanical system in the station to raise and lower the trains, and locking pins that hold them in the "Fly" position. Firehawk and Batwing have the onboard system.
If I'm not mistaken both Batwing & X-Flight/Firehawk also have a locking mechanism similar to Borg's.Take a look at the chassis when the ride is in the "load" position & you'll see the holes on each side of the chassis that the pins lock into after the seats are lowered into position.
The GAU's only raise/lower the seats without the need for station mounted lifting jacks,which Borg requires.
I call BS.
Wow! Just WOW!. I won't claim to know much about the operation of coasters but that is just poor design.
I hope the ride does open Saturday as I am stopping at Carowinds that day on my way to Florida.
When major CF rides fail due to purely mechanical issues, they say so. When they find the issue, but aren't sure how that came about, they say so. When trouble lights indicate a fault prior to a failure--only they couldn't fathom what it was, they'll tell you that, too.
They're a publicly owned company that believes in full disclosure and has better things to do than create lil' so-called 'coverups' for armchair detectives to 'uncover.'
I'm not telling you that because I'm some CF fanboy (and frankly, most folks know better). I'm telling you that because it simply IS.
First of all we still have no idea what sort of a safety mechanism would just stop a train anywhere on the course. I highly doubt they have equipped the trains with braking mechanisms should the pins unlock. A much easier, cheaper, lighter way of doing things would have a backup mechanism to prevent the chassis from opening during the ride, should the pins fail.
As for the report that someone accidentally pushed a button, now in my mind theres no way that can happen. That would mean that somehow the button being pushed would have to communicate with the ride. Almost all rides only have communication like this in the station to prevent something like this happening. That is why when a ride is being manually released its a much longer process including many manual release tools and in some cases battery packs to bring power to the ride. Now I know that it is possible that these rides may be different than all others, I'm not saying I know everything about them, but having communication like that throughout the ride course would cause a lot of errors especially being a Vekoma. Not to mention there is no real need to be able to communicate with the ride outside of the station, not a good enough reason at least to require adding a lot more to the trains and an expensive most likely wireless (and flawed) communication system.
So say all that we are hearing is true, fine. Like pagoda gift shop said though if it is in fact true, this is easily a user error thing that we should have seen in the past. The only other explainable way is if there is a manual unlike on the actual train, and one of the employees pushed it during the ride. If thats the case, it wasn't an accident, but that would have been something done intentionally which I doubt a rider would want to do to them self. If it was accidentally hit on the train, then again why havn't we seen this happen before?
The whole story is very fishy and I would like to find out some information that will make sense.
While in the station, there is a mechanism to open the lap bars. Even after they are locked, if someone starts having an anxiety attack, thunder, puke, etc. they need to be able to get the people out. Given the way the seats recline and THEN leave, I'm sure there's a locking/unlocking mechanism as well. (I know there is on the B&M's - you can hear it engage, and given the right angle you can actually see the pins lock. I can only assume that the Vekomas would be at least somewhat similar)
Therefore it's conceivable that this unlock button (or even convoluted sequence of several buttons) was pressed either before the train dispatched, or even while the train was dispatching (i.e. "in motion"). When the train is going up the hill, gravity is pulling it down, so the seats won't pop up (they're powered, not spring-loaded). However, centrifugal force while going around an element such as a loop can easily cause the unlocked cars to stand up.
I know of an S&S shot tower at an "undisclosed location" in the US that was almost launched with a restraint open due to a design flaw in the computer system. And I mean wide open as far as it can be open. Fortunately, an alert ride operator caught it and stopped the ride cycle while it was in the weighing stage before it actually launched so no one read about it in the papers. Basically, buttons were pressed in an *exact* order with *precise* timing that caused the ride to think an open seat was closed. Granted, it was big time human error in those buttons being pressed in that order (not your normal sequence of buttons being pressed), but it's also in the way the sensors for closed lap bars were designed coupled with the way the computer sytem reads it that caused it to occur. For confidentiality, I will not say what park. Rest assured that the timeouts were extended that fixed the glitch from even being possible in the future after that. BTW, this happened in 2004. When was the first S&S shot tower built? Long before that... quite a number of years before this -human error- occurred. (At least I'm not aware of any other instances of this occurring)
The article simplifies it as saying "a button was pressed". But I doubt there's a giant "unlock harnesses during the course" button that magically unlocks it which someone accidently hit with their elbow. It's probably more like "if the lock car button is quickly toggled at the exact instance when it's reclined, and then the dispatch button is pressed and held for 5 seconds, and as the train is just about out of the station but still on the last prox sensor to register as being in the station and the toggle switch is hit again, the train will respond by unlocking the cars while leaving the actual harnesses locked as the train goes up the lift, but this leaves them in an unstable state once the train disengages from the lift" -- not your garden variety "oops" by any stretch of the imagination. DISCLAIMER: I totally made that up. I have no insider information regarding this particular incident. Any resemblance to truth is purely coincidental.
It takes me back to my software engineering class in college (and the forum beta thread) -- when you test, there's a limit to how exhaustive your tests can be to be economical, yet catch as many bugs as possible. In the case of the forum, the site may freak out of you constantly click on a link to open/close a profile, but if you have to stand on your head while juggling an apple, a toaster, and a moonpie with your left foot and clicking the mouse with your right foot at a rate of precisely 45 clicks per minute.... even if it's reproducable, is it really WORTH spending the effort to fix?
In the case of a coaster, yes. In the case of a coaster forum, I gotta side with Jeff and say "umm, no" :)
Edit: punctuation/spelling typo
*** Edited 3/22/2007 10:39:45 AM UTC by dannerman***
At the very bottom of an S&S drop tower is a plate that has connectors for the restraint system. It has 1 connector for each restraint. You close 1 restraint, and the sensor will make electrical contact with the plate, and the PLC will change from 'open' to 'closed'. In normal operation, it will not start unless all are closed (showing contact). The funky part is that once the ride starts (it rises up a couple feet to weigh itself) the carriage comes off this sensor plate, and the PLC will show every restraint as 'open', even though it is, in fact, locked. The PLC is programmed to ignore this, since it is normal (just a limitation of the sensor design).
The glitch was that if the lap bar open switch/button was pressed/toggled at the exact right (or wrong!) time, it would allow the restraint to open at the precise time it's beginning the ride cycle by raising the carriage to weigh. Too early and the ride will not start; Too late and the carriage won't receive the unlock signal, and thus the restraints will remain securely locked. If a seatbelt isn't fastened properly, and a person were to push up on the restraint at that precise moment, it would open (because they're not locked) but because it's the part of the ride where it thinks it's supposed to be showing as open (because the contact with the sensor plate is missing). Granted, there's a *LOT* of 'if's in the scenario that shouldn't all happen in the precise order at the precise times -- and were going just fine for years -- but human error allowed it to happen.
If you're programming a PLC, how do you test for that sort of thing? As a software programmer, you generally don't get to pick and choose your sensors -- they're designed by someone else. You take that input, and have to design the ride program accordingly. With a sensor that has a design that only shows it as closed/locked before the ride starts but shows it as open (even though it is actually fully, safely locked) during the ride cycle, there's little else you can do.
I agree it's a poor design -- but it's on the part of the sensor designers -- not the PLC programmers (unless they were the same people ;) )
Designing safety controls is very demanding a task and unfortunately many rides are not totally conform. The software and hardware development must both be part of a fully integrated safety approach, they can't be separated. It's extremely important to clearly define what the software has to do and to perform a very thourough risk assessment. Most PLC programmers don't have a strict enough approach to program safety PLCs. When you program a safety PLC you must have a extremely good knowledge of both the electrical equipment of the whole ride (including power supply systems and ancilary support systems), the way it is operated (imagine and anticipate every possible operator error), the other risks and of course the SPLC (safety PLC) itself. Safe programming requires a very high degree of formalism and many constructs which are commly used in PLC applications cannot or at least should not be used.
For example, in some case you use pulse outputs to detect accidental short-circuits but you must also know exactly how to implement the design. Even small details like on which side of a terminal you connect a wire to use in a switch can have an influence on the safety.
Bad are roller coaster automation systems which lose block information and, or, can't update it in real time when the grid power fails. The control system should ALWAYS know in which block a train is even in case of power failure.
Unfortunately it is by far not always the case.
(Edited for typos.)
*** Edited 3/22/2007 4:25:55 PM UTC by Vallean***
That just isn't feasible in software design. No matter how important the system is, there's also a point at which the cost greatly outweighs the benefit.
There were about 8 or 9 conditions that all had to happen precisely in the case of the S&S tower incident. The probability of it happening is apparently 1 in however many shot tower launches there have been worldwide.
When you cross the street, it's customary to look left and right to detect if it's safe. Do you look up? No? Why not? - it's possible a cargo bar door may have fallen off an airplane. The probability of it happening when you cross the street is very low, but it's happened! The reason is because the probability is so low, it's not necessary.
Same thing goes with a ride safety system. Is it necessary to test a sequence of 10 buttons being pressed, along with every possible combination of delays between those buttons? The testing would never end because there's an infinite possibility of combinations.
That may be a little scary to digest in certain applications, but it's the simple truth.
BTW you can still read this scary report about the infamous Therac 25 medical device where several persons were killed due to software errors:
You wouldn't happen to be a former (or current) MIT course 6er, would you?
But I have a question. Has BORG Assimilator gotten any better when it comes to downtimes and it running more frequently. I always remember when I went to Great America, Stealth was usually always closed at some point during the day.
@ApolloAndy: Not MIT, real world industry engineer.
I just ask because at MIT in one of the entry level comp. sci. classes we did an extensive study of the Therac.
You must be logged in to post