Automation Programming Tips: Important Steps To Cue Writing

When it comes to automation programming, it is important to have faith in your team’s ability and their key strokes. However, in the interest of everyone’s safety, trust, but verify. Verification requires one thing, validation.

Validate everything. Even the smallest of changes need to be verified and validated for the safety of all involved.

When programming automation, a lot of older or antiquated systems, their initial parameters including, but not limited to, positions, velocities, acceleration and deceleration are set to a default setting when writing or re-writing a cue. So, all it would take is one parameter to be wrong and the cue is no longer set properly. An operator wants to change the cue by 50mm, not a big deal, easy to change quickly right? Unfortunately, the operator can easily make it 5mm or 500mm or 5000mm by mistake. Take the time to enter, check and re-check all the data carefully before hitting the record button. Even the best of programmers get a fat finger from time to time, but they are the best because they always follow the rules of verification and validation.

Here are the steps to follow when programming an automated cue:

1. Write or Rewrite a cue.

2. Check that the cue was written correctly.

This will only take a few seconds, but will save you time in the long run. Depending on the system, saving can sometimes take what seems a lifetime. Save time by checking twice and recording once.

3. Record the cue.

4. Check that the cue was recorded correctly.

Sound redundant? It’s not. Again, a quick check that will put your mind at ease and save you time and confidence from your team when the cue runs correctly. Once you run the cue and it’s wrong, you have to start the record process all over again and your team is going wonder what happened and more than likely question the next one. Check three times and run once.

5. Run the cue without anything else connected to the system.

6. Run the full cue with all the other devices grouped to the axis in a controlled environment.

7. Run the full cue with all elements (ie, person/prop attached to winch, lift cue in sequence).

8. Validate the cue in full show conditions.

The most critical and crucial part of this process is to not let anyone, no matter how high level they are, to push you to speed up. Some programmers work at lightning fast speeds (still with the ability to check their work multiple times) and then there are other programmers that work at their own pace.

It’s not a race and it won’t help anyone if the cue has to be re-written three times due to the person pushing the buttons being rushed. The best part about sitting behind that console is, you are the pace car. You set the pace and everyone else has to follow. No one can push you, but you.

A review of cues and cue stacks is also an integral part of this process.

Even though a programmed cue has worked for years, it is crucial that it is reviewed regularly to see if it can either be or needs to be improved or updated.

It is best to try and leave as many complex and repetitive movements, along with all of the safety-feedback loops to the machine as possible. The creation of the most efficient cue stack is not going to come in one shot. It would take even the best of programmers a period of time to experience and use their cues stacks before finding the best method to improve on them.

In some cases, It may even take several generations of programmers tweaking throughout the life of a cue stack before its cues are considered fixed for all end-users.

It is advisable to give your team the opportunity to make adjustments to their cue stacks throughout the life of the show, when appropriate.

Sometimes major changes can wait until a longer maintenance period for sake of marginal testing time that may be required.  If you don’t want to wait till a dark period and you know something that could be easily changed, verified and validated quickly, do it. Everyone is happy if you can increase safety and provide a smaller window for error.

Can a cue be changed right before the show?

Sure, if you are willing to either hold the show for validation purposes and possibly risk putting the artists and apparatuses in front of the audience prior to the show. If not, then it is best to suck it up and either cut the cue for that show or run it as previously verified, until proper changes and validation can be completed.

With certainty, in ten years, you won’t even remember cancelling the act. This means it’s not worth it. Human operators are not flawless and are bound by sheer numbers to make mistakes. So it is not fair to put all the pressure or responsibility on the operator without giving them the appropriate amount of time and resources to follow the steps properly (not just the ones recommended above, but whatever they may be in your particular Standard Operating Procedure) to ensure safety throughout the entirety of the writing and recording processes.

So for the operators, leads, and managers, it is important to trust, but verify. Validation, validation, validation.

The strength of a cue is always going to be a matter of perspective and opinion between programmers. What is known and hopefully agreed upon, is that no matter how weak or strong a cue is, there is always a safety protocol or safety component that is required to be in place to prevent putting an operator or a programmer (usually one in the same) in the position of being able to make a critical or fatal mistake.

This could be a software protocol preventing operators from exceeding a given parameter or a mechanical limit installed to keep a system physically within its range of motion or hopefully, these days, both. This was not always the case and we need to thank and applaud the pioneers of our fields that came before us that have helped improve on these safety standards one issue at a time.

In any venue, whether it be a cruise ship, resident theatre, or tour, the programming standards and requirements are going to be different. The aforementioned steps have been utilized in the past and proven effective. However, please feel free to improve on these steps by either adding additional layers for safety or removing a section here or there if it doesn’t pertain or work for your particular system. The main goal is to achieve programming that is efficient and safe.

Got any recommendations or additional tips for the newer programmers or those programmers wanting to up their game? Let’s hear them. The best part about this is we all get to work together to make our industry stronger and safer than ever before.

Also by Jay:

Troubleshooting Your Theatrical Systems, Part 1

Redundancy In Theatrical Systems

Join TheatreArtLife to access unlimited articles, our global career center, discussion forums, and professional development resource guide. Your investment will help us continue to ignite connections across the globe in live entertainment and build this community for industry professionals. Learn more about our subscription plans.

Love to write or have something to say? Become a contributor with TheatreArtLife. Join our community of industry leaders working in artistic, creative, and technical roles across the globe. Visit our CONTRIBUTE page to learn more or submit an article.