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
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.