The hidden specs vendors hope you'll miss

Every robot datasheet leads with the same five numbers: payload, reach, repeatability, speed, and weight. These are the numbers that are easy to compare in a spreadsheet, easy to present to a finance committee, and almost entirely insufficient for predicting whether a robot will succeed in your operation.

The specifications that actually drive total cost of ownership, integration difficulty, and long-term reliability live deeper in the documentation — or are absent entirely and must be asked for. Here is a guided tour of the specs that matter most, where to find them, and what they reveal.

Stopping time and stopping distance

For any robot operating near people — whether a traditional industrial robot inside a light-curtain zone or a cobot in a collaborative application — stopping time and stopping distance are safety-critical parameters that determine safe distance calculations per ISO 13855.

The safe distance formula is straightforward:

S = K × T + C

Where S is the minimum safe distance, K is approach speed (typically 1,600 mm/s for a walking person), T is the total stopping time (detection + response + mechanical stop), and C is an intrusion distance constant (typically 8 mm for light curtains).

Why it matters: if a vendor's robot takes 350 ms to reach a full mechanical stop from its maximum operational speed, and your safety system's detection-to-response time is 50 ms, your safe distance is:

1,600 mm/s × 0.4 s + 8 mm = 648 mm

A competing robot that stops in 150 ms total requires only:

1,600 mm/s × 0.2 s + 8 mm = 328 mm

The faster-stopping robot allows a cell footprint 320 mm smaller on each guarded side. In a dense production environment, that difference is the difference between the cell fitting in the allocated space or not.

Stopping time is rarely on page one of a datasheet. Ask for the "stopping time and stopping distance curve" — it should show stopping performance at various speeds and payloads. Some vendors publish this as an appendix to the safety manual. Others provide it only on request. If a vendor cannot provide this document, you cannot complete a compliant safe distance calculation, and your safety integrator will need to measure it empirically on your installed robot — at your cost.

MTBF and mean time to repair

MTBF — mean time between failures — tells you the expected average operating hours between unplanned stoppages requiring maintenance intervention. MTTR — mean time to repair — tells you how long those stoppages last. Together they determine your realistic uptime.

The catch with published MTBF: MTBF figures are derived from reliability modeling (using component failure rates from standards like MIL-HDBK-217 or IEC 62380) or from field data. Vendors who publish MTBF figures rarely specify which method they used, under what operating conditions, or what counts as a "failure" in their definition. A vendor who counts only catastrophic hardware failures may report an MTBF 3–5× higher than a vendor who counts every unplanned stop including software faults and sensor calibration events.

What to ask:

• "Is this MTBF from reliability modeling or from field data, and over how many units and operating hours?"
• "What events are included in the failure count?" (Hard stops, E-stops triggered by software, sensor faults, etc.)
• "What is your field MTBF for this model at customers running comparable duty cycles?"

MTTR is often more important than MTBF for production planning. A robot with a 20,000-hour MTBF that takes 4 hours to repair when it fails causes the same downtime cost as a robot with a 10,000-hour MTBF that takes 2 hours to repair. The repair time depends on:

• Whether the failure is diagnosable remotely or requires an on-site technician
• Whether the failed component is field-replaceable (joints, cables, connectors) or requires factory return (servo drives, safety controllers)
• Whether your facility has a service contract with the vendor or must wait for a scheduled dispatch

For high-utilization applications (24/7 manufacturing, critical logistics), ask for the MTTR on the three most common failure modes, and confirm which of those are field-serviceable by your own maintenance staff.

Software update policy and lock-in

Robot software is increasingly complex and increasingly tied to proprietary ecosystems. The update policy — how software is maintained, at what cost, and what it changes — is a major TCO factor that receives almost no attention during procurement.

Questions that reveal the risk:

"What does a major firmware update typically change, and do I need to revalidate my safety configuration?" ISO 10218 compliance is tied to a specific software/firmware version. If a major update changes the safety-rated monitoring functions, your compliant installation may need re-validation — which means another risk assessment sign-off, potentially new third-party testing. This can cost $10,000–$50,000 depending on the scope.

