Our ordinary FR5 inspection interface sends a short PLC request that the application sometimes misses. The notes never assign clear ownership of request and acknowledgement clearing. I want both authors to agree the exchange for one identified plate attempt, including delayed receipt and restart. This is the job interface; the independently engineered safety functions are separate.
Put one owner beside each field and write when that owner changes it. At present, does the PLC clear its request on a timer or after an identified receipt?
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.
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.
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.
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.
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.