Reveal Theatre Sign Reveals Complexity of Control
by Michael Karagosian
© 2000 MKPE Consulting All rights reserved worldwide
Published in the December 2000 issue of System Contractor News
I was recently asked to add a sign to a theme park entertainment system that I had designed several years ago. A sign? I did a little work some years ago on a sign in another big theme park just outside of Paris, so based on that experience I didn't think it would be that complex a job. I told my client I could do it and "signed up" for the sign controller business. By the end of the installation, though, I felt I could write a book, of which this article covers the highlights.
Display signage is one of those niche industries where creative design differentiates products and custom work reigns. You can almost get exactly what you need off the shelf, but not just quite. The many sign makers in the industry offer very different and innovative products. The choice of vendor usually rests literally on appearances and, if required, the amount of custom work that the vendor is willing to do. Rarely does the elegance of control method enter into the decision.
My client had already found the perfect sign vendor. The product had already been sampled, the mounting details worked out, and everybody liked the appearance. There was no question that this was the sign. Once on the project, I asked the vendor for their software documentation. Now, if you haven't had the pleasure of installing a sign or designing a sign controller, asking for documentation might sound like a straight-forward question. Often times, I'm told, good documentation can be scarce. Sign companies are usually small operations, and the system programmer may not be a permanent employee. For this project, I was lucky. My vendor had good documentation, and the programmer was readily available to talk to: he was the owner of the business.
When going through the documentation, the command set reminded me of something out of Redmond 15 years ago. It definitely had that old DOS flavor, only DOS was easier to figure out. If you've programmed a sign before, then you know just what I mean. Signs, being the product of a niche industry, are driven by small PCs or other microcontrollers running software written by the vendor. Usually, these programs, while performance driven, aren't very elegant to use. The product's control features tend to grow in awkward ways, since the command set is extended each time a customer asks for new features. I'm going to drop a few rules as I go along for those venturing into these waters. This is Rule #1: "Get to know the programmer behind your sign product before closing the deal." As you get into your project, you'll invariably need support from the guy who wrote the darn thing.
When considering the control needed, keep in mind that signs are one of those creative tools that clients like to toy around with. It's as if owning one gets the client's imagination going. After all, it's just a sign. Can't you just type something in somewhere and display whatever you want? Ideally, yes. Most vendors offer software to satisfy stand-alone applications, but take a very close look to see if it really supports your job. Don't be surprised if you have to write some code.
While my client had a good idea of what they wanted in terms of appearance, they weren't exactly sure of what they wanted the sign to say for all occasions. In normal show situations, they had a clear idea of what they wanted to see. But once everyone got to thinking, the exceptions began to pop up. The exceptions made it clear that this wasn't going to be a simple job. So here's Rule #2: "Identify all of the applications with your client up front." Well worth the effort.
To really understand the challenges in this project, I have to first explain the show for which this sign was destined. This was for the Reveal Theatre, a post-show for the GM Pavilion at Walt Disney World's EPCOT. (I should note that while most projects in a Disney park are handled by Walt Disney Imagineering, this project was not.) The show is an animated advertisement for GM vehicles. Three turntables, situated in a semi-circle, hold two to three cars. Each turntable has a rotary door, and the turntables themselves rotate so that, among them, only one car is "revealed" to the audience at a time. Two video walls are also situated on the semi-circle, one each between the turntables. There is a ceiling full of motor-controlled show lighting, spicing up the show. Each car show begins with a video, followed by a "reveal" of the automobile, with a total show time of approximately 90 seconds. A central show control unit runs and synchronizes video, audio, lights, and turntables, producing a continuous stream of entertainment that is completely automated. Once the show is started, no human intervention is required.
GM Reveal Theatre
The goal was to add a cylindrical LED sign, hanging above the audience, that would announce the brand of car now showing. More importantly to the client, we also needed to display the rest of the brand names in the order they would appear. Some difficulties were identified right away. The show control system is designed such that any turntable, or any car on any turntable, can be taken out of the show without disrupting the continuous nature of the show. This is a useful feature as cars are often changed out (they can be driven off a turntable back stage), and it allows maintenance technicians to deal with repairs without shutting down the entire show. In fact, the show control system is so quick that if the next desired car's turntable doesn't rotate to the correct position in time, the control system will immediately select another car show to present. So the play order is not fixed, and we needed our show controller to predict this order at the beginning of each new show. Other flexible features were desired, such as the ability to change a brand, or to move a car to a new turntable position, or to display a completely different message for special occasions.
When I first considered the methods available to control the sign, I thought it would be fairly straight-forward to do so through the show control system. The heart of the control system is an Alcorn-McBride V16 show controller. The V16 had a few spare serial ports, and one could have been assigned to send serial messages to the sign. But this wouldn't satisfy the flexibility needed by the client. Once all of the applications were identified, it was obvious that a GUI was needed where an operator could enter changes without disrupting the show or calling in a show programmer. I decided to add a separate PC-based sign controller running custom software. Which brings me to rule #3: "Be sure your sign controller is as flexible as possible."
Adding a PC-based sign controller solved some technical problems as well. The sign's built-in controller has a sizeable set of commands for displaying fixed messages stored in flash memory. However, changing the stored text in the sign required that a manufacturer-provided utility be used and that the sign be taken out of operation during the reprogramming. This didn't sit well as the software wasn't "client friendly", and since most changes would occur during day hours, it would be disruptive to the show. To overcome this, I sought to configure the sign to simply display raw text data as it was received, i.e., I couldn't use the fancy built-in programming features of the sign. Fortunately, the sign had just such a mode of operation.
The sign controller design had to take a number of issues into account. Timing was one of those issues, as the sign's scroll rate - the pace at which text scrolls across the sign -- is a snail's pace compared to the speed at which serial text is sent to the sign. This meant the serial text had to be carefully managed so the sign would not continue to display a message beyond the 90 second length of a show. In the "streaming text" mode of operation, the sign's serial input required Xon/Xoff software flow control, which needed to be handled by the custom program.
Now the task grew to providing a PC running custom software that communicated on two serial ports. One serial port using Xon/Xoff flow control to communicate with the sign, the other receiving show data from the V16 show controller. The next step was to design a GUI that the customer could easily operate. The result of that is shown in Figure 1. The phrases of the message are entered at the top of the GUI in the "main message" area. (Underscores are used to indicate white spaces.) Automobile brand names are also mapped to the various turntable positions in this section. There's a separate place to enter a "special message", which can be selected for display in the "message option" area. The "display options" area allows the operator to choose how the messages are displayed. All of these settings are stored in an INI file, which is loaded whenever the program is re-booted. To keep unauthorized personnel from changing the message, a password has to be entered to save changes or to exit the program. The idea was to let the customer figure out the best content and arrangement of messages for their sign, and give them the ability to change their mind without incurring the services of a show control programmer. Since the sign control computer is located in a room far from view of the sign, a display bar is provided at the bottom of the GUI to simulate the sign's action.
Fig 1. Graphical User Interface
All of this looked like business-as-usual, of course, until it came time for the installation. The sign panels and electronics were manufactured in Boston by Sunrise Systems. The sign frame was designed and assembled, along with sign panels and electronics, by H.B. Stubbs in Michigan. Needless to say, I was sitting in California writing code, and no sign to test it with. So I first met the sign in Florida, and we had a little difficulty learning to talk to each other. Serial communications are never a piece of cake. Once that hump was crossed, we noticed an odd slowing down and speeding up of the sign's scroll rate. This puzzling phenomenon was due to a clever but undocumented feature in the sign that slowed the scroll rate whenever the sign's buffer content dropped below so many bytes. The math said that the system should never have triggered this feature, but our eyes weren't deceiving us. Here's where Rule #1 came in handy: upon talking it over with the manufacturer, they quickly modified the sign's code to remove the variable speed feature, thus fixing the problem. The customer was pleased, having all of the features they had hoped for, and were quickly making changes to the sign's message. All of the custom code, the sign controller GUI and the sign vendor's modified program, was placed in a single InstallShield installation program for safe storage and easy retrieval in the years to come.