"Is the programming interface proprietary or open-standard?" Proprietary pendant languages (FANUC's Karel, KUKA's KRL, ABB's RAPID) create lock-in: your programmers and programs cannot transfer to a different vendor's robot. Open-standard interfaces (URScript for UR robots, OPC UA for interoperability, ROS 2 compatibility) reduce that lock-in. If your organization plans to standardize on a single programming environment or integrate multiple robot types, this question determines whether that is feasible.

"What is the annual cost of software support and updates after warranty?" Some vendors include software updates for the product lifetime. Others charge annual software maintenance fees ranging from 2–8% of robot purchase price. Over a 7-year operational lifetime, a $5,000/year software maintenance fee on a $60,000 robot is an additional 58% on the capital cost — a figure that never appears in the purchase-order analysis.

"What happens to my robot when the vendor discontinues software support?" Industrial robots operate for 10–15 years. It is not unusual for a vendor to discontinue firmware development for a 10-year-old model while the hardware remains functional. Ask explicitly for the vendor's software support commitment period.

Fieldbus and I/O compatibility

Every robot must communicate with the surrounding production infrastructure: PLCs, conveyors, fixture controllers, vision systems, safety relays, and fleet management software. The robot's communication interfaces determine how much integration engineering that requires.

Common industrial fieldbuses and their implications:

The critical question: does the robot natively support the fieldbus used by your facility's PLC? If not, integration requires a gateway device (adding hardware cost, a maintenance item, and a latency layer) or a fieldbus card option (adding purchase cost and lead time).

Safety over fieldbus: some applications require safety-rated communication over the fieldbus — for example, triggering a Safe Stop 1 via PROFINET FSO (Functional Safety over fieldbus) rather than a hardwired safety relay. Not all robot controllers support this. If your cell design depends on it, verify before you specify.

ROS 2 compatibility is increasingly relevant for research-adjacent production applications and for organizations that want to future-proof against vendor lock-in. Not all industrial robots expose a ROS 2 interface; among those that do, the quality and maintenance of the driver varies significantly. If ROS 2 integration is in your roadmap, verify which message types the driver exposes, whether it is vendor-maintained or community-maintained, and what the update cadence is.

Thermal operating range

Every datasheet lists an operating temperature range — typically something like 0°C to 45°C. But this single range hides meaningful variation in how robots perform at the extremes of that range.

Cold-start behavior: most robots require a warmup period after extended cold storage before they achieve rated repeatability. The servo amplifiers, joint lubrication, and (for high-precision robots) the thermal equilibration of the arm itself affect position accuracy during the warmup period. For a cold-storage distribution center or a factory floor that goes dark on weekends in winter, this warmup requirement can subtract 15–30 minutes from effective production time at shift start.

Ask: "What is the recommended warm-up procedure, and what is the expected repeatability during warm-up?" If the vendor does not have a documented warm-up procedure, their answer is "we don't know how the robot performs in cold-start conditions in your environment" — which is an unacceptable answer for a $50,000+ capital purchase.

Upper temperature limits and derating: above approximately 35–40°C, servo drives and controllers generate more heat than their thermal management systems can dissipate efficiently. Most controllers have a thermal protection circuit that reduces allowable speed and current (derating) before triggering an over-temperature fault. In an uncooled facility in summer, or adjacent to a hot process, this can appear as intermittent speed reduction or unexpected E-stops that are difficult to diagnose without temperature logging.

Ask for the thermal derating curve: at what ambient temperature does the controller begin derating, and what is the speed or torque reduction per degree above that threshold?

Cable and connector service life

Cables and connectors are the components most commonly overlooked in total cost of ownership, and consistently the leading source of unplanned maintenance events in fielded robotic installations.

The specifications that matter:

Cable bend life: how many flex cycles can the cable assembly withstand before insulation fatigue causes intermittent continuity? For robots with external cable management (common on cobots), cables that flex with every robot cycle may cycle 1–3 million times per year. A cable rated for 5 million flex cycles has a 2–5 year life at that duty. Ask vendors for the bend life rating of both the robot's internal cable harness and any external cable tracks.

Connector IP rating at mating face: the robot's body IP rating may be IP54, but the connector used for EOAT power and I/O — if it is a standard industrial M12 or M8 circular connector in an outdoor or wash-down environment — may only be IP67 when correctly mated and tightened. A loose or partially mated connector is IP0. For wash-down environments, ask whether connections are tool-free (locking bayonet) or require a wrench and a torque specification to achieve the rated IP.

Recommended cable inspection interval: this figure will not be on the datasheet; it is in the maintenance manual. Knowing it before purchase tells you whether the robot's maintenance cadence fits your facility's maintenance program.

Software-defined motion limits and what can be changed in the field

Most robots allow operators to define software limits — reduced joint ranges, Cartesian space limits, speed limits — that confine motion to a safe working zone without requiring physical hard stops. These limits are often critical to the risk assessment.

The hidden question: which of these limits are safety-rated? A speed limit configured through the standard programming interface is typically not safety-rated — it can be modified by any programmer with normal access and does not participate in the functional safety system. A safety-rated software limit, configured through the robot's safety controller and requiring a safety password to modify, is a safety function and can be used as a safeguard.

The distinction matters enormously. If your risk assessment relies on a software-defined workspace limit to eliminate a hazard, that limit must be safety-rated. If it is not, a routine program modification can inadvertently remove your safeguard — and your risk assessment is no longer valid.

Ask: "Which workspace limits and speed limits are safety-rated per the robot's functional safety architecture, and which are standard operational limits?"

The checklist: specs to request before evaluation ends

Before you leave the vendor's evaluation process, request these documents:

A vendor who provides all of these documents without argument has an applications team that understands production operations. A vendor who cannot or will not provide them is selling you a product, not a solution.

The principle behind specification due diligence

Datasheets communicate the best version of a robot's performance under optimal conditions. They exist to pass a quick filter — to convince you the robot is in the right range — not to give you all the information you need to make a production decision.

The specifications on the front page get the robot shortlisted. The specifications in this article determine whether the robot succeeds in production.

Build the habit of asking for the integration manual before the sales process ends, not after the PO is submitted. Everything you need to know is in there. Most vendors will provide it. The ones who won't are telling you something important.

You have completed the Reading the Spec Sheet series. Return to all guides or explore Evaluating Vendors.