fr5 request disappears before the application can say it received it

Timer. The application raises its receipt briefly and clears that itself. There is no shared rule matching receipt to a particular request, just the current plate label in both displays.

At what point does the application issue receipt: seeing the request, saving it, or starting inspection? The authors need to agree that meaning before they choose the clearing sequence.

Our screen once used running for a request sitting in a queue, and cancellation made that distinction very obvious when the queued work appeared later; the friendly word was hiding the event we actually needed to know about.

What does Ben's operator see while waiting? Is it also running, or can they tell whether the request was received?

Running appears as soon as the request is sent. We cannot tell from that screen whether the application saw it. The current callback issues receipt when it sees the request, before saving it.

Show waiting for receipt separately from received and waiting to start. That distinction helped with our interface wording. Ben's authors still have to define the events, but the operator shouldn't need to read raw flags to tell those waits apart.

Retain the request identity across interruption. A reused plate label cannot distinguish a late receipt from a receipt for its next attempt.

Authors are drafting a retained request and matching receipt identity. The PLC will own its request, the application its receipt. We still need the exact clearing and cancellation rules; naming the owners hasn't supplied those automatically.

Who decides a request is cancelled if the application has already received it? A sender clearing a field isn't necessarily a receiver abandoning work.

Callum, was your queued request saved across restart? Ben's receipt currently happens before storage, so that is another uncertainty the word received might conceal.

Ours was only in memory at that point, Ada, so restarting lost it; the later-start case was without a restart, and we had to describe both instead of using one vague queued state for everything.

The proposed receipt now means the application has durably accepted that identified request. Completion is separate. Authors have written the normal clearing sequence, but cancellation after receipt and a late reply still need an agreed outcome.

Then show cancellation pending as its own unresolved state in the draft. Don't call it stopped just because the sender no longer wants the inspection.

Can the sender create another attempt before that cancellation is settled? I'd walk that example on paper, with the old receipt arriving beside the new request. That's where your reused label would be especially misleading.

Use the same plate and two distinct attempts in that walkthrough. Include another restart while the cancellation is unresolved, not only a restart after everyone has agreed the final state.

The paper example exposed exactly that gap: the sender draft allowed a new attempt while the receiver still owned the previous request. Authors are revising that transition and its recovery owner. Thanks Luca; that was more revealing than another debate about pulse duration.

Keep that example with them until both sides give the same answer. Otherwise the operator ends up arbitrating two programs that each think the other one finished cancelling.