Skip to content

Troubleshooting: “Why Does it Do That?”

Share this Post:

Most manufacturers have comprehensive QC procedures to keep mid-show malfunctions to a minimum. Photo courtesy Robe

I was watching one of those popular prime-time TV game shows recently and noticed a small problem with one of their moving lights. As the contestant answered the question, all the fixtures tilted up from the floor to the ceiling in a synchronized sweep. However, I noticed that the fixture on the stage-right end moved much slower than all the others.

Most viewers probably never thought twice about this, but my mind instantly went through the troubleshooting routine I would use to solve the problem. The first course of action is to determine where the problem is coming from. Usually it is from one of three areas: the fixture, the system, or the programming. Every programmer should know the basics of troubleshooting problems such as this, but many just don’t have the experience to explore all the possibilities. The following describes how to approach this particular problem, but the concepts can be applied to any unusual reaction of a moving light.

‡‡         Initial Setup

Generally speaking, when you first connect your fixtures to your desk, you can immediately find many common problems. For instance, if a fixture is not addressed to match your patch (or plugged into the wrong universe), it will be immediately apparent. The fixture will be uncontrollable and possibly doing its own thing. Alternately, it might behave just like another fixture, but not respond to commands directly sent to it.

The initial setup and testing period will rule out larger problems with your patch, DMX cables, network system, lighting fixture health, and more. You should always spend a few minutes when you first connect a rig to confirm that each and every fixture is behaving as expected on all functions. Most programmers will take the time to check gobos, colors, pan/tilt and other features before beginning to program. However, it is very difficult to find all faults, and some develop at a later time. Furthermore, the actual programming can lead to unexpected results.

‡‡         Check the Fixture

When you discover that a fixture is behaving different than the others, you should check the actual fixture for problems. Although most manufacturers have exhaustive QC procedures in place, the very mechanics of a fixture can fail and lead to improper functionality. The fixture that moved slowly on the television show could have had a bad belt or motor on its tilt drive, causing it to move slowly. Or perhaps the software version was not the same as the other fixtures in the rig. I have even seen cases where something falls onto the fixture causing it to drag and move poorly.

It is also possible that the fixture had a mode setting that changed the speed of the pan/tilt movement. Many manufacturers offer slow and fast movement modes. Some can be enabled via DMX while others are only selectable in the fixture’s menu. Hopefully, this would have been caught during pre-programming testing, but the programmer may not have looked for it. Maybe the crew swapped the unit out for another reason and the replacement was in the wrong mode. All fixtures in the rig should be set to the same mode. For best results always ask for fixtures to be set to their defaults and then make changes as needed (typically from the desk).

‡‡         Check the System

Our lighting fixtures are always listening for commands and rely on the system supplying the data. This could include DMX cables, network infrastructure, or wireless devices. At any point along the chain there could be breaks or corruption that cause fixtures to misbehave. When troubleshooting errant data problems, it is always best to test a direct connection to the affected fixture (either from the desk or a DMX tester). This will eliminate all the possible problems in between. If all is good, then you can start to diagnose the problem one piece at a time.

I have seen DMX cables go bad, fixtures not pass data correctly, networks fail, and lack of termination cause terrible and confusing damage to lighting rigs. A programmer should understand the data path and be ready to assist the crew in finding problems. Again, stepping through the data flow is the best way to find the problem. Many will unplug everything and then slowly reconnect until the problem appears.

Furthermore, it could be a problem with your console software. Perhaps there is a bug that is causing one fixture to move slower than the rest in certain conditions. Be sure to check for the latest software and read the release notes to see if there is a fix for the specific problem. Always use caution when upgrading console software and ensure you understand the risks.

‡‡         Check the Programming

I saved the best for last, but this is really where you should start your troubleshooting, as most problems occur due to programming errors. If one or two fixtures are behaving different than others, the first thing you should check is your own data. Look in the output window or cue contents to see if there are any differences between these fixtures and the rest. Next, I suggest that you change the address of a bad fixture to match a known good fixture, and vise-versa. If the problem follows the address, then it is likely programming related.

It is also a good idea to try testing the errant function live in your programmer or with an entirely new cuelist/sequence. This will eliminate any accidental tracking and help to prove that the problem exists within a particular cuelist.

Remember that programming errors could occur many cues before the actual problem is seen on stage. Perhaps you accidently enabled a pan/tilt speed setting in cue seven, but did not move the fixture until cue 22. Once you see the fixture move slowly in cue #22, you will think the problem just happened there. Actually, you will have to go through your data to find where this value was accidently entered so that you can remove it from the cue.

‡‡         Humility is Your Friend

When you discover a problem with fixtures, always check first to see if the problem is with your programming or console setup. Too often I see programmers who are quick to call to the crew to fix or swap a bad unit, only to find the problem still exists. You don’t want to have guys in harnesses changing fixtures just because you accidently closed the dimmer in a particular cue. Work with your crew to see where the problem lies. Sometimes I will tell them that a fixture is acting odd, but then say I am looking for the problem. If I discover it was on my end, I am happy to report that I found the problem and corrected it. If indeed I have ruled out the programming, then I can provide them with more information that helps them to troubleshoot the problem to determine if it is in the system or fixture.

‡‡         Problems are Going to Happen

Every show is going to encounter problems of some sort with fixtures, systems, or programming. A good lighting programmer should understand the basics of troubleshooting and work with the team to quickly find and resolve any problems. Hopefully, the problem can be found and rectified quickly enough to keep techs from doing unnecessary work. Troubleshooting skills are best learned through experience, so just remember the basics here and always be prepared. If all else fails, be sure to ask for assistance from your crew and from the console and fixture support teams. Within no time, you can have your misbehaving fixtures working correctly.