How to Troubleshoot an AV Control System
Is it the code or the cables? Did the user change something in the system that’s causing errors? AV pros offer up advice on pinpointing control system issues.
You’re better off if you don’t have to troubleshoot a control system at all. So to the extent you can stage an integrated system at your facility—maybe invite the user over to give it a spinthe better off you’ll be. But this is technology and stuff happens. We asked AV integrators what their troubleshooting checklists look like.
Try breaking it first. A couple integrators say they invite co-workers to mess with the system and any peripherals it might control in order to simulate possible user-error scenarios.
Grill the customer (nicely). What was the last thing they did or changed before the system stopped working properly? Did they swap out an older AV device and replace it with a new model that might need a firmware update to support full bidirectional communication or some other capability of your control system design?
Disconnect the control system. Use a laptop and HyperTerminal software to send commands to AV devices via serial or TCP/IP connections. If you’re not getting a response back from something like a projector, at least you know it’s probably not the control system.
Follow the cables. Depending on who you talk to (programmers sometimes blame malfunctions on cables and installers blame them on code), incorrectly terminated cables can account for half of control system issues. Test cables as you do the installation so you can rule them out later. And carry pre-terminated cables to help troubleshoot.
Consider power issues. As one AV pro put it, “You’d be surprised how many systems we walk into and the integrator has underpowered or overpowered the voltage via Cresnet, Netlinx, etc.”Debug the code. If you’ve commissioned the system, this shouldn’t be a problem, but use the debugging tools that come with systems from companies such as AMX and Crestron to pinpoint any issues in the control code. And when you write code, do it in a way that clearly delineates, for example, user interface from communications code so you can tell when errors are occuring. And slip identifiers into the code, such as a “printf” statement when C programming, to leave markers so that you know which stretches of code are functioning correctly.
Thanks to Boone Oshel, systems and applications manager at Mechdyne Corp. (www.mechdyne.com), for his guidance.
