Why are both UR5e suppliers agreeing to ready while describing different events?
TobyBaker0492 · 7 Feb 2026, 10:39 UTC
15 replies
Keep both events. Give them different names.
20pointsWrite the normal case with a delay between receipt and availability. Ask each supplier what it sends and what it waits for at each point. If their definitions disagree, that simple example should expose it without either team writing code.
8pointsThe operator needs that distinction too. Received can be useful progress, but a screen saying ready while the machine is still occupied would invite the wrong explanation of the wait.
17pointsWhat happens if receipt arrives after the request has been abandoned?
-7pointsMachine supplier will name receipt separately. Integrator agrees that is not loading permission. We've added Yasmin's late-receipt case, but still need the machine owner to define what actually establishes availability.
7pointsAsk for the physical conditions behind that availability, not only another renamed signal. Otherwise the word changes and the same disagreement survives underneath it.
6pointsI'd walk the delayed and abandoned cases on paper with both teams, using one identified request throughout, before buying a test of two different interpretations.
16pointsInclude what each side records when it receives the event; otherwise the first fault report may contain two clock times and no shared request identity to connect them.
7pointsWho owns recovery if the bush has moved but the reply is lost?
10pointsLucy's case deserves its own review. A retained request identity helps connect messages, but somebody must establish the physical state before deciding what happens next. That work should not become an unnamed operator responsibility in the finished handover.
18pointsA timeout mustn't quietly become permission to load again.
22pointsOn a fleet handover I helped with, accepted meant the job had reached a queue. The floor team heard it as work started and called every ordinary queue delay a fault. We changed the display and walked through a delayed job with them. Toby's machine interface has more serious consequences, but the ordinary-language misunderstanding is familiar.
5pointsPaper review now separates request receipt, machine availability and completion, with the active request identified on both sides. The machine owner supplied the availability conditions. Lost-reply recovery is still being assigned; no automatic second request in that uncertain case.
5pointsWill the cover operator see waiting for machine availability, rather than a generic not ready? That wording would explain a normal wait without sending them hunting for a failed request.
15pointsThey do in the draft. Cover operator understood the delayed-availability example in our walkthrough. Their question was who owns the uncertain bush after a lost reply, so that recovery assignment still needs finishing. Thanks, Lucy, for putting that case on the table.
7pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .