PDA

View Full Version : California Screamin Update



phoenixfire2k5
08-14-2005, 11:47 AM
Now, just so there is no confusion, this isn't an official update, but it's one based on my experience yesterday and from a source I obtained last night.

Yesterday morning, about an hour after opening, they were running the red train through test cycles on the ride. I was wandering through the nearby shops with my gf yesterday by Ariel's Grotto and went to the railing to check out what was going on. Red was fully loaded with 24 (12 rows, 2 seats to each row, 24 seats total) completely filled large water tanks taking up each seat. So large, that the shoulder restraints weren't down all the way. They appeared to be in the seat and resting in the floor where your feet normally go. I assume that this was to simulate 24 large adults on the ride and that they were testing the weight on this train. Red would run through the ride, and when it went through brake zone 7, (the one that failed, and which is above and to the left of King Triton's Carousel), it would come to a hard AND LOUD stop, then resume through the remaining part of the ride slowly. I watched them do this a few times, then my gf and I walked down towards the front of the ride. A CM was speiling to guests about the ride not being opened, and why it's closed. Once there, I first asked in a joking manner "So, how many times have you been asked if this ride is going to open today?" He said countless lol. But I asked if DOSH still had the ride or have they given it back to Disney yet. He said he didn't know, that he didn't know anything, but that he did need a pass to even go back there. So I assumed that this meant that DOSH still has the ride and are still investigating.

Later on, riding the Metro Bus home, I was talking to one of the DL security guards. I asked him the same question about DL, and he briefly stated, and answered, that DOSH still has the ride. If I were to go by that, then I guess it's safe to say, that they still have it. But I guess only time will tell.

Doug
08-14-2005, 11:53 AM
Oh please tell me you took pictures of the train with the water bottles in them! Did you? Did anyone?

phoenixfire2k5
08-14-2005, 11:56 AM
Sorry, didn't have a camera on me. If I would've thought of it at the time, I would've snapped one with my gf's camera phone. But she was in the shop at the time. Hopefully someone else got one. :(

Doug
08-14-2005, 12:18 PM
No camera? It's an unusual day when I am at DLR and I do not have 2 camera's (not counting phone) .... and I usually have 1 when I go about my normal day (little pocket cam for every day use, and DSLR for the rest of the times) ... so, SOMEONE must have taken a pic...

SilverStyle
08-15-2005, 08:59 AM
Yep, what u saw was the water testing dummies. I am assuming they are trying to replicate the situation that happen. These dummies are filled with various amounts of water. I am assuming CA screamin wont be open for a long time till they update all sensors and ride access control sytems. I am sure DOSH is still investigating the problem.

phoenixfire2k5
08-15-2005, 03:45 PM
Later on, riding the Metro Bus home, I was talking to one of the DL security guards. I asked him the same question about DL, and he briefly stated, and answered, that DOSH still has the ride. If I were to go by that, then I guess it's safe to say, that they still have it. But I guess only time will tell.


It took me a while to realize this, but the part in bold, should actually read: I asked him the same question about California Screamin.

Opus1guy
08-15-2005, 04:42 PM
I think they should go ahead and re-open California Screamin as-is.

I mean, people have been complaining the thrill rides at Disney were not scary enough. Well...now they're plenty scary!

;)

phoenixfire2k5
08-15-2005, 04:43 PM
I think they should go ahead and re-open California Screamin as-is.

I mean, people have been complaining the thrill rides at Disney were not scary enough. Well...now they're plenty scary!

;)


lmao!

Doug
08-15-2005, 09:43 PM
Bah... got pictures?!


Yep, what u saw was the water testing dummies. I am assuming they are trying to replicate the situation that happen. These dummies are filled with various amounts of water. I am assuming CA screamin wont be open for a long time till they update all sensors and ride access control sytems. I am sure DOSH is still investigating the problem.

Bruce Bergman
08-20-2005, 09:18 PM
I think they should go ahead and re-open California Screamin as-is.

I mean, people have been complaining the thrill rides at Disney were not scary enough. Well...now they're plenty scary!

