GOTECH CAN SERIES · PART 1 OF 3

CAN bus communication explained

Let's start with what the modules are sharing. Then we'll follow the scan-tool path and see why one module answering doesn't clear the whole vehicle.

Original video · 33:443 reasoning checks

START HERE

What are the modules sharing?

Think about coolant temperature. The engine computer needs it to manage the engine; the instrument cluster needs it for the gauge. In the video's example, the engine computer shares the information over the network instead of each module needing its own sensor.

Now add more modules and separate networks. A gateway lets those networks exchange information. The diagnostic connector, or DLC, may lead to that gateway rather than directly to the branch you're interested in.

That's why we follow the path first. A successful scan-tool conversation tells us something about that path. It doesn't tell us that every other branch is working.

Watch the information-sharing example · 04:00

GoTech Tips

CORE GOTECH TIP · FROM THIS LESSON

Follow the path that answered.

A module answered. Good—now point to the path it used. We still need to look at the branch involved in the complaint.

Compare the paths →
More GoTech tips · 2

CONCEPTUAL EXAMPLE — NOT A VEHICLE WIRING DIAGRAM

One responding module does not clear every branch

Lines show communication relationships, not conductors. The response establishes enough operation for that exchange—not complete health of every item on the path.

Read the diagram in words

A scan tool connects through the DLC and a gateway to two conceptual branches. Module A responds over Path A, shown with solid lines. Path B to Module B is dashed: its condition is not established by that response.

Try the idea with a third branch →

PRACTICE IT

Try one before you move on

Make your choice, then compare it with the explanation.

0 of 3 questions compared

QUESTION 01A scan tool reaches a gateway. Modules A and C answer on separate branches; B doesn't. What have we established?
Read the full explanation
The gateway is cleared, so the fault must be in B or its branch.

Two responses do not clear every gateway function or every relationship to B. That conclusion narrows the problem farther than the observation supports.

A and C exchanged messages. B's path and the cause of its silence still need checking.

Yes. Apply the solid-path idea to both observed exchanges. Adding another responding branch still does not establish the unobserved path to B or identify why B did not respond.

B shares the scan connection, so its silence proves B is faulty.

A shared access point does not make the downstream branches equivalent. The result does not distinguish B’s branch, its module or other applicable conditions.

Continue to the other two questions →

FROM THE ORIGINAL LESSON

Find the network involved in the complaint

Where should CAN bus diagnosis start?

Start with the modules involved in the complaint. Find their communication network and physical connections on the diagram, then identify the protocol before choosing a test. A whole-vehicle diagram includes branches that may have nothing to do with the fault.

Check your thinking

Name the communication question first: which module needs to talk to which other part of the system?

Why can a scan tool communicate while another network has a fault?

In the gateway arrangement shown here, the diagnostic connector reaches the gateway through its own branch. A good result there does not clear the downstream networks. A module may still answer the scan tool through one path while its communication with other modules is affected.

Check your thinking

What did the reported DLC reading establish about its own location? What did it leave unknown about the affected branch?

Escalade: narrow the diagram to the noncommunicating module

The Escalade’s fuel-pump driver module still would not communicate after replacement. With power and ground checks reported, GoTech followed its communication wiring and excluded diesel-option branches that did not apply. That smaller search area led to reported rodent damage.

Check your thinking

Which facts let him cross parts of the diagram out, and which facts would be unsafe to assume on another vehicle?

Acadia: connect the warning light to the no-start

On the 2013 Acadia, intermittent no-start, interrupted interior lights and a blank dash accompanied an object-detection warning. The network diagram connected the low-speed communication problem to the key-reading dependency. GoTech reports corrosion at an object-detection module and a return of operation during isolation.

Check your thinking

Why did the object-detection warning deserve a place in the explanation of the no-start?

Can you use the same diagnosis on a newer vehicle?

The later Acadia had a similar object-detection warning but a different network arrangement. Object detection and immobilizer functions were separated differently, so the older vehicle’s no-start explanation did not carry over. Check the applicable diagram before reusing a familiar diagnosis.

Check your thinking

What would need to match before you could reuse the older case's reasoning?

Keep this example in scope The Escalade and Acadia stories are the instructor's reported cases. Their exact diagrams, options, connector details and lasting repair outcomes are not independently verified here. The companion teaches the reasoning without prescribing module disconnection or a replacement.

PUT IT TO WORK

Two more questions

Use the case details above. Pick an answer, then check the reasoning.

QUESTION 02Why was the persistent object-detection warning useful in the 2013 Acadia story?
Read the full explanation
Its persistence located the failed component within the no-start path.

Persistence made it a useful lead. The network relationship and further investigation still mattered.

It could be treated separately because it remained present between the intermittent no-start events.

The source revisits that separation after considering the shared communication problem and symptom pattern.

