Give the moments different names before choosing signal labels. Ask the machine side to describe receipt while the machine is still busy, then ask the integrator what it would wait for in that condition.
Our FR5 sleeve plan uses ready for receipt and availability
RobinCarter1034 · 27 Jun 2026, 14:32 UTC
18 replies
Agreement on ready is cheap. Agreement on what stays unavailable after receipt would be more useful.
14 pointsDoes either supplier define when its version of ready stops being true?
6 pointsMachine side clears its receipt indication on a timer. Integrator assumes ready remains available until transfer begins. We've put those statements side by side; they describe different behaviour as well as different events.
13 pointsThat comparison should include the receiver's response to loss of the indication. Otherwise changing the producer's duration may simply conceal the mismatch during the normal sequence, while leaving the transfer decision undefined when the condition changes.
22 pointsWho can establish the actual loading-area condition on the machine side?
9 pointsAnd who explains the unresolved case to the covering operator? It shouldn't become ask Robin.
1 pointsI'd walk a paper example through receipt, still busy, then unavailable again before transfer; cheaper than arguing over a signal abbreviation for another meeting.
14 pointsElliot, make the late receipt belong to its original request too. I've seen timeout discussions stop at failed, then a late answer quietly gets used for the next request because nobody specified the relationship.
6 pointsOwen, the machine controls lead owns that condition definition. Harish, the cell lead owns the recovery explanation. Elliot and Hazel, we've added the busy and late-receipt examples, with request identity visible in the paper sequence.
15 pointsHave they agreed conditions for the new availability event, or only its name?
20 pointsAmara's question matters. Two named blanks would still leave the operator with the same puzzle.
15 pointsReceipt has an agreed identity and clear rule now. Availability has a machine-side condition definition, but the integrator still wants a separate explanation of what happens if it is withdrawn while a transfer is being prepared.
23 pointsThat is a reasonable unresolved case. They need to distinguish preparation before transfer from a transfer already in progress, using the observations the design actually provides. Neither response should be inferred from the signal being called availability.
2 pointsKeep both cases in the handover review. A normal-run screenshot won't explain either one.
18 pointsHave the machine and integration leads agreed who owns that interrupted-state decision together?
22 pointsYes. They jointly own the open interrupted-state entry, and the cell lead will review the operator response with them. Receipt and normal availability are documented separately; I haven't marked the complete interface agreed.
19 pointsAt least the missing decision now has a name and owners; keep the awkward paper example with it so nobody closes the entry by demonstrating only the easy sequence.
20 pointsAdd to the discussion
Welcome to Application Robot
Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.