Robot cycle time is not machine-tending output

What decision should cycle evidence support?

A robot motion time can help compare one programmed movement. It does not establish the net output of a machine-tending cell. Production depends on the complete operating loop: part presentation, robot handling, machine availability, door and chuck or fixture actions, processing, inspection, rejection, replenishment, interruptions and recovery.

The buyer decision is therefore not whether the robot is fast. It is whether the configured cell can produce accepted parts at the required demand rate under the agreed part mix and operating conditions, while preserving safe access and a workable recovery path.

Why does the complete state history matter?

The OPC Foundation's current Machine Tools information model separates production states such as initializing, running, interrupted, ended and aborted. Its runtime model records starts, ends, interruptions and abortions, and its time-based KPI guidance explains that useful time measures can require the duration of multiple states rather than one headline value.

That distinction is practical for tending. A short robot move does not recover time lost while the machine is unavailable, a part is mispresented, quality approval is pending, a program is being changed or an operator is restoring the cell. Record those states separately so the proposed solution is not credited for time it cannot control.

Which events connect machine time to accepted output?

A state label is useful only if the buyer can trace it to the production question. For a proposed cell, ask who owns each source signal, when it is recorded, which part or job it refers to, and where an accepted or rejected part is counted. A machine job end is not automatically a good part, and a robot load completion is not proof that the machine has started processing.

The OPC UA Machine Tools model provides job runtime and interruption concepts. A manufacturer’s machine-tending I/O example separately distinguishes requests and completions for load and unload, clamping and robot-clear states. Neither source proves that a particular installation exposes all required signals. Map the actual machine, robot, operator and quality records before calculating a cell result.

• For each load, process, unload and quality event, retain the source system, named signal owner, timestamp and part or job reference.
• Mark an operator intervention as planned work, unplanned recovery or changeover, with its start, end and restart authority. Do not silently charge every operator minute to the robot cycle.
• Keep machine processing and robot or operator work that happens in parallel as overlapping intervals. Adding every duration into one serial cycle would overstate elapsed time.
• Connect the output count to a stated good-part definition and a named demand window; record rejected, reworked and still-pending parts separately.

What should the baseline contain?

Use the baseline to identify the actual constraint. If machine processing dominates and the operator already tends several machines, faster handling may not materially change output. If handling blocks the machine or creates variable idle time, a tending solution may have a clearer production hypothesis.

• Required good parts by product or part family during the real demand window.
• Observed machine processing time and its distribution, not only a nominal recipe value.
• Manual load, unload, cleaning, gauging, deburring and quality-disposition time.
• Setup, program, gripper, fixture and verification time for each representative changeover.
• Waiting caused by upstream presentation, downstream capacity, quality release or missing material.
• Fault, interruption and recovery categories, including who responds and how production restarts.
• Rejected or damaged parts and the point at which their disposition becomes known.

How should a provider's cycle claim be assessed?

Ask the provider to state the exact configuration and scope behind the claim: robot and software version, tool, part, presentation method, path, speeds, machine interface, inspection steps, safeguards and exclusions. Separate simulated time, dry-cycle time, a demonstrated best case and an observed production distribution.

NIST's manufacturing-robot agility work is useful here because it treats efficiency and effectiveness under changing conditions as measurable system properties. That research does not certify a tending application, but it supports testing the system against the variation and anomalies that matter to the buyer rather than relying on one ideal cycle.

What should a representative pilot measure?

The pilot should preserve raw state and event evidence where the interfaces allow it. OPC UA production and interruption states can provide a common structure, but the responsible machine builder, integrator, safety duty holders and operator still need to agree which signals are authoritative and how they may be used.

• Good parts completed during a named operating window and demand condition.
• Complete loop time from ready-for-load through accepted output, reported as a distribution.
• Machine waiting, robot waiting, blocked, interrupted and aborted time by reason.
• Interventions, recovery time, restart authority and any manual work retained.
• Changeover time across the agreed part family, including verification before release.
• Quality escapes, rejected parts, damage and the evidence used for disposition.
• The tested configuration, conditions, exclusions and a pre-agreed proceed, revise or stop rule.