;)

:( Funny. Ha. Ha. It is to laugh... :rolleyes:

So they've got a train loaded trying to duplicate the problem - and I bet I know what it is already. (Disclaimer: I don't work for Disney or any other theme park, I am not an engineer - I'm just a troubleshooting electrician who solves problems in complex systems for a living, and IMHO I'm pretty darned good at it.)

Warning: Geek Speak ahead. Abandon all hope...

They trip an E-stop /while/ the train is entering Brake Zone 7, and either the PLC computer control system does not know that the train is already entering the zone and NOT to try to stop it there, but let it through to a (hopefully empty) BZ 8.

Or the brakes don't close till the train is partially through, and the computer does not have a sensor properly positioned to know that BZ 7 is 'fouled' with a train half in, half out. If the only sensor is at the entrance of the BZ, the computer obviously can't see a train that's stopped in there - but caught only by the brake fin of the very last car.

Half the battle is that (as far as I can tell) the trains are sensed by optical gap sensors looking at an interrupted LIM drive motor reaction fin on the bottom of each car in the train. If there's only one sensor the train could be stopped over a gap (at the car couplers) and the sensor can't "see" it. Once a train is moving, a lone sensor sees a pulsed blink as each train car goes by. You have to put three or four sensors in a row a few feet apart to really "see" the train at all times.

And another big problem is reaction time - it takes a quarter to half second for the PLC computer to get the position sensor inputs and decide what to do, and a good one to two seconds for the brakes to react and close fully. Meanwhile, Back At The Ranch ;) the train is still moving at up to 35 MPH, and that sensor information is now old news...

Either way, they may have to spread out the train spacing (add a bit more buffer space) and/or add additional Emergency Only brake zones in between the existing ones so the odds of another foul-up like this are greatly reduced.

That way the computer sees a train caught and partially fouling BZ 7 and another moving train to the rear approaching - So they release the front half of the brakes in BZ 7 and allow the forward train to advance to a theoretical BZ 7-1/2 and clear BZ 7 for the next train, and still leave the back half of the brakes closed to catch the incoming train behind it. The second that the sensors say the forward train has cleared the front half of BZ 7, slam the rest of those brakes closed again.

If the wanted even finer control, they could even divide the brake zone controls up into thirds, and add more sensors. Two-thirds of the brakes engaged should be able to stop all but the most grossly overloaded trains approaching from the rear.

So what if there is no catwalk to off-load a train from the newly installed BZ 7-1/2, and they have to wait till they can clear BZ 8 and advance that train. I'd much rather be stopped in a non-evacuatable spot for a few minutes than get a "coaster train enema" at full speed. :eek:

(And you know how painful that can be... :p )

Before you say that the ride control PLC computer can't have that fine of control of the trains to account for this complexity, let me remind you that the Space Shuttle (even after upgrades) is flying on late 1980's computer tech, using specially hardened and "Space Rated" 1980's processor chips. 80486's, or first-generation Pentiums. It's all in the granularity of the train position and speed sensors and the control systems for the brakes and pusher motors, and the skill of the computer programmer. You can do a lot with simple commands and properly programmed What-if scenarios...

--<< Bruce >>--

Doug
08-21-2005, 01:19 AM
I would assume that very little computer power is needed for ride control systems for a couple of simple reasons (all assumtions on my part :)), 1) if you program the ride control apps in assemly, it's fast, unlike basic, 2) each sensor can be 1 bit of info.... a few rundred bits is nothing to deal with, even with mid 80's hardware .... Thoughts?

Osky
08-21-2005, 09:21 AM
Bruce, a few problems with your assumptions.

First, I find it hard to believe that any ride system would take close to three seconds to apply the breaks fully as you suggest.


And another big problem is reaction time - it takes a quarter to half second for the PLC computer to get the position sensor inputs and decide what to do, and a good one to two seconds for the brakes to react and close fully. Meanwhile, Back At The Ranch the train is still moving at up to 35 MPH, and that sensor information is now old news...

