A protocol name is not an integration guarantee.

“Supports CAN” is only the first layer

A complete communication record starts with the electrical layer: voltage levels, transceiver, isolation, termination, connector and topology. It then identifies the frame protocol, addressing, bitrate, payload definition, device profile, control modes, state machine, diagnostics and configuration tool.

Two actuators can both expose CAN while using unrelated command formats. A CANopen device may implement a standard profile, a vendor extension or only part of the expected object dictionary. The same distinction applies to Ethernet: a 100 Mbps link does not identify the real-time application protocol running above it.

Common joint-network families

The following descriptions are system boundaries, not endorsements or equivalence claims.

• EtherCAT uses an Ethernet physical layer with a distributed-clock mechanism and a conformance ecosystem; device profile and implementation still matter.
• CAN and CAN FD define bus transport characteristics; CANopen and other profiles add device semantics. Proprietary CAN command sets remain common in compact actuators.
• RS-485 defines an electrical signaling layer. Products such as some DYNAMIXEL variants run a vendor packet protocol over half-duplex RS-485.
• Standard Ethernet can carry vendor APIs, UDP/TCP control or real-time protocols. HEBI’s actuator family uses networked APIs over its published Ethernet/optical interface.

Real-time behavior requires timing evidence

Control-loop quality depends on command and feedback latency, jitter, update rate, clock synchronization, bus load, error recovery and host scheduling. A nominal bitrate cannot predict all of these. The record should distinguish an actuator’s internal control loop from the external command loop.

For multi-joint robots, timestamp origin and synchronization method are especially important. Distributed clocks, PTP, hardware triggers and host timestamps solve different parts of the timing problem. RCI does not infer synchronization quality from a connector or protocol logo.

Evidence ladder for a compatibility claim

The strongest public record progresses from a protocol mention to an exact implementation and then to a verified combination.

• Manufacturer manual names the interface, version, bitrate and command/profile document.
• Electronic data sheet, object dictionary or machine-readable device description is available.
• Conformance listing or test report identifies the exact model and revision.
• Host, master, firmware and configuration are documented in a deployed BOM or reproducible test.
• Failure behavior, watchdog, safe state and recovery are tested under load.