Automating Theatre Effects

CHRISTOPHER L. ANDREWS, QUENTIN W. TERRY, BENNY CHEN, JAMES P. KELLY, KYLE P. PARKER, ERIK
G. WOJCIK, JOHN WIDMAN, NICHOLAS R. CURRIE, MATT D. HALLORAN, JASON FAZIO, DOMINIC M.
FUNARO, and DAVID L. RODRIGUEZ

Production plays depend increasingly on the best and most realistic effects. This requires a lot of manpower, raising the production costs markedly. We conducted research to see if a software solution could cut out most of the manpower to rely more heavily on software automation.
To accomplish this, at all points when the system is running, there needs to be an emergency stop button on the console and on the motor. For operations in the system, you would perhaps want to make complex effects leveraging up to 16 motors. Our solution to operate the motors, involves the creation of cues and within the cues individual effects. A cue for example could be an instruction to the Programmable Logic Controller (PLC) to run motor 1 for 10 seconds at 20 revs/sec, and when that is done a second effect of Cue 1 is kicked off. Another scenario could be, in Cue 1, motor 1 is runnings for 10 seconds and 20 revs/sec and when motor 1 has been running for 3 seconds, effect 2 of motor 1 kicks off with motor 2 running for 15 seconds at 40 revs/sec. You can imagine being at a play and seeing a piece of the background moving in synchronization with another moving prop. To produce a better standard for theatre automation, we did research on Programmable Logic Controllers (PLCs), Variable Frequency Drives (VFDs), the ModbusTCP protocol, the Dapper ORM (Object Relational-Mapping) and motor technology. We use the ModbusTCP protocol to communicate from the high level application (the interface) to the PLC, which
communicates with the VFD, which controls the motor. Additionally, the Dapper ORM could be used for
communicating from the high level C# code, to the MySQL database, which could store Motors, Cues & Effects, and PLC information.