It helped select a lead within the affected network after the symptoms were considered together.

Yes. Its value came from the case's symptom pattern and network relationship, not from the warning text alone.

QUESTION 03A newer vehicle has a familiar warning but lacks the older case's other symptoms. What is the best learning takeaway?
Read the full explanation
Check the actual network and equipment relationships before carrying over the old explanation.

Yes. Experience suggests a question; the applicable diagram determines whether the old relationship still holds.

Use the earlier explanation as the working layout until a new test result contradicts it.

That carries an unverified architecture into the interpretation. The later Acadia example changes the relevant relationships.

Use the missing symptoms to exclude the object-detection network before consulting its layout.

Different network separation can change the consequences. The symptom difference alone does not establish the layout or exclude a branch.

FROM THE ORIGINAL LESSON

Watch the original GoTech video

33:44

The original lesson demonstrates this reasoning through the instructor's Escalade and Acadia network cases. Each story keeps its own equipment and communication relationships.

Original GoTech lesson thumbnail

Video loads only when you choose to play.

YouTube connects only when you choose to play.
Watch on YouTube ↗ · CAN Bus Communication Explained (Part 1)

Watch the full video, or use the timestamp links beside each explanation to jump to that moment.

KEEP THIS

A module answered. Follow the path it used, then check the branch involved in the complaint.

Explain it back · optional

This note stays in this open page. It is not sent, graded or saved; copy it before leaving if you want to keep it.

Review your explanation
  • Did I name the source example and the relevant conditions?
  • Did I separate the observation from my interpretation?
  • Did I say what the evidence still does not establish?
Study sheet · read or print

GOTECH · CAN PART 1 OF 3 · STUDY SHEET

CAN bus communication explained

A module answered. Good—now follow the path it used. We still need to look at the branch involved in the complaint.

Follow the response path. One responding module does not clear every branch.

Three GoTech tips

  1. Follow the path that answered. Find the scan connection, gateway and responding module on the diagram. Keep that result attached to that path.
  2. Make the diagram smaller. Start with the modules involved in the complaint. Check the vehicle's equipment so unrelated branches don't send you the wrong way.
  3. Check the layout again on the next vehicle. A familiar warning doesn't guarantee the same network or the same cause.

The Escalade example

What GoTech reports
The fuel-pump driver module still would not communicate after replacement. Power and ground checks were reported.
What narrowed the search
Following the applicable communication wiring—and excluding diesel-option branches—led to reported rodent damage.

What this does not establish

A scan response does not establish that every branch is healthy. This reported case does not independently verify your vehicle's wiring, connector details or a lasting repair.

Your working notes

Which modules answer, and which do not?

Which path or branch would you identify next?

Go back to the source

Lesson: https://gotech.com/learn/can-bus/communication-and-context/

Written from GoTech's original video; these notes paraphrase the explanation. Technician review and independent verification of source diagrams remain pending.

Next: see what the wiring changes

In Part 2, we'll look at what a disconnection changes besides the module you unplugged.

Mark studied & continue →

Saves your place on this device. Your answers and written note are not saved.

Work through the concept with Ask GoTech →
Source, scope & review

GoTech’s written companion to the original demonstration. Source moments support the case observations; the learning prompts are GoTech editorial guidance.

The Escalade and Acadia stories are the instructor's reported cases. Their exact diagrams, options, connector details and lasting repair outcomes are not independently verified here. The companion teaches the reasoning without prescribing module disconnection or a replacement.

Timestamp links identify supporting passages. They do not independently verify every source diagram or establish a procedure for another vehicle.

Additional source moments
Learning goals and the GoTech way of thinking

Use these prompts when you want to slow down and work through the reasoning.

By the end of this lesson

  • Distinguish the scan-tool access path from the network involved in a complaint.
  • Explain how vehicle options and symptom patterns narrow the source cases.
  • Recognize when experience with an older vehicle becomes an assumption about a newer one.

Before you startRecognize a module, scan tool and wiring diagram. Need a refresher? Start with wiring diagrams.

This lesson’s focus

Before interpreting a communication result, identify which network, branch and access path the evidence actually represents. Keep the vehicle's equipment in that picture.

The GoTech way of thinking · 6 steps

WAY OF THINKING

The GoTech way of thinking

01Define the questionPrimary focus

What are we actually trying to establish?

02Map the systemPrimary focus

What components, circuits, networks or relationships matter?

03Observation ≠ conclusion

What did we actually observe, and what are we inferring?

04Find the evidence boundary

What does this measurement, source or test establish, and what remains unknown?

05Choose the next check

What additional evidence would reduce uncertainty the most? Choose a check that helps distinguish the remaining explanations.

06Stop where the evidence stops

Do not turn a plausible explanation into a confirmed fact.

Did this help you move forward?

Optional. No written response is collected.