Let's assume a half second for the computer to get the message and two seconds for the brakes to react. So, two and a half seconds total from the time the train enters the brake zone, to the time the brakes are fully applied. At your above stated 35 MPH, the train would have traveled 128 feet by the time the brakes are applied. Now, considering that the train is moving faster than that in some of the brake zones, I don't buy it. Modern actuators can operate in a fraction of a second. So fast, that to the human eye there is only two states. Open and closed. Now, I doubt they would go to that extreme on the brakes, but I think a reasonable estimate would be in the milliseconds for the computer to receive the information from the sensors and process it, and less than half a second for the brakes to be applied.

Now, to dispel bad myths. The shuttle does not run on 80386, i486 or Pentium processors. There are five main control computers in the shuttle. Four running the standard software, and one running a special backup program. These five computers are IBM AP-101 avionics computers. More information can be found here: http://en.wikipedia.org/wiki/AP-101


Before you say that the ride control PLC computer can't have that fine of control of the trains to account for this complexity, let me remind you that the Space Shuttle (even after upgrades) is flying on late 1980's computer tech, using specially hardened and "Space Rated" 1980's processor chips. 80486's, or first-generation Pentiums. It's all in the granularity of the train position and speed sensors and the control systems for the brakes and pusher motors, and the skill of the computer programmer. You can do a lot with simple commands and properly programmed What-if scenarios...

Um. the i486 25 debuted in April of 1989. Well after all of the shuttles were built. (Construction on the later added Endeavor started in 1987) The Pentium debuted in 1992.

coronado_g
08-21-2005, 11:58 AM
Thanks for the geek-speak alert! :p
In everyday language, does this mean that the brakes aren't working?

Bruce Bergman
08-21-2005, 12:48 PM
Bruce, a few problems with your assumptions.

First, I find it hard to believe that any ride system would take close to three seconds to apply the breaks fully as you suggest.

Let's assume a half second for the computer to get the message and two seconds for the brakes to react. So, two and a half seconds total from the time the train enters the brake zone, to the time the brakes are fully applied. At your above stated 35 MPH, the train would have traveled 128 feet by the time the brakes are applied. Now, considering that the train is moving faster than that in some of the brake zones, I don't buy it. Modern actuators can operate in a fraction of a second. So fast, that to the human eye there is only two states. Open and closed. Now, I doubt they would go to that extreme on the brakes, but I think a reasonable estimate would be in the milliseconds for the computer to receive the information from the sensors and process it, and less than half a second for the brakes to be applied.

Ahh, but the brakes on most coasters are air actuated - actually, in this case they are air released and air/spring actuated, so any loss of pressure or electrical failure of the braking circuit is supposed to make the brakes fail in the Closed condition. You can have a mechanical linkage jam or break, or the brake shoes fall off (or wear out of specs) but nothing is perfekt. :p

The computer is several hundred feet of cabling away from the train sensors and brakes (especially the ones at the far end of the ride) and that introduces a negligible few milliseconds of delay, but the processor will take from 25 to a few hundred clock cycles to digest the input and decide to actuate the brakes. If the CPU clock is very slow, or the program is busy with another desision loop right now, that extra delay can be a problem.

Then it actuates the brakes - the solenoid valve is opened, and the brake actuator (diaphraghm spring brake, looks to me just like the brake actuator on a Class 8 truck) has to vent the release air charge holding it open to atmosphere through the hoses and solenoid valve (letting the safety spring set the brakes part-way) and get air into the application half to positively set them. That is what takes a bit of time - I'd say around a second overall, but the train is still moving.


Now, to dispel bad myths. The shuttle does not run on 80386, i486 or Pentium processors. There are five main control computers in the shuttle. Four running the standard software, and one running a special backup program. These five computers are IBM AP-101 avionics computers. More information can be found here: http://en.wikipedia.org/wiki/AP-101

Um. the i486 25 debuted in April of 1989. Well after all of the shuttles were built. (Construction on the later added Endeavor started in 1987) The Pentium debuted in 1992.

