The PLC raises and clears our ordinary inspection request between application polls, so some reference-plate requests disappear; I want the PLC and application authors to agree who retains the request and what receipt means before this FR5 job interface is handed over, separate from the engineered safety functions
Have the PLC retain the identified request until a matching receipt is acknowledged, with clearing and restart rules agreed by both authors; making the pulse longer still leaves a polling gap to argue about
They agree about retaining it, but the application author calls starting inspection the receipt while the PLC author only means storing the request; that disagreement is now visible in their example sequence
Separate receipt from availability and completion in that sequence, because the application may retain a request while still unable to inspect its plate.
Does the application actually store it before acknowledging? I've tested interfaces where received meant the handler had begun, and a restart inside the handler left no record. Both sides could honestly think the other one still owned the request.
Both. We moved receipt after the agreed retained record, and still reconciled unresolved work after restart. Storage alone didn't tell us whether the physical inspection had happened before the interruption.
Our authors are now walking retained request, delayed availability and restart as separate cases, with the same attempt identity carried through; I have no approved clearing sequence yet, but the old short pulse is no longer their proposed solution