Devices
As awesome as the V16 and other show controllers are, we understand that they aren’t inherently the show (more’s the pity). People don’t come from all around to watch the lights dance or the screen flash on the show controller, the same way most folks don’t go to the symphony to watch a conductor – it’s about the show, the music, the whole experience.
And so it is here – without something else attached, the V16 isn’t THAT exciting, so we need to add something that we can control to make a show. Like the Muppets, it’s time to play the music, it’s time to light the lights – so let’s see how we do that.
This is the Devices panel where the first bits of magic takes place.
The only device on the list currently is a V16X. Let’s say that we’re designing that same dark ride experience. We had a video moment that was going to playback on the door as we lead into Scene 1 playing on an A/V Binloop Uncompressed.
We need to know a little bit more about that device in order to add it to the list. We need to know the type of device it is (Binloop), how we’re going to connect to it (serial, ethernet, MIDI, etc.), what the configuration of the device is, etc. Many of these configurations are unique to the device and product file used to support them.
A product file is the description of everything that our controllers can currently do to communicate with a particular device. A simple one might just be a “Message” instruction where you send your own message to a device. We have a generic implementation of this that is often used when needing to send TCP or UDP messages to a device that doesn’t have its own product file yet. A more complex one might involve incorporating external metadata and custom functions and require custom development (though these are the exceptions). There’s a software tool called “Product File Creator” that’s installed alongside WinScript for you to be able to create your own Product Files with assistance from us. We also provide support for these kinds of requests if you need a hand. Check out Justin’s excellent Product File Creator course for more information.
Included with WinScript are almost 400 product files that describe connecting to nearly any type of conceivable system. Lighting controllers, audio systems, animatronic controllers, PLCs, TVs/screens, video servers, projectors, video switchers, I/O devices, and more!
From the Devices panel, we can add new devices and configure the devices we have already added. We can click Add here in the menu, or we can double click on the blank row at the end to start the wizard or we can edit an existing row.
First, we’ll need to give our Device a name. This is what we’ll see it called inside our script, so it should be something descriptive and convenient for you to remember. You can use manufacture and model names, but you could also just go with something like “QueueLineProjector_SectionA” or “Scene2_BunnyFigure.” You’ll use this when you’re creating your sequences, so make sure it’s something that will help you down the road.
Next, we need to choose the manufacturer. This list contains all the known product manufacturers we have product files for. If you don’t see your manufacturer listed – don’t worry! There are still ways to make your product communicate (we’ll see that momentarily). We’ll go with an Alcorn McBride A/V Binloop Uncompressed for now. There are versions of the product files saved, so if you need to look back to a previous version or create your own version of one, you can make sure to choose the correct version here. We hit NEXT and now we get to figure out how we’re going to communicate to this device.
All of our modern controllers have the ability to speak to Ethernet and serial devices. Many also can speak over Midi. Which connection type is available will depend on the product file – for instance, Midi doesn’t make sense for an A/V Binloop Uncompressed, so it’s not even showing up as an option. I’ll pick Ethernet, but know that serial is here too (and there are often good reasons to choose serial over ethernet!).
The V4X and V16X have multiple network ports, so we need to clarify which one of our ports is connected to the network with the A/V Binloop Uncompressed on it. For now, I’ll leave it at A, but it could be on any of those ports (depending on how you design your system). I could have multiple Binloops, one per port if I wanted to!
On the device side of the connection, I choose what method I’ll use to communicate to it. For some devices, you’ll have a choice of either TCP or UDP; choose the method that’s right for your installation. For this device, UDP is the only option, so we’ll go with that, and we’ll put in an IP address and leave the port at the default. (Did you know that Alcorn McBride has ports 2639 and 2640 registered as “our” ports with the IANA? Jon Postel would be proud!)
We click next and we see Device variables that are part of this product file definition. These will vary by device. Some will have none at all and some will have many; for now, we don’t need to look too deeply into these, but it’s important to know that they exist.
So now I have a device I can communicate with! Let’s add one more – how about a PLC? PLCs are often used for safety control inside an attraction. In our case, the PLC is going to tell us where our ride vehicles are inside an attraction and when to playback a scene via something called a trigger. So we’ll add this Allen-Bradley PLC and configure an incoming variable and outgoing variable from it so that we have something to tell us when to start our scenes!
Now that we’ve got those variables, let’s go ahead and take a look at Triggers in the next session.