CP Network Operating Center?

PLC's have been running machines for decades, rides included. PLC stands for "programmable logic controller," and they do what the name implies. Rides are not that complicated. If one thing is in a certain state, do this or that. PLC's were made for that.

Now PointBuzz, that runs on Windows.

I hate computers and so does Cedar Fair.

For those interested in what controls some of the rides at Cedar Point check out this information on the ControlLogix Processor and the rest of the components and see why a ride will never run off of a Windows box.

Also, for you youngsters interested in Electrical Engineering, look into the world of automation. It's a field that will continue to need people as we are finding ways to control things around us without human intervention.

Without giving too much information, I made the jump from IT to the automation world a few years ago and work for an Allen Bradley distributor not far from Cedar Point.

~Rob

You don't say Rob? :)

I've been too preoccupied to pay much attention here the past couple of days (starting a new round of severe underemployment can do that...), but let me chime in...

If you read carefully the EULA that you agree to when you use Windows, you will find that there is some very scary text in there that means that Microsoft themselves basically declare that Windows is unfit for use in any life-safety critical application. Period.

PLCs operate in an environment very different from general purpose computers. You know how modern computers tend to be object oriented, where objects carry properties and interact with each other? It's a useful model, but in the PLC world, it is all about signals. Signals can be literal signals, real-world I/O being driven high or low by the ride hardware, or they can be virtual signals. Early PLCs were designed to emulate relay logic (because that was what they were intended to replace). Stuff happens, which causes an electrical decision to be made, which causes other stuff to happen or to not happen. The actions that the PLC can take are designed specifically to be extremely limited, which makes the code for these things very obvious to interpret, and makes their workings not merely "bulletproof", but "armor-plated". The real benefit to using PLCs instead of relays is that the PLCs are programmable (so the actions can be changed or swapped out), and because with the right I/O boards, the PLCs can also handle analog signals as well as digital ones.

PLCs are given the job of performing very simple tasks at a very high cycle rate. These tend to be relatively low power processors with high capability because the instruction sets are deliberately kept simple. Traditionally, rides (and other safety-critical systems) have been built using multiple signaling systems and even with multiple PLCs so that critical functions are joined using a logical AND or OR, so that critical activities only happen when both programmable systems agree with each other. Often such systems are built using different hardware. Today, all of the major manufacturers offer safety-rated PLCs which build measurable levels of redundancy and reliability into the PLC itself.

For example, on a roller coaster, there may be a "check out" switch and a "check in" switch on each block. One PLC is wired to the check in switches and the other is wired to the check out switches. As a train leaves Block #2 it trips the check-out switch for Block #2, and as it enters Block #3 it trips the check-in switch for Block #3. When this happens, each PLC knows, through its internal programming, that Block #2 is now clear. Both PLCs have to signal that Block #2 has cleared in order for the brake in Block #1 to open and allow the next train to pass into Block #2. That way, if a switch fails, or if there is buggy code in one of the PLCs, the disagreement between the PLCs will prevent the creation of a hazardous condition (allowing a train to proceed from Block #1 into Block #2 if the block is not clear).

Using PLCs, the code to perform logic like this is very simply designed, so that each logic wave* can run very quickly. In each logic wave, all of the signals leading to the processor are checked, and if any trigger condition is detected, the appropriate solution* is run. So it is effectively a multi-tasking system (in some cases multi-threaded) optimized for interfacing with the real world.

I should clarify that I am familiar with the general operation of the PLCs used in the amusement industry, though I've never programmed one. I am a participant in the ASTM subcommittee that is presently re-writing the design standards for safety-related control systems used on amusement rides. The language I've used here to describe the operation of the PLC is actually based on a similar class of systems with which I am quite familiar, the Crestron 2-series processors, which are generally Freescale Coldfire CPUs running an embedded real-time operating system (no, NOT an embedded version of any desktop OS. Not a Unix variant, either.). Like the safety PLCs, Crestron's controllers are signal-driven, multitasking devices. Like Windows, they are not rated for safety-critical applications.

As has been noted, a depressing number of touch panels, including those from Crestron and Rockwell, are now running Windows CE or whatever Microsoft is now calling their embedded version of Windows. Those things are just as buggy and unreliable as their reliance on any flavor of Windows suggests, but the purpose of the Windows-based OS is to translate between signals supplied by the PLC and Windows graphic objects displayed on the screen. This enables the interface programmer to make use of Windows' graphic capabilities for the user interface. Usually with touchpanels, the entire user interface is stored in the touch panel itself, so that only representations of selected signal data need to be sent to the panel. This dramatically reduces both the processor overhead in the PLC, and the amount of data that needs to be supplied to and from the touch panel for a reasonably elaborate interface. So you might see a PLC-based system control panel boot into Windows, but that is only for the display interface. The control system itself is running something vastly more robust.

--Dave Althoff, Jr.

*The terms "logic wave" and "logic solution" refer specifically to the operation of Crestron control system programs. I am not sure if Rockwell uses similar language.

