CAN bus diagnostic communication is the way a scan tool exchanges requests and answers with a vehicle’s computers over the controller area network, the protocol required for OBD-II on US cars and light trucks from model year 2008. It is the method most owners meet today.
This guide explains what the CAN bus is, how diagnostic messages travel across it, why several modules can reply to a single request, and what this means when you use a basic scan tool. Diagnosing network trouble codes is covered in a separate article.
A Shared Network Instead of Separate Wires
Older vehicles often ran a dedicated wire for each signal. As electronics multiplied, that approach became heavy, complex, and difficult to service. The controller area network, or CAN, replaced much of that wiring with a shared two-wire network that many computers use together.
Each computer on the network is called a module or node. The engine computer, transmission computer, ABS module, instrument cluster, and body controller can all exchange information over the same pair of wires, taking turns according to message priority rather than talking over one another.
For diagnostics, this means a scan tool plugged into the OBD-II port joins the network as one more participant. It can send requests and listen for answers in the same way the vehicle’s own modules communicate with each other during normal driving.
The Two Wires at the Diagnostic Port
On the SAE J1962 diagnostic connector, CAN high uses pin 6 and CAN low uses pin 14. The two wires are usually twisted together along their length, which helps protect the signal from electrical noise produced by ignition systems, motors, and other components.
CAN uses a differential signal. Instead of reading one wire against ground, each module compares the two wires against each other. Interference that affects both wires equally tends to cancel out, which makes the network dependable in an electrically noisy vehicle.
Because both wires carry the message together, damage to either one can disrupt communication. A chafed harness, corroded connector, or water intrusion at a module may cause intermittent faults or prevent a scan tool from reaching some systems while others still respond normally.
How a Diagnostic Request Travels
When you ask a scan tool for stored codes, it builds a request according to the OBD-II rules for CAN, defined in ISO 15765-4. That request moves across the network as a short message with an identifier showing who it is meant for and how urgent it is.
Broadcast Requests
For generic OBD-II services, the scan tool usually sends a functional request. This works like a question addressed to every emissions-related module at once. Any module that holds the requested information answers, and the tool gathers those replies.
This explains why some tools show codes labeled with different module names or numbers after one scan. The engine computer and transmission computer may each have answered the same question.
Direct Requests
A scan tool can also send a physical request aimed at one specific module. Enhanced diagnostics, such as reading airbag or body module codes, typically rely on this approach and on manufacturer-defined messages.
Basic code readers mostly stick to broadcast requests for generic data, while professional scanners use direct requests to reach individual modules in greater detail.
Long Messages in Pieces
Individual CAN frames carry only a small amount of data. Longer answers, such as a vehicle identification number or a long list of codes, are split into several frames and reassembled by the tool. The ISO 15765 standard defines how that splitting and rebuilding works.
You never see this process on the screen. It matters only because an interrupted connection, such as a loose plug, can cut a long reply short and produce incomplete results.
Why Message Priority Matters
On a CAN network, every message carries an identifier that also sets its priority. When two modules start transmitting at the same moment, the higher-priority message continues and the other module waits, then tries again. Nothing is lost, and no central controller is needed.
Safety-critical and powertrain messages typically receive high priority, so they move without delay. Diagnostic requests from a scan tool are designed to fit around normal traffic, which is why reading codes does not disrupt engine operation on a healthy network.
Understanding priority is mostly background knowledge for owners. Its practical value is explaining why a network fault can affect several systems at once.
This arrangement also explains why a single faulty module can upset the whole network. A module that transmits constantly or corrupts messages can crowd out others, leading to multiple communication faults and warning lights that seem unrelated to each other.
Gateways and Multiple Networks
Many modern vehicles contain more than one CAN network. A high-speed network may link powertrain and chassis modules, while a separate network serves body and comfort functions. Some vehicles also use other network types for entertainment or lighting.
A gateway module connects these networks and passes selected messages between them. On many vehicles the diagnostic port connects to the gateway or to one primary network, and the gateway forwards scan tool requests to modules elsewhere in the vehicle.
Some newer vehicles use a security gateway that limits what an unauthorized tool can do. Reading generic emissions data remains available, but certain functions, such as programming or resets, may require a registered tool and credentials. This is a manufacturer design decision, not a defect.
What a Basic Tool Can Read Over CAN
Even an inexpensive code reader can access a useful amount of information on a CAN-equipped vehicle. The OBD-II standard guarantees access to emissions-related data no matter which brand built the vehicle.
- Stored and pending emissions-related codes, plus permanent codes where supported.
- Readiness monitor status for emissions inspections.
- Freeze frame data captured when a code was set.
- Live data such as engine speed, coolant temperature, and fuel trims.
- Vehicle information such as the VIN on supported models.
These functions cover most check engine light diagnosis. What a basic tool usually cannot do is reach body, chassis, and safety modules using manufacturer messages.
That limitation reflects the tool’s software, not the network. The data travels on the same wires, but a basic tool simply does not know how to request it.
Signs of a CAN Communication Problem
Network faults often show themselves through clusters of symptoms rather than one clear failure. Typical signs include the following.
- Several unrelated warning lights appearing at the same moment.
- Gauges that drop to zero briefly or behave erratically.
- A scan tool that reaches some modules while others never respond.
- Features that work one day and fail the next, often in wet weather.
Network problems frequently set U codes, the trouble code family for network communication. These codes indicate that a module lost contact with another or received invalid data. They point toward the network or a module’s power supply, not necessarily the component named in the description.
If you suspect a network fault, record which modules respond and which do not, along with the codes stored in each. That information helps a technician narrow down the problem area before any connectors are disturbed or modules replaced.
Safe Habits When Working Near the Network
CAN wiring is sensitive to poor repairs. Never pierce the insulation with a test light, splice in accessories, or connect devices that were not designed for automotive networks. A single bad connection can introduce faults that are very difficult to locate later.
Keep the battery in good condition and avoid disconnecting it during a scan. Low voltage can cause modules to drop off the network or set communication codes that disappear once proper voltage returns, which leads to confusing results.
Network testing with an oscilloscope or breakout box belongs to technicians who have the correct service information and equipment. For an owner, the safest contributions are a visual inspection, a clean scan with a quality tool, and careful notes about when the symptoms appear.
Common Myths About CAN Diagnostics
One common myth is that any CAN-capable tool can access everything on a modern vehicle. In reality, generic OBD-II access covers emissions-related information, while full module access depends on manufacturer software, subscriptions, and sometimes security credentials.
Another myth is that a U code always means a failed module. Many network faults trace back to wiring, connectors, low battery voltage, or a blown fuse feeding a module. Replacing an expensive module without testing its power, ground, and network connections often leaves the original problem in place.
Some owners also believe that leaving a wireless adapter plugged into the port is harmless. These devices draw power and transmit on the network. Unplug them when not in use and remove them first whenever communication problems appear.
A last myth is that clearing network codes fixes the problem. If the underlying wiring or power issue remains, the codes simply return during the next drive.
Getting More From Your Next CAN Scan
Before scanning, make sure the battery is healthy and the ignition is on. Allow the tool to finish its protocol detection, then save or photograph the full list of codes and the modules that reported them before clearing anything.
Look for patterns. Several modules reporting lost communication with the same partner suggest that partner, its power supply, or its wiring deserves attention. A single module with a single code is usually a more focused diagnosis.
Use the codes as directions for testing, not as a shopping list for parts. When the evidence points toward network wiring or module faults, a qualified technician with manufacturer service information and network testing tools is the most efficient route to an accurate repair.