Right. But the AP-101 traces its roots back to the old System/360 Mainframe (Core Memory and all) and I was programming card decks for that (LAUSD MISS) in High School way back in the dark ages... :p A System/360 processor is rugged and reliable, and is designed to deal with a ton of I/O points at a time in a distributed system (hundreds of dumb terminals, card readers and punches, chain printers) but it doesn't have nearly the data processing horsepower that a modern Pentium 4 or above commands. If you go backwards, the computer on the Apollo shots were barely above the level of a pocket calculator - but they worked for the job they were given.

The PLC computers on the rides are in the same boat - they can buy tried and tested 386 or 486 class chips for under $20 each, toss them in a box with the support chipset and memory, and there you go. Add in a series of I/O Racks and cards.

Though it doesn't really matter that you are using an "ancient" processor if you aren't dealing with a high-level language, GUI front end or tons of data crunching - it just has to watch several hundred sense points and control switch inputs, react correctly to the inputs given, and give outputs to a few hundred actuators and indicator lights...

--<< Bruce >>--

Osky
08-21-2005, 01:09 PM
Regarding the first portion of your reply, you seem to know more about the actual physical braking mechanism than I do. However, if there is any sort of delay as you say, then the ride must surely incorporate sensors prior to the brake zone such that the ride can apply the brakes the moment the train first enters the zone, or prior to the train entering the zone.

I highly doubt that the system is designed as such that the controller could be busy in another loop and not have the ability to process the information from the brake sensors right away. Every possible situation should have been modeled and problems corrected with the controllers prior to the ride getting the go ahead to carry passengers. If you look at controllers on aircraft going back to the early days of flight computers, it is mandatory that every function be performed when necessary. You cannot have a case where the controller is busy with something else to handle a safety system. If you do have that situation, it is either bad software or bad design.

RE: the AP-101. I know very well the history of the AP-101 and I agree with what you are saying. I was trying to combat this statement which is false:


Before you say that the ride control PLC computer can't have that fine of control of the trains to account for this complexity, let me remind you that the Space Shuttle (even after upgrades) is flying on late 1980's computer tech, using specially hardened and "Space Rated" 1980's processor chips. 80486's, or first-generation Pentiums.

While it is true that the AP-101 comes from the System/360 Mainframe, the version used on the shuttle comes directly from the modified version in use on the B-52s. Yet another instance of NASA's Buff "008" adding to the space program.

Bruce Bergman
08-21-2005, 01:37 PM
Thanks for the geek-speak alert! :p
In everyday language, does this mean that the brakes aren't working?

