Steel Vengeance

CoasterKyle1121 said:

I don’t see any logical reasoning to only having a set amount of people to ride SV per day. It actually sounds downright idiotic to me. If the issues aren’t fixed then don’t open the ride. It sounds to me at everything is good to go. All I know about the boarding passes is that all of the guests in line (including myself) got a sheet of paper that says immediate boarding through the exit of SV. The ONLY reason there was a set number of people to ride once it reopened on Saturday was because it was an hour before the park closed and they only had one train operating. If they had everyone storm to the ride, then they would be there all night.

I could be wrong, as my family and I were in line with early entry, but I think they did this specifically for Sunday because of the 1 train operation.

If they know that x amount of full trains can be reasonably put out in an hour and they only had 10 total hours on Sunday because it didn't open on time for early entry, then they can reasonably assume the amount of people that would be able to ride all day would be z.

You want to under-promise and over-deliver if you're Cedar Point so you set the expectation that only a set number of people can ride with one train operation. If that's not how they did it and it was an arbitrary number, then I really have no idea. But the above makes sense to me personally.

What's the capacity on one train? With a roughly three minute cycle that's twenty trains per hour if there are no issues with loading, which it sounds like there are at this point.

The dynamic changes when you add a train. Three trains is a guaranteed stack. I remember Mean Streak- gold would be going down the first drop, passing red on the way in while green was loading. Red always sat behind green for a moment or two before it could enter the station.
People foolishly complain about rides like Diamondback, and I don’t know how it could be handled any differently. Even with optimal operations there will always be a train sitting behind the station waiting for it to clear to unload. Then there’s Mystic Timbers where they concocted a “show room” to while away the time while trains naturally stack.

Three trains will, of course, move people faster through the queue. But it doesn’t serve to triple capacity. Add unavoidable loading delays and there you have it.
I hope they find their way to three trains eventually, but it won’t solve everything. I wouldn’t be the least bit surprised if they didn’t continue the boarding pass through the summer on the busiest of days, even when operations are at their best. If nothing else it would prevent crews and associated park employees from having to work until 4 AM every morning.

I think that doing the boarding passes when they have multiple trains running would cause a lot of complaints. People are used to CP keeping the line open until closing and then running the ride until the line is emptied. They even did that with MF and Magnum which were hugely popular in their first year, I don't see that changing with Steel Vengeance.

^ It's a tradition and a strong selling point. It's practically part of the brand now.

What's the latest a new popular ride has finished up for the night? Has this ever caused issues with preparing the ride for the next morning?

I am sure they have the three-train thing all figured out as-is, and we will see it when the season kicks into full gear.

I am NOT an engineer, nor a designer... but rather than relying on the mid-course brake run acting as a block, the straight run out of the station (before the 180 turn) appears to have plenty of room to act as a "staging" position. The transfer spot. Load the train, roll it out of the station to the transfer, and have it wait there. Meanwhile, another train could be loading/checked while the 3rd is on the course.

Then again, what do *I* know?! :) ::shrug::

If the mid course brake isn't a block then there is no use in having one. We all know we don't want them to use that as a trim brake, right?

If stacking is their concern, then how about dispatch one train, have it wait in the transfer brakes, then when the last train clears the MCBR, send the one in the transfer brake through. That sounds like a good way to do it without the possibility of a train stopping in the MCBR. I actually thought I remembered reading somewhere quite some time ago that's how it was going to be set up.

Thabto said:

If stacking is their concern, then how about dispatch one train, have it wait in the transfer brakes, then when the last train clears the MCBR, send the one in the transfer brake through.

That sums up what I mentioned above. :)

Part of the issue with a "Premiere Weekend" is that I would imagine it's hard for many employees to sign up for a job, work a couple days and then have a work week off before starting full time.

Or does training occur during those days off for all employees thus making my point invalid?

