Moving More Stuff Onto the Gravesend Inn Network
While the audience members blithely wander through the Gravesend Inn, they are being silently stalked by frightful things like:
All of these things are part of the show control system. And now, onto some serious control geekery (feel free to skip the rest if your eyes start glazing over).
The Gravesend Inn attraction has evolved slowly over about 10 years, and the show control system has evolved along with it. The haunted hotel has always been interactive, responding to the audience's actions. At first, the attraction was pretty small, and we just used a few sensors, and lots of students behind the scenes moving scenery or scaring people. As the system grew, though, we added more and more sensors, and a few years ago, I standardized our I/O system onto "TCP I/O" boxes.
These are based on an Advantech I/O card, the 6050, and each box allows us to connect in up to 12 simple contact closure output sensors--motion detectors, push buttons, microwave sensors, photo cells, etc. I used these Advantech boxes because they are relatively cheap and allowed me to talk to them and poll their input state over the network using Modbus TCP commands. ("Cheap", of course, is relative, since I had to spend like 20-30 hours figuring out the Advantech Modbus TCP I/O addresses, since the documentation was completely wrong, click here for a Word document detailing the issues). But this system worked out well (although after several years, one died last year).
As the attraction grew, we started adding pneumatically-actuated effects, so we now needed some sort of output device control from the show control system. While we had initially only configured the TCP I/O boxes for "I" (input), each unit also had 6 "O" (output)s, so it was pretty easy to use them to actuate the effects. To make it a bit more flexible I designed some relay boxes based around a $99 Automation Direct DL05 PLC (second picture from the top above) and a 24V power supply. While I could have just driven the various effects from the Advantech output (through a relay or something), I wanted the PLC for future flexibility--for example, to include interlocks later--and for things like monitoring E-Stop, etc. I also wanted some connectors (remember, we have to load this whole thing in and out every year), and settled on 4-pin AMP CPC connectors. Here's the back of one of the units (gray box on the bottom):
To keep things simple, the DL-05 PLC was just taking simple contact closures from the Advantech boxes over a multipin cable that we made, using the power supply in the TCP I/O box. This was easy because I already had the communications worked out to the Advantech boxes, and we already owned them. The drawback of this approach, however, was that we had to run a custom 7-conductor (6 outputs and common) cable between the TCP I/O boxes and the Relay boxes (you can see this cable (also a CPC connector) in the above photo, going from the left back of the TCP box to the right top of the relay box). This meant that either these relay boxes have to be located near the TCP I/O boxes, or we have to make very long, custom (and expensive) multipin cables to connect the TCP box and the Relay boxes. But this approach worked fine at first, with just a few effects spread over the attraction. This year, though, we added two more effects, and this meant that the relay boxes for the pneumatic effects now needed to be located in different places than the input sensor boxes. So it was time to move these relay boxes onto their own Ethernet control.
Another reason I had selected the DL05 PLC is that it has an expansion card, that can accommodate a $199 H0-ECOM100 Modbus/TCP card. As I've written about before, I'm on a quest to get every single control device in the haunted hotel onto our show network and off of old legacy protocols like serial and MIDI (I'm down now to just two serial ports to ancient legacy video switchers, and MIDI to the lighting console (which actually is sent using a KISS box over the network) and the Yamaha DM-1000 mixer). Like anything else involving industrial control, getting something like this to talk to a show control system like Medialon Manager (our show control system) is never "plug and play". Medialon has direct support for Modbus/TCP, and the H0-ECOM card supports it. But that, of course, is just the starting point.
First, we had to establish communications between the PLC and Manager. My show control student crew members Felipe and Lillian set up the system, and we were able to ping the PLC and so on, so we knew it was connected and functioning properly over the network. But on a first try, we weren't able to get the PLC to respond, so I started working through the system very--uh--systematically, and eventually got it all working. To get started, we had to see what the DL05 could support (this is why, with anything like this, I recommend buying only one unit, testing it, and then expanding from there). Automation Direct actually has pretty good manuals available online; the Modbus manual for the ECOM card is here. Next, we got the IP address set in the PLC and in Medialon using the NetEdit software for the ECOM card, and after realizing that some of the older ECOM cards we had around wouldn't accept Modbus, got it communicating.
Next, I wrote a Manager test program that would, on a button push, poll an "X" input of the PLC using a command from Medialon. Here's where we often see discrepancies--Medialon calls this command, "Read Discrete Input", while the DL05 documentation calls this "Read Input Table". But, fortunately, the always indespensable Wireshark anaylyzer (which calls this command "Read input discretes") was able to show the actual Modbus numeric code, and I was able to find out that both of these commands were a Modbus Function Code 02, and I got the input polling working. (Similary, Medialon calls Modbus command 15 "Write Coil", which Automation Direct calls "Force Multiple Outputs", and Wireshark calls "Force Multiple Coils"). I picked the input first because it was kind of easy, and then moved onto attempting to controlling the outputs. At first, just to see if it worked, I tried to write directly to the Y relay outputs, but I couldn't get this to work. And then it dawned on me--the internal program in the PLC was also continuously writing the state of these Y outputs too, and so even if I turned the output on, the internal PLC program would immediately, within one scan time, turn the output off. So I deleted out the PLC program (one very cool feature of this ECOM card is that you can now talk to the PLC directly over the network--no custom serial adapter needed!), and was able to write to the outputs with Modbus with no problems. Well, maybe one problem--there's a discrepancy somewhere in the address, which I document in my book (regarding MIDI) as the "off by one" problem. If I send a Modbus command to address 2048 in Manager, Wireshark is actually showing me a 2047, and the PLC was reacting accordingly (I've sent this info onto Medialon as well). So by simply offsetting all the addresses by one, I got it working just fine.
And then I rewrote the simple PLC code to accept the old X inputs from the TCP I/O boxes, and also fire from a new internal C series "relay":
And now, we're able to fire these relay boxes directly over the network! I wrote a test program to pound the system all night (something I always do), and everything seemed to hold up fine.
And now, we can place the relay boxes wherever we like, and just drop a Cat 5 cable into it from our network switch. This kind of Ethernet control is incredibly flexible and reliable, and increasingly affordable.