( :geek: Thanks - I try to be considerate and avoid the $20 words, but some days it's hard work... :fez: )

No, the brakes on California Screamin' work as designed - but they obviously didn't allow for the actuating delay, or there's a serious flaw in the computer program for how to handle it when a fast train catches up to a slower one. And it appears as if they're applying the brakes at the wrong time.

Car analogy: Say you are approching an intersection in your passenger car at the posted speed limit, and the signal light turns yellow - you step on the brake pedal and the hydraulic brakes react almost instantly, and you can stop before the limit line. No sweat.

But driving a big Kenworth with air brakes, as you press the brake pedal there is a short delay as the air pressure builds up in the brake lines. Even if you have enough braking power to get stopped before the limit line, add in that extra time delay in setting the brakes and the truck is sticking out 10' past the limit line into the intersection.

And if you know there's a second truck following closely behind you as the light turns yellow, sometimes it's a better split-second decision (Is the intersection clear?) to run legally through the yellow light, and leave the truck behind you the whole distance he'll need to get stopped before the light turns red. Just because you can get stopped in time does not mean he can, especially with your 60 feet of truck in the way...

End of analogy - If you are going to catch a California Screamin' train in a brake zone for an E-stop, you pretty much have to have the brakes set fully by the time the first car of the train enters the brake zone. If the brake isn't actuated in time, you can end up stopping but "past the limit line" at the front of the zone.

And if there are two trains in the same zone, the computer has to be able to "wait through the yellow light" and let the first train get fully clear of that brake zone before slamming the brakes on to catch the second train. Or there is going to be a wreck like we just witnessed, with two trains stopping in the same brake zone colliding.

--<< Bruce >>--

Doug
08-21-2005, 01:59 PM
Nice car analogy, I assume that is why truckers (heck even cars sometimes), honk there horns as they go through, even though it's a yellow light... it's a "I am better off going through, than jamming on my breaks, so look out!" kind of thing...



And if you know there's a second truck following closely behind you as the light turns yellow, sometimes it's a better split-second decision (Is the intersection clear?) to run legally through the yellow light, and leave the truck behind you the whole distance he'll need to get stopped before the light turns red. Just because you can get stopped in time does not mean he can, especially with your 60 feet of truck in the way...

--<< Bruce >>--

Bruce Bergman
08-21-2005, 02:21 PM
Regarding the first portion of your reply, you seem to know more about the actual physical braking mechanism than I do. However, if there is any sort of delay as you say, then the ride must surely incorporate sensors prior to the brake zone such that the ride can apply the brakes the moment the train first enters the zone, or prior to the train entering the zone.

I highly doubt that the system is designed as such that the controller could be busy in another loop and not have the ability to process the information from the brake sensors right away. Every possible situation should have been modeled and problems corrected with the controllers prior to the ride getting the go ahead to carry passengers. If you look at controllers on aircraft going back to the early days of flight computers, it is mandatory that every function be performed when necessary. You cannot have a case where the controller is busy with something else to handle a safety system. If you do have that situation, it is either bad software or bad design.


I'm a repair electrician. I deal with Dumbth almost on a daily basis, because I have to tear it apart, figure out what went wrong, and make it work again.

Rule Number One: Never say "Now I've seen it all." Because as surely as the sun comes up in the morning, you will see worse. Murphy will see to it.

Bad design, bad programming, bad construction, and bad maintenance crop up all the time. There are lots of dumb people out there working well past their competence level, and lots of smart people who are neither wise nor thorough.

People building and programming complex machines (like roller coasters) will dismiss improbable 'What If...' failure scenarios out of hand with a brusque "That can never happen!" Well I have a news flash for you - I've seen where the strangest things can and do happen, and you have to brainstorm and plan for them. It's just like trapping "divide by zero" errors.

--<< Bruce >>--

ToursbabeC3po
08-21-2005, 02:30 PM
DOSH still has the ride and they are still investigating. I have talked to a former co-workers of mine and cast members have no ideal what is going on because of DOSH's investigation. They do this on purpose so there are no leaks on the Internet or the media.
They do know this much that the computer system has had problems in the past and this is something that should have been looked into or corrected a long time ago. I was told that there were software problems since it opened but have not been told that is the reason for this accident. I guess we will all know when the public DOSH records come out. I know Disney has to be pushing for the attraction to reopen as soon as possible because it is such a popular attraction but it is not in there hands.
Toursbabe

Hakuna Makarla
08-21-2005, 02:32 PM
Do we kow if any one has filed suit against Disney for this accident yet or is going to ?

Osky
08-21-2005, 02:33 PM
Well, let me recall my last post. :) Stupidity is all around. From the aerospace industry, you see a lot less of that kind of stuff because so many conditions are tested, including conditions that are considered to be impossible to recreate in real life. In many cases, one mistake means a crash and loss of life.

Most disasters are caused by a sequence of unusual events. Stop one event in the sequence, and you stop the disaster.

phoenixfire2k5
08-21-2005, 02:39 PM
DOSH still has the ride and they are still investigating. I have talked to a former co-workers of mine and cast members have no ideal what is going on because of DOSH's investigation. They do this on purpose so there are no leaks on the Internet or the media.
They do know this much that the computer system has had problems in the past and this is something that should have been looked into or corrected a long time ago. I was told that there were software problems since it opened but have not been told that is the reason for this accident. I guess we will all know when the public DOSH records come out. I know Disney has to be pushing for the attraction to reopen as soon as possible because it is such a popular attraction but it is not in there hands.
Toursbabe


