Freeze wiring, protocol, software, commissioning, and evidence boundaries before full-speed robot motion. This guide is written for engineers turning a purchased actuator module into a commandable, diagnosable robot axis.
Research snapshot checked on 2026-06-16. Core conclusions are tied to the source table below.
Reader Model
The distinct intent is wiring, protocol, software and commissioning path. Definition, supplier evaluation, pricing, and sizing are adjacent decisions, but not this page's primary job.
Robot system integrator
Freeze power feed, protection, brake release, encoder feedback, communication wiring, grounding, cable motion envelope, and the owner of every fault transition before sample PO.
Controls engineer
Choose by cycle-time target, synchronization need, object/profile support, diagnostics, software stack, and conformance evidence rather than by protocol name alone.
Software and ROS 2 engineer
Map protocol objects into command interfaces, state interfaces, lifecycle states, QoS policies, limit handling, and fault recovery paths before trajectory tests.
Procurement or program lead
Require wiring drawings, EDS/ESI files, object dictionary or PDO map, state-machine notes, fault code table, firmware version, thermal derating, and sample acceptance data.
Key Conclusions
Each conclusion has a source marker or a clearly stated implementation basis. Treat unsupported supplier claims as open evidence requests, not as pass conditions.
8 boundaries must be explicit before bench power-up
Power, protective earth, brake, encoder, drive enable, fieldbus, firmware parameters, and fault ownership should be assigned to either module supplier, robot integrator, or controller team before sample release.
Evidence: [S3][S4][S8]
ETG states design targets of <=100 us cycle time and <=1 us jitter
Use EtherCAT when distributed-clock synchronization, topology scanning, working-counter diagnostics, ESI/ENI workflow, and conformance evidence are part of the robot architecture. ETG also notes that official conformance certificates are issued only after testing at an accredited EtherCAT Test Center.
Evidence: [S5][S11]
CiA 402 versions from 2024 add 64-bit position values and extra operation modes
CiA 402 gives a common drive state machine, controlword/statusword pattern, PDOs, SDOs, and operation modes. CiA explicitly warns that optional functions and partial mandatory subsets can limit device exchangeability.
Evidence: [S6][S7]
ros2_control separates command interfaces from state interfaces
A usable module driver must expose the selected joint command mode, actual position/velocity/effort, diagnostics, lifecycle transitions, hardware groups for fault propagation when needed, and error behavior that the controller manager can enforce.
Evidence: [S9][S10]
7-stage commissioning path: offline, wiring, network, state, motion, thermal, fault recovery
A module that moves on the bench is not integrated. The pass condition is repeatable startup, disable, brake, fault, recovery, thermal, and software restart behavior under the target control architecture.
Evidence: [S1][S2][S3]
ISO 10218-2:2025 covers integration, commissioning, operation, maintenance, and decommissioning
Do not infer robot-level safety from a module datasheet. Treat STO, brake control, safe speed, guarding, and collaborative operation as system validation topics with dated evidence.
Evidence: [S1][S2][S4]
Evidence Table
Official standards and protocol documents define boundaries, vocabulary, and integration duties. They do not prove that a specific supplier module is compliant or fit for your robot.
| Claim | Evidence basis | Date | Strength |
|---|---|---|---|
| Industrial robot safety is split between robot design and system integration. | ISO 10218-1:2025 covers the industrial robot as partly completed machinery; ISO 10218-2:2025 covers robot applications and cells. | Checked 2026-06-16 | Tier 1 official standards pages |
| Machine electrical integration begins at the supply connection point and includes power-drive related updates. | IEC 60204-1:2016 product page describes general requirements for electrical equipment of machines and notes additions for power drive systems. | Checked 2026-06-16 | Tier 1 official standard page |
| Functional safety in adjustable speed electrical power drive systems has its own standard family. | IEC 61800-5-2:2016 is listed as an international standard with safety category and publication date 2016-04-18. | Checked 2026-06-16 | Tier 1 official standard page |
| EtherCAT integration depends on ESI/ENI files, topology, and diagnostics. | EtherCAT Technology Group documentation describes ESI files, ENI export, topology discovery, working counter diagnostics, and conformance testing. | Checked 2026-06-16 | Tier 1 official technology group |
| CiA 402 specifies drive behavior, operation modes, PDO/SDO use, and state-machine semantics. | CAN in Automation describes CiA 402 FSA, controlword/statusword, PDO mapping, SDO access, IEC 61800-7 links, and 2024 revision notes. | Checked 2026-06-16 | Tier 1 official technology group |
| ROS 2 message delivery can fail silently at architecture level when QoS profiles are incompatible. | ROS 2 Lyrical documentation describes request/offered compatibility, reliability, durability, deadline, liveliness policies, and incompatible QoS events. | Checked 2026-06-16 | Tier 1 official project documentation; version boundary: ROS 2 Lyrical docs checked 2026-06-16 |
| EtherCAT conformance and interoperability are related, but a certificate has a specific test-center meaning. | ETG conformance pages describe Plug Fests, Conformance Test Tool, official EtherCAT Test Centers, and the distinction between in-house testing and an EtherCAT Conformance Tested certificate. | Checked 2026-06-16 | Tier 1 official technology group |
| ROS 2 hardware descriptions can model non-joint actuator signals, but generic publishing is not automatic. | ros2_control Kilted documentation build labeled Jun 2026 describes joints, sensors, GPIOs, hardware groups, data types, and the need for custom GPIO controllers for application-specific ports. | Checked 2026-06-16 | Tier 1 official project documentation |
| Evidence source | What it proves | What it does not prove | Action for integrators |
|---|---|---|---|
| ISO 10218-1:2025 and ISO 10218-2:2025 | Industrial robot safety is split between robot design as partly completed machinery and integration of applications/cells. | That a purchased actuator module is sufficient for service robots, medical robots, mobile platforms, lifting people, or any final cell acceptance. | Map the target use case to the actual robot category before reusing industrial-robot assumptions. |
| IEC 60204-1:2016 and AMD1:2021 consolidated listing | Electrical-equipment scope starts at the machine supply connection and includes protective bonding, EMC, PDS, overcurrent, STO, and documentation concerns. | That the supplier harness, brake circuit, or cabinet wiring meets the final machine electrical design. | Request wiring evidence and run continuity, isolation, grounding, voltage-drop, and restart checks on the real cabinet. |
| IEC 61800-5-2:2016 | Functional safety for adjustable-speed electrical power drive systems is a dedicated standard family with its own scope. | That a module-level STO claim closes robot-level safe stop, brake, restart, guarding, or operator-access requirements. | Treat drive safety functions as components in a system safety validation, not as final robot certification. |
| ETG EtherCAT technology and conformance pages | EtherCAT has public design targets and mechanisms for short cycles, distributed clocks, ESI/ENI configuration, Working Counter diagnostics, and conformance testing. | That one supplier module, firmware revision, ESI file, or MainDevice stack will meet your robot cycle and recovery target. | Ask for ESI revision, ENI generation path, CTT/test-center status, topology scan log, DC setting, and Working Counter expectations. |
| CiA 402 and CANopen profile documentation | CiA 402 defines drive behavior, FSA, controlword/statusword, operation modes, PDOs, SDOs, and recent 2024 profile revisions. | That every claimed CiA 402 device implements the same optional functions or all mandatory objects correctly. | Compare object dictionary, PDO map, operation modes, EMCY behavior, vendor ID, and firmware release notes before substitution. |
| ROS 2 Lyrical QoS and ros2_control Kilted documentation | ROS 2 exposes QoS compatibility rules and ros2_control has hardware interface types for joints, sensors, GPIOs, and groups. | That a supplier driver is deterministic, safety-rated, or compatible with the chosen controller manager configuration. | Pin ROS 2 distribution, RMW, controller YAML, QoS profiles, interface names, lifecycle logs, and restart tests. |
Wiring Boundaries
Most integration delays come from hidden ownership gaps: brake, enable, shielding, bus configuration, feedback, or harness fatigue. This table turns those gaps into evidence requests.
| Boundary | Evidence to request | Failure mode | Acceptance check |
|---|---|---|---|
| Power input | Rated voltage range, inrush, peak current, continuous current, fuse or breaker recommendation, connector pinout | Brownout, uncontrolled reset, nuisance trips, or cable overheating during acceleration | Voltage drop and current logged during worst acceleration and brake-release events |
| Protective bonding and shielding | PE/FE point, shield termination plan, cable shield continuity, cabinet grounding drawing | Encoder noise, fieldbus errors, EMC failures, or intermittent position feedback | Continuity, isolation, and noise check recorded before closed-loop motion |
| Brake and enable chain | Brake voltage/current, release time, holding torque, dynamic-stop limits, enable logic, STO ownership | Axis drops, brake overheats, or drive enables before the controller owns the axis | Brake release, disable, E-stop, restart, and gravity-load behavior verified in the target orientation |
| Encoder and feedback | Encoder type, resolution, absolute/multi-turn support, index behavior, update rate, fault bits | Wrong homing direction, lost commutation, position wrap, or unstable velocity estimation | Direction, zero, wrap, startup absolute position, and plausibility checks pass before trajectory test |
| Fieldbus and service channel | Cable type, termination or topology rule, node ID/addressing, EDS/ESI file, object dictionary, firmware version | Device discovered but not controllable, wrong PDO mapping, cyclic data mismatch, or poor diagnostics | Network scan, object read/write, cyclic data, diagnostics, and restart behavior logged |
| Harness motion envelope | Bend radius, torsion limit, drag chain rule, hollow-shaft routing, connector retention, strain relief | Intermittent bus faults, cable fatigue, connector loosening, or seal damage after cycling | Motion cycle test with cable route inspected and fault counters reviewed |
Protocol Choice
A protocol label is not enough. Integration-ready modules need the files, object map, timing behavior, diagnostics, and conformance story that your controller stack can reproduce.
| Protocol path | Use when | Artifacts to freeze | Limits |
|---|---|---|---|
| CANopen / CiA 402 | Distributed modules need a standardized drive state machine, moderate bandwidth, compact wiring, and object-level access. | EDS, node ID plan, vendor ID, baud rate, PDO map, SDO list, controlword/statusword, operation modes, EMCY handling | CiA warns that optional functions and even partial mandatory implementations can limit exchangeability. Confirm exact mandatory and vendor-specific objects. |
| CANopen FD | Classic CANopen object model is desired, but larger PDO payloads or newer device profiles are required. | CANopen FD profile support, 64-byte PDO assumptions, CiA 402-6 mapping, controller compatibility, termination and bit timing evidence | Supplier and controller ecosystem support is narrower than classic CANopen in many robot programs. |
| EtherCAT / CoE | Multi-axis synchronization, short cycle time, topology diagnostics, and centralized configuration are primary requirements. | ESI, ENI, PDO assignment, distributed clock setting, Working Counter expectations, CTT or EtherCAT Test Center evidence | Requires a compatible EtherCAT MainDevice stack, configuration tooling, and careful startup-state management. Certificate evidence should specify whether testing was in-house or at an accredited ETC. |
| EtherCAT with FSoE | Safety-related data must travel through the same network architecture under a black-channel approach. | FSoE safety plan, safety parameters, safe-state behavior, validation records, safety controller compatibility | Does not remove the need for robot or cell safety validation under the applicable risk assessment. |
| Vendor serial or local API | Prototype axis is simple, bandwidth demand is low, or the module supplier provides a mature validated driver. | API manual, packet timing, checksum/fault behavior, firmware version, timeout behavior, host library tests | Integration cost can rise later if the program needs multi-vendor interchangeability or deterministic synchronization. |
| Protocol path | Verified public fact | Integration test | Fail condition | Source |
|---|---|---|---|---|
| CANopen / CiA 402 | CiA lists CiA 402-1 version 5.0.0 published 2023-12-05 and CiA 402-2/-3 version 5.0.0 published 2024-02-06. | Read identity object, validate controlword/statusword transitions, compare PDO map to EDS, and inject EMCY/fault reset. | Supplier claims CiA 402 but cannot show supported modes, mandatory object coverage, or firmware-specific PDO mapping. | [S6][S7][S13] |
| CANopen FD | CiA states CiA 402-6 specifies default 64-byte PDO usage for CANopen FD networks and multiple-axis systems. | Confirm controller CAN FD support, bit timing, payload size assumptions, and profile version before selecting modules. | Classic CANopen tools, gateways, or controllers are assumed to handle CANopen FD without evidence. | [S6] |
| EtherCAT / CoE | ETG states design focus of <=100 us cycle time and <=1 us synchronization jitter, plus ESI-to-ENI configuration flow. | Generate ENI from the supplier ESI, verify distributed clocks if used, compare topology, and log Working Counter behavior. | The module runs in a vendor tool but fails under the target MainDevice stack or loses working-counter consistency after restart. | [S5][S11] |
| EtherCAT with FSoE | ETG describes FSoE as a black-channel safety protocol standardized in IEC 61784-3 and suitable up to SIL 3. | Validate safety parameters, safe-state truth table, safety controller compatibility, and robot/cell restart authorization. | FSoE support is treated as final robot safety approval without application-level risk assessment. | [S5][S12] |
| Vendor serial or local API | No public standard can prove interchangeability unless the supplier publishes the protocol and driver contract. | Run timeout, checksum, restart, version mismatch, fault injection, and driver lifecycle tests on the target controller. | The only repeatable control path is a GUI or undocumented vendor initialization sequence. | To be verified / no reliable public standard evidence |
Software Interface
The control stack must know what it can command, what it can read, how the module changes state, and how faults become safe, observable, and recoverable.
| Layer | Decision | Evidence | Blocker |
|---|---|---|---|
| Hardware description | Represent each controlled joint in URDF and ros2_control with explicit command and state interfaces; every joint in ros2_control must also exist in the URDF received by controller manager. | URDF fragment, interface names, limit values, transmission assumptions, mimic or coupled-joint notes | The joint exists in CAD but not in the controller manager hardware information. |
| Driver and lifecycle | Implement startup, configure, activate, deactivate, cleanup, and fault transitions deliberately. | Driver state diagram, startup log, retry policy, timeout behavior, firmware compatibility matrix | The module can move only after manual vendor-tool initialization. |
| Command mode | Select position, velocity, effort, or torque command mode and document when switching is allowed. | CiA 402 operation mode, EtherCAT PDO mapping, controller YAML, command-mode switch test | The trajectory controller sends position commands while the drive is still in velocity or torque mode. |
| State feedback | Publish actual position, velocity, effort/torque estimate, temperature, voltage, and fault status where available; use sensor/GPIO interfaces for non-joint telemetry instead of hiding it in joint states. | State interface list, broadcaster config, diagnostic topic, fault-code mapping, sample log | The controller sees position but not drive faults, thermal warnings, or brake state. |
| QoS and telemetry | Define QoS for diagnostic and telemetry topics so tools and supervisors actually connect. | QoS profile table, reliability/durability choice, deadline and liveliness settings, bag replay test | A reliable subscription requests more than a best-effort publisher offers and receives no messages. |
| Safety supervision | Keep safety-related stop logic outside ordinary motion topics unless a validated safety protocol covers it; use hardware groups only for error propagation, not as a safety certification shortcut. | Safety controller architecture, STO/brake wiring, safe-state truth table, restart authorization rule | A non-safety ROS node is treated as the only stop path for hazardous motion. |
| Failure pattern | Why it happens | Detection check | Fix before pilot build |
|---|---|---|---|
| Reliable subscriber receives no diagnostic topic | ROS 2 QoS uses a request/offered model. A best-effort publisher cannot satisfy a reliable subscriber. | Enable incompatible QoS event callbacks and run a bag or live subscription test for diagnostics. | Pin publisher and subscriber QoS profiles for telemetry, diagnostics, services, and command acknowledgements. |
| Late-joining supervisor misses the current fault state | Volatile durability does not persist samples for late subscribers; transient local requires agreement on both sides. | Restart the supervisor while the drive is in warning/fault state and check whether it receives current state. | Use a latched/transient-local equivalent only where stale data risk is controlled and documented. |
| Brake or enable signal is modeled as a generic joint command | ros2_control supports GPIO-like interfaces for non-joint signals, but application-specific GPIO publishing needs custom control logic. | Inspect URDF and controller YAML for brake, enable, reset, and safety I/O ownership. | Separate joint motion commands from brake, enable, reset, and diagnostics interfaces. |
| One actuator error should stop a manipulator, but does not | ros2_control hardware components isolate errors by default unless hardware groups are configured to propagate faults. | Inject a drive fault in one axis and verify whether the intended group response occurs. | Use hardware groups for non-safety fault propagation and validate the resulting controller behavior. |
Commissioning Path
This sequence intentionally delays performance testing until the module has already proven controlled startup, safe state, communication, direction, limits, and repeatable recovery.
| Phase | Objective | Checks | Pass condition |
|---|---|---|---|
| 0. Offline package review | Confirm all integration artifacts exist before hardware is energized. | Wiring drawing, EDS/ESI, object map, firmware version, mounting drawing, brake limits, thermal curve, fault table | No unknown owner remains for power, brake, feedback, bus, firmware, safety, or diagnostics. |
| 1. Mechanical and wiring inspection | Prevent avoidable faults before closed-loop control. | Connector keying, torque marks, PE/FE, shield termination, cable motion envelope, strain relief | All wiring and harness risks are logged with photos or inspection records. |
| 2. Network bring-up | Prove the controller can discover and configure the module repeatedly. | Node scan, EDS/ESI parse, address, PDO map, object read/write, working counter or bus error counters | Cold restart and software restart both reach the expected communication state. |
| 3. Drive state machine | Move from disabled state to operational state under controlled authority. | Controlword/statusword or equivalent states, enable sequence, brake release, fault reset, quick stop | Enable, disable, fault, reset, and quick-stop transitions match the documented state table. |
| 4. Low-energy motion | Validate direction, zero, limits, and basic control behavior with low risk. | Jog, home, soft limits, velocity sign, torque/current limit, following error, encoder wrap | Axis moves in expected direction and stops within conservative software and physical limits. |
| 5. Duty-cycle and thermal run | Show continuous use is compatible with the real robot duty profile. | Target speed/load cycle, temperature, current, voltage drop, brake temperature, reducer noise, fault counters | Temperature and fault counters remain inside agreed limits for the planned duty profile. |
| 6. Fault recovery and software restart | Prove the robot can recover without hidden manual steps. | Cable disconnect, bus timeout, overcurrent, overtemperature warning, controller restart, E-stop reset | Every injected fault reaches safe state and recovers only through the approved sequence. |
Field Proof
The official sources explain standards, profiles, and interfaces. A robot program still needs measured evidence from the selected module, firmware, harness, controller stack, and duty cycle. Use these checks when a supplier claim is plausible but not yet proven in your architecture.
| Proof item | Evidence to capture | Pass condition | Source basis |
|---|---|---|---|
| Cold-start reproducibility | Power-cycle log from supply off to controller active state, including node discovery, object/configuration writes, and final mode. | Three consecutive cold starts reach the same disabled/ready state without vendor GUI steps. | [S5][S6][S9] |
| Topology and communication diagnostics | EtherCAT topology comparison plus Working Counter log, or CANopen node scan plus EMCY/fault counter log. | Injected disconnect, address conflict, or bus timeout is localized and reported before motion resumes. | [S5][S7][S8] |
| Mode and unit consistency | Command units, encoder counts, zero direction, velocity sign, torque/current scale, operation mode, and limit values. | The same command produces expected direction, magnitude, and limit behavior through the robot controller, not only the vendor tool. | [S6][S9] |
| Thermal and brake duty cycle | Installed robot-axis run with final harness, covers, load, ambient assumption, brake release pattern, and fault counter trend. | Temperature, current, brake heating, and fault counters remain inside agreed limits for the actual duty cycle. | [S2][S3][S4] |
| Software restart and QoS behavior | Controller-manager restart, driver lifecycle transition, QoS compatibility events, and telemetry reconnection logs. | Restart does not require hidden manual initialization and supervisors receive state or explicit incompatible-QoS events. | [S9][S10] |
Integration Data Pack
A useful supplier response is not a generic datasheet. It is a versioned package that lets electrical, controls, software, safety, and test owners reproduce the same result on the target robot.
| Package | Minimum fields | Why it matters | Owner |
|---|---|---|---|
| Electrical and harness pack | Power pinout, connector part numbers, shield/ground rule, brake circuit, fuse recommendation, inrush and peak current | Lets the buyer validate cabinet wiring, protective bonding, cable routing, and brake release before first power. | Supplier electrical engineer + buyer controls lead |
| Protocol configuration pack | EDS or ESI file, object dictionary, PDO map, operation mode list, firmware version, node/address plan, diagnostic object list, conformance or test-center status | Prevents the common failure where a module is discoverable but cannot be controlled by the target stack. | Supplier firmware engineer + buyer controls lead |
| Software driver pack | Driver API or plugin, lifecycle states, command/state interfaces, unit conventions, timeout behavior, restart and fault reset rules | Turns module behavior into a reproducible robot-control contract rather than a vendor-tool demo. | Buyer software lead + supplier application engineer |
| Commissioning evidence pack | Startup log, low-energy motion log, thermal run, brake test, fault injection, bus counters, final configuration archive | Shows the same module can be installed, restarted, disabled, recovered, and accepted across samples. | Integrator test lead |
| Safety boundary pack | STO/brake wiring, safety I/O, safe state truth table, restart authorization, risk-assessment assumptions, applicable standards | Keeps drive-level safety functions separate from robot or cell-level safety validation. | Safety engineer + system integrator |
No public universal value
Use the robot controller period, drive loop, bus cycle, and measured jitter for the selected architecture.
Insufficient without object-level review
Compare mandatory objects, optional objects, PDO maps, operation modes, and firmware behavior before approving substitutions.
To be verified until object dictionary and test log are provided
CiA warns that some vendors claim conformity while implementing only subsets; require object-level evidence before module substitution.
No reliable public data unless the supplier publishes the protocol
Do not use a vendor API for production axes until timing, checksum, timeout, restart, and fault behavior are reproducible without GUI tools.
Not implied
Validate safety at robot application or cell level, including brake, restart, guarding, and operator access.
Not sufficient
Run the final duty profile with installed harness, covers, brake behavior, and target ambient assumptions.
Acceptance Matrix
The matrix gives procurement and engineering a shared rule: no gate passes on claims alone. Each pass needs reproducible evidence and a named owner.
| Gate | Owner | Proof | Reject if |
|---|---|---|---|
| Pre-PO evidence gate | Supplier + buyer systems lead | Drawing pack, EDS/ESI, protocol map, firmware list, thermal assumptions, fault table, brake limits | Any required artifact is replaced by a screenshot or undocumented vendor-tool setting. |
| Bench sample gate | Controls engineer | Startup logs, network scan, command/state interface test, low-speed motion, disable and fault reset | The module can only be controlled through vendor software and not through the target controller stack. |
| Robot axis gate | Mechanical + controls team | Installed cable route, thermal run, limit test, brake test, restart test, trajectory profile log | Harness faults, brake heating, or following errors appear only after installation. |
| Pilot build gate | Program lead | Repeatable commissioning checklist, configuration versioning, sample acceptance report, open-issue list | Configuration is not reproducible across modules or firmware revisions. |
Scenario Examples
Premise: Each joint module exposes CiA 402 controlword/statusword, cyclic position command, current feedback, and temperature.
Process: Start with node ID and PDO map freeze, then validate state machine, brake release, current limit, zeroing, and fall-safe behavior.
Result: Conditional fit if thermal data and brake/fault recovery pass under real gait duty cycle.
Premise: The controller needs synchronized multi-axis trajectories and topology diagnostics during startup.
Process: Use ESI files to generate configuration, check distributed clocks, compare topology, then verify working counters and fault logs.
Result: Good fit if MainDevice stack, ESI revision, and drive conformance evidence match the target controller.
Premise: A vendor API can move the actuator, but ROS 2 command/state interfaces and restart behavior are incomplete.
Process: Build a thin hardware interface, map diagnostics, define QoS for telemetry, and run restart/fault injection before payload tests.
Result: Prototype-only until the driver starts without vendor tools and exposes enough state for supervision.
Premise: Robot actuator modules, I/O, safety controller, and upstream PLC use different networks.
Process: Separate motion bus, safety path, supervisory data, and cell interlock responsibilities before commissioning.
Result: Acceptable if system-level safety validation and restart authority are documented at the cell level.
Risk and Boundaries
The common failure pattern is simple: the module can move, but the team cannot reproduce safe startup, diagnostics, thermal behavior, and fault recovery inside the target robot.
| Risk | Trigger | Severity | Mitigation |
|---|---|---|---|
| Protocol name hides object-level mismatch | Supplier claims CANopen or EtherCAT support but cannot provide the exact object dictionary, PDO map, or ESI/EDS revision. | High | Block sample PO until object-level data and firmware revision are frozen. |
| Brake control is treated as ordinary motion output | Brake release, enable, STO, and restart sequence are not separated in wiring and software states. | High | Create a brake/enable truth table and test gravity-load behavior before robot installation. |
| ROS 2 QoS mismatch removes diagnostics | Telemetry publishers and supervisors use incompatible reliability or durability settings. | Medium | Document offered/requested QoS and test connection events plus bag recording. |
| Thermal success on bench fails in robot harness | Module passes no-load motion but fails after cable routing, covers, gravity load, or duty cycle are added. | High | Repeat thermal run in final mechanical orientation with the final cable route. |
| Safety scope is overclaimed | A module has STO or safe inputs but no robot-level risk assessment or cell validation record. | High | Treat the module as one safety-related component and validate the complete robot application separately. |
You already know the module class and need a practical path from datasheet to wired, configured, and accepted robot axis.
The team is still arguing whether the item is a motor, reducer, servo actuator, joint module, or complete robot joint.
Torque, speed, inertia, load, duty cycle, and thermal margin are not yet quantified.
The project needs legal compliance, medical validation, collaborative safety approval, or final machine acceptance.
Sources
Standards pages and protocol documentation can change. For regulated or safety-related programs, re-check the current publication, version, and market-specific legal status before final acceptance.
S1 / 2026-06-16
Used for the boundary between industrial robot design requirements and later integration responsibility.
S2 / 2026-06-16
Used for integration, commissioning, operation, maintenance, and decommissioning scope.
S3 / 2026-06-16
Used for machine electrical-equipment boundary and power-drive-system context.
S4 / 2026-06-16
Used to keep drive safety-function claims separate from ordinary motion integration.
S5 / 2026-06-16
Used for cycle-time, jitter, topology, distributed clocks, diagnostics, CoE, FSoE, ESI/ENI, and conformance context. Automated curl checks returned 403 on 2026-06-16, so re-check in a browser before regulated use.
S6 / 2026-06-16
Used for FSA, controlword/statusword, PDO/SDO, IEC 61800-7 links, and optional-function warning.
S7 / 2026-06-16
Used for process data, configuration parameters, diagnostic information, object dictionary, and profile interoperability context.
S8 / 2026-06-16
Used for planning, assembling, commissioning, and installation-guideline release context. Automated curl checks returned 403 on 2026-06-16, so re-check in a browser before regulated use.
S9 / 2026-06-16
Used for command/state interface, joint, sensor, GPIO, hardware-group, data-type, and version-boundary requirements. Source page title is labeled Kilted Jun 2026 documentation.
S10 / 2026-06-16
Used for request/offered QoS compatibility, reliability, durability, deadline, liveliness, incompatible-QoS events, and matched-event risks.
S11 / 2026-06-16
Used for Plug Fests, Conformance Test Tool, EtherCAT Test Centers, and official conformance-tested certificate boundaries. Automated curl checks returned 403 on 2026-06-16, so re-check in a browser before regulated use.
S12 / 2026-06-16
Used for FSoE black-channel architecture, IEC 61784-3 standardization, SIL 3 suitability claim, and safety-boundary caveats. Automated curl checks returned 403 on 2026-06-16, so re-check in a browser before regulated use.
S13 / 2026-06-16
Used for identity-object and vendor-ID checks when validating CANopen device identity and substitution risk.
FAQ
Confirm rated voltage, inrush, current limit, connector pinout, protective bonding, shield termination, brake wiring, drive enable logic, and the approved first-power procedure.
Not by default. Brake release should be tied to a documented enable and safe-state sequence, especially for gravity-loaded robot axes.
Request power and signal pinout, connector model, cable recommendation, grounding and shielding note, brake electrical data, encoder interface, and service-port instructions.
It becomes critical once the cable moves with the joint. Bend radius, torsion, hollow-shaft routing, strain relief, and connector retention must be tested under motion.
No. EtherCAT is often stronger for synchronized multi-axis systems, while CANopen/CiA 402 can be simpler and robust for distributed modules with moderate bandwidth needs.
You need the EDS, supported operation modes, exact PDO map, required SDO parameters, state-machine behavior, fault codes, and evidence that mandatory objects are implemented.
You need the ESI file, PDO assignment, distributed-clock support if required, MainDevice compatibility, topology behavior, working-counter expectations, and conformance evidence.
It is acceptable for prototypes or tightly controlled systems if the supplier provides a stable driver, timing data, fault behavior, and a migration path if the robot scales.
Expose each joint through command interfaces and state interfaces, then document driver lifecycle, interface names, limits, units, and fault transitions.
QoS mismatches can prevent diagnostics or telemetry from being delivered. Supervisory nodes should use tested reliability, durability, deadline, and liveliness settings.
No. Joint position, velocity, and effort belong in joint state paths. Temperature, voltage, fault bits, brake state, and bus counters often belong in diagnostics or custom state interfaces.
The driver should initialize without vendor tools, command the selected mode, read actual state, report faults, recover from restart, and reject unsafe command-mode changes.
The first pass is not motion. It is repeatable discovery, configuration, disabled-state verification, and safe response to missing command or bus timeout.
Only after wiring, network, state machine, direction, zeroing, limits, brake behavior, and low-energy motion have passed.
Include robot axis role, target protocol, controller stack, torque/speed/duty cycle, power supply, brake need, encoder requirement, quantity, and required documentation package.
Pause when the supplier cannot provide protocol files, object maps, firmware revision, wiring details, brake behavior, or fault recovery instructions before sample PO.
Action Plan
Send the target protocol, controller stack, axis role, torque/speed/duty cycle, supply voltage, brake need, encoder requirement, documentation expectations, sample quantity, and acceptance gates. Ask the supplier to return missing files before you buy hardware.
Inquiry Email
Send target torque/speed, protocol, quantity, and delivery location.