The story I've been told is that the computer is not yet set up for three train operation and it should be done this week. Now I flunked out of Computer Engineering before I got through all the calculus and physics and onto anything fun so I can't claim any real knowledge, but it seems like the program for three train operation (or really n train operation with at least n+1 or more blocks) on a modern roller coaster is a solved problem (don't release or push a train with drive tires from a block if the one in front of it is not fully cleared) and that the main thing would be to put all the hardware in place and get it correctly wired up and addressed to support the program (I've got to imagine that's done at this point), maybe tweak some timings, the speed on the drive motors or the lift, tweak the brakes for a smooth and controlled stop, etc. It would sort of boggle my mind if literally everything is programmed from the ground up on every ride and they'd set it up for two trains and then install the three train code as phase two. Maybe I'm wrong since we've seen this sort of thing before with Millennium Force and Dragster, but MF has the trains following eachother very closely as they move together through the stations so I'd imagine there's some extra complexity there. I remember hearing Dragster trains would move in a similar manner, but they never quite got it working that way so they essentially wait for the entire holding area in front of it to be clear before the next one moves. I always sort of chalked that up to Intamin being Intamin.

Brian Ondrey was doing programming for B&M (Consign) like 15-20 years ago and their rides have been some of the safest, reliable, and efficient ones on the planet so I think it's unlikely he doesn't know what he's doing at this point. I remember seeing a story that he was an intern and actually solved a problem with Dueling Dragons when it was first being commissioned. That's what makes me so curious about what actually happened on Saturday. My initial hunch was that the issue might have been more mechanical in nature since the Chess train which was bumped was making some very nasty noises while it ran the course. I suspected a bad wheel or two when I heard it. The train behind it sounded absolutely fine and then when it returned and Chess hadn't departed yet, there was the "bump." My initial hunch was that Chess knocked something out of wack or perhaps tore up some stuff on the way through the brake run and thus hampered the ability of the ride to stop Digger. When I saw the suits and RMC out looking at the brake run, I was thinking the brake run would be a mess, something on the chassis of Chess would be a broken mess, and the front of Digger would be messed up too. I was wondering why the PLC or an alert human would not have detected things out of place at the brake run and stopped Digger on the lift or at the midcourse. But I think it's safe to say my initial guess was totally debunked when Digger and Chess both were testing a few hours later and the ride opened later on with no visible damage to the brake run and with Chess as the one operating train. So I'm back to wondering if there was some strange edge case in the blocking that wasn't accounted for. Clearly they successfully stacked two trains at that spot without a problem during testing and throughout the morning. The train is initially slowed by magnetic brakes and its speed is well under control of the drive tires by the time it gets anywhere close to the station so it doesn't seem like a case of slipping through friction brakes or wet/worn drive tires. Was their some "bug" where if a train was sent exactly at the wrong time, the block showed as clear rather than occupied and the tires kept Digger rolling? I really don't know, but I'd like to understand what happened.

I doubt we'll ever really know and I am not trying to be some sort of self proclaimed expert on PLC programming or ride mechanics here, but I am interested both from a coaster standpoint and a technology standpoint to know.

This whole thing is very interesting to me, more so because of how quickly they got it back up and running. It makes me think it wasn't such a major issue.

On the roller coasters (and water rides) that I have operated, the standard block check involves not only stacking a ride vehicle behind the other (to ensure it stops as designed), it also involves attempting to clear that second vehicle while the first is still in its block. Obviously, the second one shouldn't move if its in a normal operating mode.

Now something I have seen in my experience working a coaster is that when in maintenance mode, you can actually advance the second train even if the block is occupied. In The Smiler accident, the ride being put into maintenance mode and the crew not verifying the location of the other train lead to the big oops. Not saying this is or isn't anything like that, just something I find very interesting.

I fully agree it seems a bit ridiculous to re-write the code from the ground up. However, I fully suspect that the code used on the rides is propitiatory to the manufacturer. For example B & M won't let any of their code be used with an Intamin, etc... Thus each manufacturer would have to write their own version of the same code. Now, that being said, I fully suspect there is code reuse between rides by the same manufacturer like Twisted Timber & Steel Vengeance. However, each ride going to be unique, and have some differences. There would be different numbers of sensors, different positions of the sensors, etc that would affect the program.

The approach they are using on this is to start simple, and work their way up. Start with one train. Get the system to properly operate that. Then slowly add the second train. Make sure the system is fully functional with two trains, and everything else that goes with it. Only then, add the third train.

I'm wondering if this boarding pass thing will continue. We haven't seen a normal day I guess though, where SV is used to running 2 trains at least and no rain delay either. I certainly would want to partake in going in the queue as last ride and waiting however long it would be.

Visionist said:

What's the capacity on one train? With a roughly three minute cycle that's twenty trains per hour if there are no issues with loading, which it sounds like there are at this point.

Six cars with 4 per car is 24 per train. The cycle is 2.5 minutes and I doubt they can dispatch in 30 seconds. There is probably closer to 15 or 16 trains per hour with a 1 train operation. One train could be under 400/hour. That may sound low because 3 should be 1200/hour but the load time does not count against the cycle when you run multiple trains. This is why they need at least 2 going. Even if they run it at 1 cycle at a time they can push near 600/hour with 2 trains. Of course they go beyond that when they go faster using the block break.

I have to believe that the ticket system is just a limited thing until they can get more trains running on the ride. For what its worth, they did a ticketing system (ticket to ride) in 2000 for Millennium Force and it was running full three train capacity at that point.

MDOmnis said:

The story I've been told is that the computer is not yet set up for three train operation and it should be done this week.

...

It would sort of boggle my mind if literally everything is programmed from the ground up on every ride and they'd set it up for two trains and then install the three train code as phase two.

Assuming the ride is managed via PLC, it's not "code," per se. It's ladder logic.

And while it is a solved problem, it's still humans who are programming the PLC, and as such they are going to make mistakes. And even at their most basic, these rides are pretty complex, so there are all sorts of avenues for difficult-to-foresee failure modes.

A big part of my job is in industrial automation, with automotive BIW assembly systems. Even a relatively modest automated cell will have hundreds of components - robots, prox sensors, clamps, valves, actuators, light screens, operator panels, etc. It's relatively straightforward to program how the cell should operate. The "fun" comes when the cell is running and we go to great effort to "break" things in all sorts of imaginative ways. We often spend weeks on these "shakedowns," finding and correcting issues. And inevitably once the equipment ends up in the plant the end user will find new failure modes.

Anyway, I guess my point is that it's probably rather easy to set up for 3-train operation. But testing for failure modes and recovery is considerably more complex than it is with 2 trains.

The thing I like and I would think the park like about the ticket to ride system is that it allows people to be out spending money rather than being trapped in a queue where they can't spend anything. Plus, nothing takes away the fun of riding on a coaster more than your bladder feeling like it's going to explode BEFORE you get on it.

I don't know much about PLC's, but I don't think the programming is particularly portable, as there's probably not an abstraction layer between the typical 3-train, 6-block layout and the logical bits (6 blocks to allow stacking outside of the station). Every ride will have a different set of sensors, motors and such, and those would have to encapsulated into some known interface to work against some generic "code" interface. That's easy enough in object-oriented programming, but I don't know that it's a thing with PLC's.

^What he said.

By chance, has anyone seen it testing since the weekend? I keep checking the webcam out and haven't seen it run at all.