Check the time basis before ordering observations — method added 7 October 2026

A tending trial can produce a tidy spreadsheet whose rows do not share a comparable time basis. The machine may timestamp a value at its source, a gateway may record receipt, and an operator may enter a quality decision later. Sorting those displayed times can create an apparent sequence without establishing when the underlying work happened. Before attributing waiting or recovery to a robot, identify the meaning and clock behind each observation.

The OPC UA Part 4 reference distinguishes SourceTimestamp from ServerTimestamp for Variable values. The source timestamp belongs to the data source, uses UTC and is passed unchanged when forwarded. The server timestamp describes receipt or when that server knew a value to be accurate; subscribing servers apply their own server timestamps. These are field semantics, not proof that a particular machine exposes them, that an event log uses the same fields, or that two installed clocks are aligned.

For each comparison, retain the exact source system and field, what the timestamp represents, the physical clock basis and any timezone conversion used in the export. Ask the controls owner for dated evidence of offset or uncertainty during the trial window. A configured time service is useful context, but its name alone does not demonstrate the relationship between the two observations being compared. Record changes, outages or unavailable checks instead of silently treating every row as equally reliable.

Consider a hypothetical machine-ready observation displayed at 10:00:00 and robot load completion displayed at 10:00:01. That one-second display difference is not yet a measured handling interval if one field is source time and the other is server receipt time, or their clock relationship is unknown. Keep both raw records. Do not add a guessed correction simply to produce a positive duration. The owner may need to narrow the comparison to one evidenced clock domain or collect another observation under an agreed method.

Choose the required time resolution from the buyer question, not from the number of decimal places in the export. A comparison of broad shift states and a claim about a short handoff interval may need different evidence. RobotAtom does not prescribe a universal offset threshold here. The operations and controls owners should define what uncertainty would prevent their stated conclusion and retain the reasoning. If the evidence cannot support event order, say so; an unresolved interval should not become a confident bottleneck diagnosis.

The local output evidence register now provides a separate timestamp-comparability review. It requests both systems and field meanings, clock basis, dated offset or uncertainty evidence, and the owner's disposition. Missing entries or an unresolved disposition keep the review withheld. Completing those fields checks only that a record exists: it does not synchronise equipment, correct timestamps, calculate elapsed time, verify accepted output or approve production. Keep the counter and quality-disposition checks separate, and take the actual records—not just a completed form—to the trial review.

Check the counter before subtracting two readings — method added 6 October 2026

A trial report can contain two clear counter readings and still leave its production claim unresolved. Before subtracting, identify the physical machine, the counter path or identifier, the counting rule and the production order. Keep the start and end timestamps with their timezone. A screenshot labelled total parts is not enough to establish whether both readings describe the same machine, order and unit of output.

The OPC Foundation's quantity guidance describes deriving produced quantity from readings at the start and end of a production order. Its machine-operation model identifies PartsProducedInLifetime as an optional UInt64 counter and warns that acquisition can differ between machines. The counter carries no quality information. This supports checking the input boundary before doing arithmetic; it does not establish that a particular installed server exposes the counter or that one increment equals one accepted unique part.

Ask the controls owner to explain what happens around job changes, configuration changes, counter replacement and interruptions. These are buyer-side investigation questions, not a claim that the specification permits routine resets of a lifetime counter. If the counter decreases or continuity is unresolved, retain the raw readings and withhold the difference. Taking an absolute value hides the problem. Adding an assumed rollover quantity can create a plausible result without the evidence needed to support it.

Consider a hypothetical start reading of 1,000 and end reading of 1,100. With retained evidence for one counter and an unchanged scope, the entered arithmetic gives 100 increments. The site still needs to demonstrate what those increments represent. Multiple operations on one physical part, a multi-part cycle or a vendor-specific counting rule may require reconciliation to a unique-part record. Do not use the counter difference to fill the accepted-output column: acceptance belongs to the separate quality record and cutoff.