I guess thats what they get for depending on a computer or using one for their attraction system. Computers are not perfect and are prone to mistakes or breakdowns. I have problems with mine all the time. And once in a while, I threaten to get rid of the dang thing and every other piece of technology around here, move to Pennyslvania and go Amish!!!

And Karla, if there is anyone wanting to sue the park, they're probably waiting for the DOSH report to go public first, or there is something already in the works and is just going through red tape. If there is anyone currently trying to file a suit against them, it probably isn't public yet.

ToursbabeC3po
08-21-2005, 02:56 PM
Every attraction I ever worked at Disneyland (not including autopia and Jungle) was ran by a computer system. I don't think the computer system is really the problem it is the people that ignore that there is a computer glitch or software problem that are the problem. Yes there is always a possibility that something can go wrong with a computer system but most attractions will ride stop if there is any error in the system. In this case it was the most likely the ride stop part of the computer system that had the error so there was nothing that could be done. (besides fixing the problem before it happened if the problem was known)

I can almost guarantee that there will be lawsuits. I have never heard of a accident at Disney without one. People are going to complain of back and neck injuries. If I had to put a bet down if there were going to be lawsuits or not I would go with there will be several.
Toursbabe

Bruce Bergman
08-21-2005, 06:14 PM
Every attraction I ever worked at Disneyland (not including autopia and Jungle) was ran by a computer system. I don't think the computer system is really the problem it is the people that ignore that there is a computer glitch or software problem that are the problem. Yes there is always a possibility that something can go wrong with a computer system but most attractions will ride stop if there is any error in the system. In this case it was the most likely the ride stop part of the computer system that had the error so there was nothing that could be done. (besides fixing the problem before it happened if the problem was known)

Exactimundo! They had a programming error that was a known problem - I heard stories of a Ride Op seeing this was going to happen during the Test And Adjust runs of the ride, and 'saved' the situation by manually inhibiting the ride stop (holding the brakes off by hand) till the forward train could clear that brake.

I'll have to go there and visually study it, but I'll bet there aren't enough train position sensors in each block zone to pinpoint where each train is, or the software wasn't tracking the timing between the sensors that are there.

Either way, that is a HUGE programming error if the computer can't figure out there's a block violation before there are two trains inside the same block and they both trip position sensors at the same moment. The Computer should have done something about the approaching train 15 to 30 seconds ago before it became a crisis.

Once the computer knows there is a bad enough block violation that there are two trains inside the same block, you can't just throw on all the brakes and hope for the best. It becomes REALLY important to know exactly where all the trains are (within several feet) so they can selectively throw the brakes on in the right sequence to prevent a collision.

They might also have to install 'trim brakes' that are under computer control, to slow down the faster train to the rear.


I can almost guarantee that there will be lawsuits. I have never heard of a accident at Disney without one. People are going to complain of back and neck injuries. If I had to put a bet down if there were going to be lawsuits or not I would go with there will be several.
Toursbabe

Well, from the reports there were no serious injuries, just the kind of thing that happens when you get rear-ended at around 5 MPH - but the fact that it was a minor collision never stops some people from trying to cash in...

("My Lawyer Larry H. Parker (http://www.fightforyou.com/) got me $4.1 Million Dollars...") :mad:

Disney is self-insured. Meaning most of those people injured in the accident will be offered a modest settlement with a rock-solid confidentiality clause attached, and will quietly go away. (Modest by Disney's standards, not necessarily theirs.) And the ones that decide to push it further will be fought in court tooth and nail.

I'm not going looking (under a rock... :rolleyes: ) for them now, but I understand there are accident lawyers out there whose advertised specialty is in suing Disney.

--<< Bruce >>--

Doug
08-21-2005, 08:03 PM
Well, without computers, there would be very few rides, because you just can not do some things with out them.... and even with computers, and thier errors, they do have predictable failures, regardless if it is a ride control computer, a home computer, or whatever....


I guess thats what they get for depending on a computer or using one for their attraction system. Computers are not perfect and are prone to mistakes or breakdowns. I have problems with mine all the time. And once in a while, I threaten to get rid of the dang thing and every other piece of technology around here, move to Pennyslvania and go Amish!!!