Posts
True story. My wife teaches spin classes at a local gym, and
the other day I went to her class. Before class she was struggling with the
computer that runs the audio and scheduling in the room. She couldn’t get it to
work, so I thought I would help. The computer is a NUC-type, about six inches
long by about four inches wide and inch deep, and it was mounted to the back of
the equipment rack. All of the cables, both power and data, were routed through
the locked rack, concealing their path. The monitor had an error message saying
that it was not receiving a video signal. So I disconnected and reconnected the
video cable at the monitor and at the computer, but the same error message
appeared. Then I disconnected reconnected the power cable at the computer,
thinking that resetting it might help. Again, the same error message appeared
on the monitor. It must be a bad video cable, I thought. It was frustrating not
being able to get into the rack to get a better look, and I was at a loss about
what else I could do. I almost gave up. About that time, the manager of the gym
came along and pushed a button on the computer and it came to life. It turned
out that the On/Off switch was in the Off position.
The first rule of troubleshooting is to check the obvious
things first. Bill Byrd used to be a technician at High End Systems. He started
there shortly after serving as a tech in the Air Force. That’s where, he said,
he picked up the first rule of troubleshooting. “Is the O-N/O-F-F switch in the
O-N position?” That was his favorite line.
Another good practice while troubleshooting is to take
pictures as you go so that you can reference them when it’s time to put things
back together. We used to have to write everything down but now with smart
phone cameras, it’s much quicker and easier to take pictures.
One last tip is to write down your steps as you go so that you never
have to repeat your work. Last month I was troubleshooting a complicated
lighting network at a major television studio. (Look for the article about it
in the Winter 2018 issue of Protocol magazine.) We had run a temporary Ethernet
cable to a network switch in a computer closet, so we had two cables – the main
and the temporary. The system worked fine on the temporary cable but there were
problems with the main cable. I wanted to rule out the cable itself, so we tested the system in four different conditions; one with the main cable
connected to the main port in the switch, one with the temporary cable
connected to another port in the same switch, one with the main cable connected
to a different port in the switch, and the last with the temporary cable
connected to the main port in the switch. So I quickly drew a table with four
rows and labeled them 1 through 4. As we conducted the test, I would write down
the results.
I’ve learned over the years that even a simple test like
this can be interrupted or you can lose track of which combinations have
already been tried. So writing it down saves time and effort. This is a
technique that I learned from reading about Leonardo da Vinci, who was said to
document everything his did in excruciating detail. It takes longer but in the
end, it saves time.
There is a lot more to troubleshooting, and as you gain
experience you will develop your own techniques. But in the meanwhile, focus on
the simple solutions first, take lots of pictures, and document your work.
