By Simon Buddle, SMC.
There’s some sort of strange magic afoot in this here system. Mops and buckets are dividing themselves spontaneously, and that there mouse fellow has no idea how to solve the problem. Don’t put on the wizard’s hat if you don’t have the wherewithal to use it, that’s my advice.
It is often the case that faults are perceived as some kind of dark art, sent to ruin our lives, but a logical, rational and systematic approach is all it takes to help us to keep our hair and sleep well.
Back in the day when the world was flat, system fault-finding was relatively straightforward. Take the left phono lead from the record player, connect it into the right-hand input of the amplifier. If the fault moved from left to right, you knew you had it solved. If not, repeat the process on the leads from amplifier to speakers.
Systems, and particularly KNX systems, are not that simple anymore. We have hardware and software to contend with, and most likely, you’ll have equipment that has not been supplied by you but for which you have the responsibility of controlling. Then there are all of the mechanical issues which may crop up.
Keep an Open Mind
In recent times I have been witness to another KNX dealer’s meticulous fault-finding which at no point involved him connecting to the system. The client complained, during one of the coldest spells, that rooms were cold and never seemed to get warm. Clearly the heating system was at fault.
It turned out that whilst the trench heaters were pumping out heat at full blast, they were being significantly compromised by the home’s ‘listed building’ status. The perceived fault was caused as a result of the original window frames, which no longer closed fully, allowing an icy draft which, at that time of year and with their north easterly aspect, caused the room temperature to plummet to 14C. The ability of everyone to be honest and objective during the process resulted in a quick response to the problem – secondary glazing.
I’m often confronted by puzzled engineers who do think that some form of magical gremlin has entered their system, and in all but one instance, this has not been the case.
Some Logical Steps
Fault-finding is a logical process, and even if the fault could have been solved by someone less-qualified than we are, we have to be part of the process in resolving any issues. How should we go about it? There are some logical steps we can follow that will guide us towards the solution:
1. Be honest, open and objective.
2. Gather as much information as possible.
3. Understand the system from end to end.
4. Identify the fault by:
-
- a. Logical system testing end to end.
-
- b. Isolating the fault.
-
- c. Swapping out devices.
-
- d. Looking for commonality.
-
- e. Knowing your system demarcation points. Can you test each side?
- f. Identifying factors outside of the system that may have an impact.
It goes without saying that points 1 and 2 are fundamental requirements. Understanding the system may require a little more thought. It may be prudent to draw the hardware and software layers of the system if they are not already on paper. ‘The system’ also ought to be considered in terms of its input activity and output. As we’ve seen from the example above, the system worked correctly, but the result of the output was not as expected. The root cause was therefore outside of the system and certainly outside the control of the integration company, and yet as far as the client was concerned, it was the integrator’s problem.
Monitoring
How do you track down intermittent and site-specific faults? These types of fault can be pesky and require a little more focus. If possible, ask the client to report issues to you as soon as they occur. It may also be wise to put some form of data logging equipment in the premises, which could take the form of an actual bus fault logging device such as the ABB SMB/S or a HomeServer.
However, it might require in-room temperature sensors or voltmeters. If you are able to monitor remotely, that will also save on the number of trips to site. The key is to interact with the client at the time of the fault, and to have the ability to record what is happening at that time.
Conclusion
Fault finding can be a seemingly never-ending maze, but with a little logic, understanding and patience, we can establish what the root cause is and how to resolve it.
Some faults, of course, are not faults at all, but simply the client misunderstanding how a system is supposed to work. In most instances, a bit of time demonstrating and retraining the customer may be all that is needed. However, there may be circumstances that require additional work to be carried out in order to align the system with the client’s wishes.
Simon Buddle is the Technical Director of SMC – systems integration consultants and installers. Simon is also a regular contributor to KNXtoday.
