CAN Is a Bus, Not Magic

A CAN network lets multiple devices share a communication bus. That architecture reduces dedicated wiring, but it also creates shared dependencies.

Understanding those dependencies makes CAN troubleshooting much less mysterious.

Think topology first

A simplified chain might look like:

controller
  ↕
motor controller A
  ↕
motor controller B
  ↕
motor controller C
  ↕
sensor/device D

Actual physical wiring can vary by legal device and topology guidance, but the important idea is that communication depends on a healthy bus.

Each device also needs a unique identity/configuration that matches what robot software expects.

What travels on the bus?

Depending on the device, CAN can carry:

• commands;
• configuration;
• sensor values;
• status;
• faults;
• current/voltage/temperature telemetry;
• device discovery information.

The bus is not the motor-power path. A controller can be electrically powered and still fail to communicate.

Pattern recognition beats guessing

Suppose devices A and B are visible, while C and D disappear together.

That pattern suggests inspecting the shared path around the transition from B toward C before replacing C and D independently.

Now suppose C is missing but D remains visible. The hypothesis changes.

Topology produces evidence.

Device IDs

If two devices are configured with the same identifier when unique IDs are expected, software may not be able to address them correctly.

A good electrical map records:

The exact device configuration tool depends on vendor hardware. The architecture does not.

Completed fault analysis

Symptom:

An intake motor controller shows power but robot code reports it unavailable.

Do not jump directly to firmware or replacement.

Check:

1. Is the device actually on the intended bus?
2. Is the CAN path physically continuous?
3. Does the device ID match software/configuration?
4. Are there duplicate IDs?
5. Do neighboring devices remain visible?
6. Does the vendor diagnostic tool report a fault?
7. Is the problem intermittent when the harness moves?

Each answer changes the next step.

Make your CAN map

Add the control devices from your selected robot to a bus map.

Mark:

• controller;
• device names;
• device IDs if known;
• subsystem ownership;
• physical order or branch relationship;
• termination/end points according to the hardware design you are documenting;
• one connector failure that could affect multiple devices.

If you do not have a robot, build the map from a hypothetical four-motor drivetrain plus intake and elevator.

Limitation: online does not mean correct

A device can be online and still have the wrong configuration, inverted direction, incorrect sensor units, bad current limits, or a mechanical problem downstream.

CAN visibility answers one question: can this device participate in communication?

It does not certify the whole mechanism.