--DCAjr.

Dave stole my answer.

Rideman -

So i'd assume that any standard pc interface is strictly for monitoring in a user friendly manner, or for maintenance checking ladder logic conditions? Similar to transfer lines / etc for manufacturing production environments?

Wayne,

I know the question wasn't directed to me, but yes, that's pretty much where the PC comes into place. The area I deal in is the data collection, reporting, and security of process information including the PLC's. So in addition to the PC's, there are also server based applications that collect and report data as well as host HMI applications in a distributed environment. However, RGR could better answer whether Cedar Point has any of that or not.

~Rob

P.S. RGR, see what I did there?

Typically, what you are going to see is a PLC doing all the heavy lifting, then there might be a data channel leading to a PC, terminal or printer for logging and diagnostic purposes. The PC won't have direct access to anything in the PLC, but the PLC may be set up to feed data...real time or otherwise...to the PC. Sometimes it isn't even about presenting data in a user-friendly way...the PLC lacks any kind of display device at all, in many cases, so hooking into its serial port or network connection may be the only way to get a comprehensive data readout.
It's kind of like when you work on a car and it is easier to read a code off a scan tool than to count indicator light flashes.

Also, if adjustments need to be made to the PLC program, that is done by hooking up and talking to the device. That's kind of a dangerous thing. You get system logs from the same port you use for programming the unit, so it is important to take steps to protect the program from inappropriate changes. Like burning it to an EEPROM, for instance, and keeping careful records of the program length and checksums.

It would be interesting to learn whether there is any truth to this old story...

Apparently when Raptor was new, the ride would run perfectly for a while, then without warning, it would shut down...the PLCs mould throw a fault and the ride would have to be reset. After lots of troubleshooting, they finally figured out the problem. A printer had been connected to the PLC to log all of the signals generated by the ride. The ride was generating enough logging data that the printer could not keep up, and eventually, the logging information would fill the printer's buffer, and the interface would send 'wait' signal back to the PLC, which would do just that.

Replacing the printer with a computer would have solved the problem.

--Dave Althoff, Jr.

Rockwell uses the term "scan" Dave :)

Cute Rob.

Dave,

My brain has a crush on yours.

:)

After doing some research on PLC's , they are pretty standard, and I understand how the PLC's work, but you are right, they need to have an output display, printer, etc. They are also generaly interfaced with another "computer" type device. I/O operations, Logging etc. the printer is a good example of what I was asking about, the printer is a logging device that basicy records on paper , opposed to a network drive, local drive, solid state, bubble memory, or other type of memory. Output is kinda what I was looking for. and I found that depending on what type or reporting is needed, changes what kind of device that is on the other end of the PLC.
With some research, i found that some of the interface devices are running Windows of some flavor, Unix of some other flavor, etc. and from what I already was able to find, that most of the output of the PLC is done in just raw ASCII text, so a Commodor 64 could have done the Job if it could write to the screen, disk fast enough.

but generally, a PLC seems to be based on just a bunch of relays (not hard relays, but data on/off relays, that do checks and balances., and run a single hard coded program mostly in machine language. )

from also my research , the term PLC is such a generic term , like the word computer, witch could be your phone, to your PC at home, to the unit that runs your car. Mostly machine language again.
also you could look at a PLC almost the same as the computers used in the Apolo missions, the differences being is that the Apolo missions were programmed a little differently, but generally, just a checks and balances, and corrections device.

kinda just rambling, here, but I understand what the PLC is, but the real question, was really how was the data collected outputted, and how is the data inputed, worked in (Start/stop, breaks, safety bars).

ikes.. I did find a few coasters either in the works or in action, have a touch screen interface, from what I saw, these were run with a MS Windows interface, or a Unix X-Windows interface.

output via a network, sometimes is only done internally, (PC to PLC to Sensors, but as we said, most of them are stand alone).

long story short, this would make the NOC at Cedar point a lot smaller then I expected

On another note. I did find that the Ticket system/Season pass/attendance system is run off a Windows front end, and I think Microsof SQL , and Oracle database. Obviously synced offsite with other systems for their entire network. I was able to do a little confirmaton when I found some help wanted programmers ad's from sometime ago.

and I'm out, but I am still curious how the rest of the networks other then the coasters work, and I will do some more reading.

There is no "NOC." The Internet companies I've worked for didn't even have a NOC. They aren't ISP's or telephone companies. Like any other large business, I'm sure there are a series of network closets and a few server rooms.

I know that Gate Central was continually a work in progress back in the day, particularly when it was rolled out to the Cedar Fair parks, and I'm sure it still is. My understanding is that each location is autonomous on any given day, but there is some level of synchronization on a regular basis to account for passes purchased at one park but used at another. It was implied once that the sync happened once over night, with some edge case of someone buying at Kings Island one day and not being recognized that evening at Cedar Point. I have to assume that has all changed by now. I think it's a pretty good system, if only for online renewals.

Now the Accesso system... don't get me started.