Quick answer: Evaluate EtherCAT when your design needs coordinated timing across many drives and the exact actuators support it. Evaluate CANopen when your controller, devices and measured traffic budget meet the required update rate. A CAN port alone proves neither CANopen nor CAN FD support. There is no universal joint-count or control-frequency threshold that selects the protocol for you.
Updated September 18, 2026. Network capability and a particular ZHR model's supported interface are separate questions.
1. Compare the network, device profile and actual implementation
| Option | What it specifies | What to verify before selection |
|---|---|---|
| EtherCAT | Industrial Ethernet communication with distributed-clock support | Exact drive support, ESI file, process data, supported control modes and synchronization behavior |
| CANopen CC | Higher-layer protocols and device profiles over Classical CAN | EDS, object dictionary, PDO mapping, heartbeat, SYNC behavior and drive-profile implementation |
| Proprietary CAN | A manufacturer's own messages on a CAN network | Frame IDs, payload encoding, scaling, update rates and fault handling |
| CAN FD / CANopen FD | CAN FD is a CAN data-link option; CANopen FD is a higher-layer system built on it | Controller, transceiver, device firmware and application-protocol compatibility throughout the network |
2. EtherCAT: evaluate coordinated timing
EtherCAT distributed clocks provide a common time reference for participating devices. This supports coordinated sampling and output updates. Network timing does not automatically equal the actuator's torque-control bandwidth: the controller task, process-data schedule and drive firmware also matter. See the EtherCAT Technology Group technology overview.
For a candidate drive, request the supported cycle times, operating modes, process-data map and clock configuration. Test worst-case command-to-feedback delay, jitter and missed cycles with the intended master and complete axis count. A gateway adds another processing and timing boundary; it does not make a CAN actuator a native EtherCAT drive.
3. CANopen: validate the traffic budget
CiA distinguishes CANopen CC over Classical CAN from CANopen FD. CANopen CC specifies configurable rates from 10 to 1000 kbit/s, plus communication services and profiles. These link rates do not establish a particular multi-axis cycle time. See CAN in Automation's CANopen overview.
Check whether CiA 402 is actually implemented, which modes are supported and how PDOs are mapped. Include command, feedback, synchronization, heartbeat and diagnostic traffic. Account for frame overhead, bit stuffing, arbitration, errors and retransmissions. Leave capacity for the behavior you require under faults.
A payload-only lower bound — not a tested network benchmark
Assume 6 joints, one 8-byte command and one 8-byte feedback per joint, updated at 1000 Hz. Payload alone is 6 × 2 × 8 × 8 × 1000 = 768,000 bits/s. At 1 Mbit/s, payload already consumes 76.8% of the link before frame overhead or other traffic. This calculation cannot certify the design; it shows why “CAN supports 1–5 kHz” is not a general system-level claim.
Repeat the calculation using your real message map, then measure the complete network. The drive's internal current loop may run faster than the network command loop; document both separately.
4. CAN FD does not automatically upgrade an existing actuator
CAN FD support must be explicit for the controller and every relevant device configuration. Do not infer it from a CAN connector or from a related model. Confirm the application protocol and supported arbitration and data-phase settings. A vendor-specific CAN FD implementation does not by itself establish CANopen FD interoperability.
5. Select against acceptance criteria
- Define the control requirement: axis count, command period, allowable jitter, synchronization error and fault response.
- Check supported interfaces first: exact model, drive hardware and firmware revision.
- Calculate the message budget: command and feedback bytes, diagnostic traffic and update frequency for each signal.
- Verify integration files: use the ESI for EtherCAT, EDS/object dictionary for CANopen or message manual for proprietary CAN.
- Test the full configuration: log worst-case delay, timeouts, watchdog response and recovery with all axes connected.
Choose the architecture that passes these requirements and fits your integration resources. Increasing the nominal link speed alone cannot fix an unsupported drive protocol or unsuitable fault behavior.
Does ZHR-P60 have verified CAN FD, CANopen or gateway compatibility?
The public ZHR-P60 documentation specifies CAN with no native EtherCAT. CAN FD support, CANopen support and compatibility with any specified EtherCAT-to-CAN gateway are not publicly verified by the documentation provided here. This evidence gap does not establish hardware impossibility; request written confirmation for the exact model, firmware, controller and gateway configuration before design-in.
Encoder evidence is model-specific: P60 lists two magnetic encoders. P17 has a 36 V single-encoder configuration and a 48 V dual-encoder configuration. These are not a family-wide dual-encoder specification. Check the selected model and configuration rather than extending one model's specification to all ZHR-P modules.
Check available model documents and request protocol evidence
6. Confirm ZHR support by model
The public ZHR-H family page lists CAN / RS485. ZHR-P support must be checked for the selected model; P60 is listed as CAN only without native EtherCAT. Neither statement establishes family-wide CANopen, CAN FD, CiA 402 or EtherCAT availability. Request the exact protocol manual and firmware applicability before design-in.
Frequently asked questions
Does a CAN interface mean CANopen support?
No. CAN identifies a network technology; the actuator may use proprietary messages. Confirm CANopen, the object dictionary and supported device profiles for the exact firmware.
Can I choose a protocol using axis count alone?
No. Required update rates, payload size, synchronization, diagnostics and device support all affect the choice. Calculate the traffic budget and validate worst-case timing on the full network.
Is ZHR-P60 a native EtherCAT actuator?
The public P60 documentation lists CAN only, without native EtherCAT. Verify any proposed gateway or alternative configuration separately before design-in.
Integrating ZHR Actuators into Your Control System
Send your controller model, axis count, command and feedback payloads, target update rate, synchronization tolerance and preferred actuator. Request the protocol manual, message mapping and firmware applicability for a compatibility review.
Request a Protocol Compatibility ReviewEngineering RFQ path
Match the protocol to the actuator before specifying the joint
Send the controller protocol, cycle time, axis count, torque, speed, envelope, and quantity. We can check the interface against the published product data before a sample or OEM quote.