For an engine fastening cell, define how an accepted tool result becomes a completed joint and then permits assembly release. The difficult acceptance case is a stop between those events: the tool has finished, but the station has not acknowledged the result. A useful proposal states how the product, joint and program remain identifiable through that interruption and any authorized rework.
What does each device own?
Ask for an interface description that separates the responsibilities below. The division depends on the actual tool controller and station design; the table is a proposed contract to resolve, not an assertion about the filmed equipment.
| Event or record | Question the proposal must answer |
|---|---|
| Product and intended joint selected | Which system identifies this assembly and the next physical joint? |
| Tightening program selected | How is the intended program and revision associated with that joint? |
| Tool reports a result | What identifies the attempt, and who accepts or rejects it against the agreed requirements? |
| Station acknowledges the result | What prevents a delayed or repeated message from becoming another completed joint? |
| Assembly released | Which required-joint state and unresolved-fault checks permit release? |
Robot arrival, tool completion and joint acceptance answer different questions. A single global cycle-finished signal is insufficient as an interface definition if the project needs to distinguish them.
The accompanying footage shows a white robot carrying a tool towards working positions on the side of a green engine-shaped assembly supported in a fixture. It gives a concrete fastening context for defining the additional interface and acceptance work in a similar project.
00:08 — The robot carries its tool towards the side of the supported engine-shaped assembly.
Stop after the result, before the acknowledgement
Agree a controlled demonstration at this boundary using test parts and an approved trial method. Complete an attempt at the tool, interrupt the proposed sequence before the station has confirmed it, then perform the intended recovery.
Ask the team to retrieve the attempt and show which product and joint it belongs to. Observe whether the station recognizes an already accepted result, requests a defined recovery action, or requires further disposition. A repeated transmission must not silently create another completed joint; a missing acknowledgement must not silently turn accepted work into an instruction to tighten again.
The acceptance requirement is an unambiguous outcome under the agreed interruption, not one universal communication architecture. Put the expected state after recovery in the test record. If the actual controller cannot provide the identifiers or recovery information needed, that limitation belongs in the integration scope before the station is ordered.
Which controller settings affect that outcome?
Read the proposed configuration, not just the feature list. One published tightening-controller manual allows configuration of sequence order, tool locking and whether a non-accepted result advances a batch counter. That makes it necessary to define what a station means by complete and how it uses the controller’s result.
Likewise, detecting an already-tightened joint is not the same as identifying a physical bolt location. A documented multistep restriction uses a configured torque condition and optional angle window; its usefulness must be validated for the actual joint. The cell still needs the product-and-joint association required by the project.
For the underlying difference between tool results and completed positions, see the related discussion of why a screwdriving torque result can mislead a buyer. This acceptance discussion takes the next step: demonstrating the state transition between the tool and the station.
Can authorized rework retain the original attempt?
Controller documentation shows storage and export of tightening and loosening results, program information and result traces. The project must still define the relationship between those records, the physical joint and the final assembly status.
During acceptance, retrieve a test assembly’s original attempt, subsequent authorized action and eventual disposition. Show the product identifier, joint identifier and program revision used. If only the latest accepted status remains, the record cannot explain what happened across the interruption or rework.
Agree who can authorize another attempt, how the station receives that decision and what must be resolved before release. Bring EVST the bolt map, process programs, product-identification method and required history so we can define these interface questions and acceptance demonstrations with you.