In a lifetime engaged in the study of the multitudinous technical manifestations of the One True Universal Law (Murphy's, of course), I have managed to extract a single powerful theorem for use in fault finding: It is folly to believe that similar symptoms are produced by similar faults.
Jumping to conclusions without an approved safety harness is always a risky business that can lead to serious confusion, depression and even derision from ones closest colleagues.
Thus, to find problems in a complex system requires the adoption of a systematic approach to identify the precise location of the faulty elements. The approach that I have come to favor is to eliminate all of the correctly operating components, so all that remains are the faulty bits.
I'm currently working with a client to locate an extremely intermittent and deeply mysterious problem in a multi-universe DMX512 distribution network. If what the head technician told me is correct (and I have deep reservations that this is the case), then we must arrive at the conclusion that nothing can be faulty, so the system should be working perfectly--which it manifestly is not. The only other conclusion available to me is the system is inhabited by some form of DMX ghost.
Now while the installation in question is a 170-year-old theater, and comes fully equipped with the requisite theater ghost, there is no reason, as yet, to suppose that this is the cause of the problem. I merely suspect the accuracy of some of the tests that they purport to have performed. Due to the very infrequent appearances of the fault, I haven't yet had a chance to verify the client's results. I have loaned them a DMX tester, with strict instructions as to how to test their system on the next manifestation of their rhythmic flickering problem.
There are a several popular methods for picking a starting point in your search for faults. Many people are in favor of starting at one end and methodically working your way through the system. However, as a lifelong student of Murphy, I just know that such a search will always start at the furthest possible point from the fault, and thus require much fruitless effort. On average, you will have to test about half of the system before isolating the source of the problem. A 30-component DMX system (including console, cables, splitters, dimmers fixtures, etc) should require approximately 15 tests, but could require as many as 30 if Murphy prevails.
THE BINARY SEARCH
Instead, I favor a simple, yet elegant technique, known in the data processing business as the binary search. Rather than beginning the search for faults at one end of a system and working your way through, the binary search method repeatedly divides the system in two, discarding half of the remaining system with each test, and so rapidly zooms in on the faulty components. A 30-component system will require a maximum of five tests to locate the fault, no matter what.
Selecting the right midpoint can reduce the effort of fault location considerably. If only part of your system is exhibiting a fault, then it may be appropriate to begin your search at a point after the divergence of the faulty section from the rest of the system. However, it's also important to remember that some faults caused by data reflections in incorrectly terminated or joined networks can appear a long way from the source of the reflection.
Another factor to consider is that the starting point doesn't have to be at the absolute geographic center of the network, particularly if that place happens to be up a tower, in a flown truss system or deep below a temporary stage structure. If the fault is located in such an inconvenient place, your tests will lead you there soon enough without having to rappel down from the roof or climb under the stage to make the initial couple of tests.
After choosing a convenient midpoint in your system, break the network and insert your DMX tester, in receive mode, on the controller side of the break. If the data arriving at the tester is fault-free, then you have just exonerated the upstream half of your system and know to look halfway farther down the line. If however, the data arriving exhibits faults, then it's time to move halfway back towards the controller, to repeat the process and zero in on the source of the problem.
As a further check, insert the DMX tester, in transmit mode, on the receiver side of your chosen midpoint, and send out your test data. If the fault has disappeared, then you can be sure that its source lies upstream of your test point. If not, then it's time to move halfway farther down the line to continue your search.
The process is actually much simpler than it sounds in writing. The only difficult part (aside from having to clamber around in your DMX network cabling) is using your tester correctly. It's crucial to know what you should be seeing on your tester in receive mode, and equally vital that you are sending out a useful data stream in transmit mode. If the fault only appears in certain lighting states, then clearly that is what you should be sending from both the console and the DMX tester. In most other circumstances, it is useful to either send out a single static state on all channels, or send out a simple repeating pattern that will help to identify the location of the fault.
While DMX networks can be complex and messy conglomerations of cables and equipment, some careful thought, the right test gear and the application of a few simple rules should comfortably enable you to lay to rest your network ghosts.
MOST READ
