Electronic System Controls & Communication

Electronic temperature control

An electronic controller compares a sensed temperature to a setpoint and applies a differential to prevent short cycling. Modern controllers add anti-short-cycle timers, pull-down logic, and alarm delays. Understanding those timers matters: a compressor that will not restart for several minutes is often obeying a timer, not failing.

Parameters are field-changeable and frequently changed by someone who should not have. Before diagnosing strange behaviour on commercial refrigeration, read the parameter list and compare it against the factory defaults.

• Anti-short-cycle delays commonly run 3–6 minutes — wait them out before concluding a failure
• A wide differential produces large temperature swings that read as a control fault
• Record parameters before changing them so you can return the unit to a known state

Defrost: the fault that presents as no cooling

A frosted evaporator blocks airflow, so the compartment warms while the compressor runs continuously — the classic 'not cooling but running' complaint. Defrost failures split three ways: initiation (the controller never calls), execution (heater or valve fails), and termination (the sensor or thermostat never ends the cycle correctly).

Work it in that order. Force a defrost through the controller, then confirm the heater draws current or the hot gas valve energises, then watch termination. Each stage produces a clear answer, and the pattern of frost on the coil tells you a lot before you touch anything.

• Even frost across the whole coil suggests defrost failure; frost only at the inlet suggests low charge
• Heater current is the proof of execution — voltage alone is not
• Termination sensors are the most commonly failed part of the chain

Boards that talk to each other

Many machines split control across a main board, a user interface, and one or more slave boards, connected by a serial bus. Communication faults produce codes that name a board that is perfectly healthy — the fault is in the link. Check supply and ground at each node first, then wiring, then termination where the bus requires it.

On networked commercial systems, the site controller adds another layer: schedules, setpoints, and alarms may be coming from a supervisory system rather than the local controller. Establish who owns the setpoint before you spend an hour chasing local behaviour.

• A communication code implicates the link and both nodes, not just the named board
• Shared ground problems between boards produce intermittent comms errors
• On networked sites, confirm whether the setpoint is local or supervisory

Boards talk over a handful of physical layers — know which one you're on

Modern appliances distribute intelligence across two, three, or more boards, and those boards have to agree on what is happening before anything runs. The link between them is rarely a mystery once you look at the wiring: a simple two-wire serial link (often called a communication bus, LIN-style, or a proprietary two-wire protocol) is common between a main board and a user interface or a secondary board; a differential twisted pair, behaving like a CAN bus, shows up on more sophisticated platforms and commercial equipment where several nodes share one line; and some systems still ride commands over the AC supply conductors themselves, a powerline-style link, which looks like ordinary wiring but carries a modulated signal on top of the mains.

None of these are diagnosed by continuity alone. A wire that measures continuous end to end can still be carrying no valid signal, and a bus with correct voltage levels but the wrong data rate looks identical to an open wire on a meter. The practical skill is recognising the topology — how many nodes, which one is the master, which wires are shared — before you decide what a fault on that bus actually means.

Termination and bias also matter on multi-node buses. A CAN-style bus expects a resistive termination at each physical end; add or remove a board without respecting that, and the whole bus can degrade even though every individual board tests fine in isolation.

• Two-wire serial link: point-to-point, usually main board to UI or to a secondary controller
• Differential twisted pair (CAN-style): multiple nodes share one bus, terminated at each end
• Powerline-style link: signal riding on the AC or DC supply conductors rather than a dedicated data pair
• Correct wire continuity does not prove a valid signal — measure or observe the data, not just the copper

Never join or extend a communication pair with generic low-voltage wire spliced in without checking impedance and length limits; it is enough to turn a marginal bus into a failed one.

A communication fault names the path, not necessarily the part at the far end

A board that stops hearing from another node has exactly one honest report available to it: 'communication error.' That message tells you the conversation stopped. It does not tell you which of the two parties stopped talking, or whether the wire between them is the actual problem. Technicians who read a communication code as 'replace the board it names' are guessing, and the guess is wrong often enough to matter.

The discipline is to work outward from the fault rather than jumping to either end. Confirm both boards are powered and that their own local supplies are within range, confirm the physical link with the machine de-energised and then re-energised, and where the platform allows it, look at whether one node is transmitting and the other simply is not responding, or whether nothing is moving on the bus at all. A board that has genuinely failed usually shows other symptoms alongside the comm fault — a dead output, a dark display, a relay that never clicks — while a lost conversation with two otherwise healthy boards points at the path between them or at a shared rail.

Distributed control adds a wrinkle: on a machine with a main board, an inverter or motor-control board, and a user interface, any one of the three can be the node that dropped out, and the fault code is often generated by whichever board noticed the silence first — which is not necessarily the board that caused it.

• A comm fault names a broken conversation, not a confirmed faulty part
• Check for other independent symptoms on the accused board before condemning it
• On a three-node system, the board reporting the fault is often the listener, not the one that went silent

Shared rails, EMI, and mismatched firmware — the usual suspects behind 'it won't communicate'

The single most common physical cause of an intermittent or permanent communication fault is not the data pair itself — it is the supply and ground the two boards share. If one board's low-voltage rail sags under load, or if the ground reference between two boards separated by a long harness run has drifted due to a poor connector or a corroded splice, the data signal riding on top of that reference degrades even though the signal wires themselves are intact. Measure the supply at both ends of the link under load before you condemn the data pair.

Noise is the second suspect, and it has grown more relevant as inverter-driven compressors and motors have become standard. A variable-frequency drive switching at several kilohertz radiates electrical noise, and a communication cable routed alongside motor leads or near the drive's heatsink can pick up enough of it to corrupt data intermittently — a fault that appears under load or at certain speeds and disappears at idle is a strong tell. Correct routing, shielding, and grounding of the drive are the fix, not a new board.

The third suspect is configuration rather than hardware at all. A replacement board that has not been told what model, capacity, or feature set it is controlling can fail to establish communication with the rest of the system even though every wire and voltage is correct, because the two sides are speaking the same physical language but disagreeing about the data itself. This is where pairing, learning, and configuration procedures earn their place in the job — skip them, and a perfectly good replacement board looks like a wiring fault.

• Measure supply and ground at both ends of the link under load, not just at rest
• Suspect EMI when the fault correlates with drive speed or motor load rather than being constant
• A brand-new, correctly wired board that won't communicate may simply be unconfigured or unpaired

Route and dress replacement harnesses the way the original was routed. A comm cable rerouted near a drive or a motor lead is a self-inflicted noise fault that will pass every static test and fail on the customer's floor.

Failure modes and what confirms them

Test procedures

Manufacturer differences

Safety and professional boundaries

• Communication circuits are low voltage but frequently share a board and a harness with line-voltage sections — verify what you are probing before you probe it.
• Do not defeat interlocks or bypass safety-related communication faults to force a machine to run for testing; some communication faults exist specifically to stop unsafe operation.
• Powerline-style communication rides on conductors that also carry line voltage — treat the entire circuit as line voltage for safety purposes even when reading a low-level signal on it.

Expected readings and what they mean

Field scenarios

Knowledge check