For a discontinuous window, separate intervals only where the controls owner can provide a defensible boundary and evidence for each interval. Keep the unavailable interval visible rather than quietly reporting the sum as complete shift output. Compare the baseline and proposed trial using the same inclusion rule. A tighter evidence boundary may reduce the usable sample; that is preferable to making a commercial throughput claim from an unexplained counter jump.

The output worksheet now checks entered counter values without changing the disposition balance. It preserves large UInt64 readings with integer arithmetic, withholds a result for blanks, missing provenance, unresolved continuity or a decreasing counter, and labels a valid subtraction arithmetic only. Its continuity selection is self-reported, not verification. Bring the raw records and owner explanation to the trial review; no counter check in this worksheet approves production, quality or safety.

Reconcile accepted output at a quality cutoff — method added 5 October 2026

A machine can finish producing a part before the quality owner can accept it. If inspection happens after the shift, a count taken at shift end and a count taken the following morning answer different questions. Keep the production window fixed and state the quality cutoff separately. Otherwise an apparent improvement may come from allowing more time for disposition, rather than changing the tending cell.

The OPC Foundation’s quantity-based KPI guidance distinguishes produced quantity from good quantity. In the current Machine Tools reference, a lifetime produced-parts counter can support a produced-count difference, but cannot establish good quantity by itself. Rework quantity is also not generally available through that interface. Check the actual installed implementation and the quality record; do not manufacture missing information from a cycle-complete signal.

The reference also retains a deprecated PartQuality enumeration for older implementations. It separates good, bad, not-yet-measured and unavailable quality statements, and limits the statement to the machine’s process steps. That older enumeration is useful when interpreting an existing signal, not a recommendation to install a deprecated interface. A machine’s good flag may still leave downstream or customer acceptance unresolved.

For a buyer comparison, ask operations and quality to agree a unique-part rule before collecting counts. Choose one current disposition per part at the cutoff: accepted, rejected, pending inspection or rework, or another explicitly explained category. Rework passes are events affecting an existing part, not automatically additional produced parts. A part that moves from pending to accepted should change category, not appear in both totals. Retain the earlier snapshot if the later disposition changes the commercial conclusion.

Consider a hypothetical window with 100 unique produced parts, 90 accepted, three rejected and seven still pending. The categories balance, but accepted output at that cutoff is 90, not 97 or 100. If the pending seven are accepted later, report the later quality snapshot and its timestamp. Do not silently revise the original trial result or compare the later snapshot with a manual baseline that had less disposition time.

The local output-boundary worksheet now checks this arithmetic and flags missing or overlapping counts. It deliberately does not calculate a throughput rate, infer the condition of pending parts or approve production. Use its mismatch as a request for the count source, unique-part references and a named quality owner. A balanced worksheet remains self-reported until those records are checked. If the evidence only covers the cell, keep the claim at cell level rather than borrowing line or customer acceptance.

How should the buyer compare the manual and proposed loops?

Use the same part family, mix, shift window and good-part rule for the manual baseline and the proposed automated trial. Record material starvation, machine waiting, downstream blocking and quality-release delay as separate reasons. A faster tending motion may leave the actual constraint unchanged; a slower machine recipe can still coexist with more accepted parts if the rest of the loop changes. The result must come from this site’s observed counts, not a supplier case study transferred across plants.

Before a proceed decision, inspect the event trail for the worst ordinary interruptions as well as the median cycle. If an event cannot be traced to a source and owner, call it an evidence gap. If downstream work is outside the test boundary, label the result cell output rather than line output. The accompanying worksheet turns those distinctions into a request list for the machine builder, integrator, operator and quality owner; it does not estimate throughput.

The practical next step

Bring RobotAtom one machine-tending problem with the machine, part family, demand window and current operating loop. We can structure the requirements, expose the likely constraint, compare suitable solution approaches and providers, and define a bounded pilot with measurable acceptance conditions.

RobotAtom leads the solution process but does not certify machine safety, production capability or compliance. Manufacturers, integrators and accountable site specialists remain responsible for their claims, designs and approved scope.