Triggers

So far, we’ve looked at an overview of the Winscript user interface and the basics of sequences which are groups of events that do some action to make our show go. We’re going to look at the detail of those events in our next session, but for now, let’s talk about how these sequences get started and the various ways they can be triggered!

Sequences can be triggered by changes in time, variables, I/O, or an incoming message from another device.

Let’s talk about some of the use cases for how the triggers might come into play. We started with the PLC example in the previous video, so let’s dig into that one. The PLC is part of the ride system and so it knows where all the ride vehicles are at all times. Because of that, it can tell us when it needs us to play scenes for each ride vehicle. This can be as simple as a single audio track at each scene, or it can be as complex as multiple animatronics, pieces of show action equipment, video tracks, audio files, and much more. The show controller will be the one distributing the messages to all these devices (or in some cases, subsystem controllers will help to distribute some of these messages like audio or projection subsystems). These messages can come over a variety of industrial protocols like Ethernet/IP, ModBus, and more. We are constantly working to add new methods of communication to the controllers.

There are other ways this can work in different types of systems. For kiosks or museums, it might be a V16X taking direct contact closure triggers from buttons in front of exhibits to start the playback of video or audio files. Those can be wired directly to the V16X through its contact closure or voltage inputs OR to networked I/O like the Alcorn AMIO modules.

In another method, these could be serial or ethernet messages coming in from a PC or remote control via Arduino or Raspberry Pi. The V16X can parse those messages and then send control signals to other network devices on behalf of those input systems.

We also can take control signals from ShowTouch user interface panels, which we’ll learn more about in a few lessons.

So now we know what they can do for us and where they can come from. How do we tell those triggers what to do when they show up?

On our sequences, there’s a space for Triggers. We can get to this info a couple of different ways. If we double-click under the column heading for the correct sequence, we can launch the triggers. We also can highlight the column and click the Triggers button OR we can right-click on the sequence number and look at the existing triggers OR Add a new trigger. Notice here that we get a list of the four types of triggers we can add – we can Start, Pause, Reset or Stop Looping a sequence. If this were an SMPTE sequence, we’d see slightly different choices here – Arm and Disarm (which we’ll get into in the SMPTE video).

Triggers are exactly what they sound like – they are actions that trigger a sequence to do something (start, stop, pause, etc.) They can be tied to I/O changes (buttons, inputs, outputs), variables (integers, strings, Booleans, etc.), date/time (including the special conditions of sunrise and sunset which are calculated based on latitude and longitude), which can also recur on a scheduled basis OR an incoming message to a device. Let’s walk through a few of these!

The most simple version of a trigger is a push-button on the front of the device to start a sequence. Let’s walk through that with this simple script.

This script contains a Start Video and Stop Video sequence. We’re going to use a “Start” trigger to start the Start Video sequence when button1 is pressed and a “Start” trigger to start the Stop Video sequence when button2 is pressed.

NOW. When you first hear that, you may think “WHAAAAT?!?” Why would I have a start trigger to STOP something from playing?

Because. Because the sequence called Stop Video does all the work to stop the video from playing (and it could be more than just a simple stop command – it could mute audio, mute video outputs, switch inputs to a different source, start a background loop, etc.). So just because we’re stopping media doesn’t mean we want to use a STOP trigger. Capisce?

So we’ve got this Start Video sequence. We’ll add a start trigger based on I/O from button1 going HIGH (turning on). We could make it work the opposite way where a button going LOW or turning off if that made sense for a particular type of input (a normally closed button, for instance). Once we click save, we’ll notice that the trigger shows up in the list of sequences. If we have multiple triggers, they’ll be on the list one after the other for easy access.

Let’s add another for Stop Video sequence, based on button2. Now let’s see it work! When I press Button 1, we can see Sequence 1 starts playing. You can see the video playing back on the monitor and the front panel of the V16X says “Show: Running”. When I press button 2, the sequence stops, the screen goes to black and the front panel of the V16X says “Show: Stopped”.

Cool, huh? We can add all kinds of other fun stuff to this, but we’ll hold off on that until we get to Events. Let’s talk about some of the other kinds of triggers and how we might use those.

Variable triggers are very handy for tracking internal system status and responding appropriately. You might have a variable for tracking system mode (Off/Auto/Manual/Remote or similar) or you might have a variable for system power (On/Off). You could have a variable that tracks how many guests are being loaded into a show area and only start the show once it reaches a certain number of people or once a certain amount of time elapses. Variables would work to trigger any of these types of events. Let’s look at a simple On/Off system state variable.

We have an initialization sequence that goes out and powers on all the LCD screens in our venue when the system is Powered On for the day. So when strSystemState = “On”, we want the Startup sequence to run. We ONLY want this to run when the system CHANGES state – if the system receives multiple ON requests, we only want to run it the first time (otherwise we may change states of systems that we have changed later). This logic may vary depending on your installation and needs! And then for our Shutdown routine, we do the same thing, we create a trigger for where the variable strSystemState = “Off”. We can force this string to be either “On” or “Off” and watch the sequences fire here in the Live Log – and watch our systems respond appropriately.

Time-based triggers are pretty straightforward – when a time happens, the sequence trigger runs. There are a few unique things you can do with time triggers that we should look at, though – specifically sunrise and sunset. Remember how we looked at setting the Latitude and Longitude of our controller earlier? Turns out that’s got hidden value for you here! IF you set those values correctly, the controllers will calculate your sunrise and sunset times for that day and allow you to run triggers for those special times. This is immensely useful for setting lighting looks appropriately for exterior lighting, but it can also be used for setting the look of a display according to the conditions that are occurring outside. These values are also available as variables in the system that are updated daily, so you can reference them and perform mathematical operations to run your sequences with them (i.e. I need to run something an hour BEFORE sunrise or an hour AFTER – I can use the variables and do some math with them to check my conditions).

Let’s say we want to set up a recurring time-based trigger to wake up our system at 8 a.m. every weekday morning. This will be in addition to the trigger we defined with strSystemState above, so I’ll add a new trigger to the Startup sequence that recurs every weekday at 8 a.m. The next time the clock rolls around to 8 a.m., our sequence will run and get us set up for the day.

If we have external devices in our system, we may receive messages from them when it’s time to do some activity. For instance, if we have a PLC, an incoming message or variable change from the PLC could signify entering a scene or queue trigger, or we could get a Ride Start/Ride Stop signal where we need to start/pause/stop/resume scenes (be sure to check out the application note video about resuming shows without missing a beat – not every show controller can do this!). We could have an audio subsystem that needs to pass us information about zone mutes or speaker statuses to display to users. Let’s take a simple example of a status message coming in from an Animatronic Controller (the Weigl ProCommander AX). Here’s the format of a status message (and don’t worry if it’s a little hard to read – that’s the show controller’s job!). Whenever the show controller receives a message, it parses this into a readable format in device variables – and then you can use those device variables to take action on something, for instance, if a motor has an error, you can send that message to the user or if a homing routine completes, you can indicate that the show is ready to be run.

Triggers are the catalysts for action, the ignition to our sequences. Now that we know how to get them started, though, it’s time to really dig into sequences and adding all the events that make things happen and build some really cool stuff together. See you in the next session!