Who should retain our FR10 inspection request until receipt?

PLC author proposes holding the request to receipt. Application author currently uses receipt to mean result available. First problem is the event names.

Does the application send any separate confirmation that it accepted the request?

Ravi, put a timed-out example beside the successful one in the meeting. Otherwise everyone can agree that receipt means received and still leave the operator wondering whether to ask again. I'd want the attempt identified on that screen too, not just inspection waiting.

Sam, no separate receipt today. Authors are adding that to the design, with result availability separate. Leah, timeout and restart examples are on the same review sheet.

Who owns the request if the application restarts after receipt but before its result is saved? That should not turn into another short pulse simply because one program forgot the exchange.

Jamie, agreed. Retained identity and defined unknown outcomes belong in the design, with restart reconciliation rather than an automatic new inspection.

Does the PLC retain the same attempt identity across that restart?

The agreed design retains the exchange identity. An uncertain outcome goes to reconciliation, not ordinary submission. The first offline implementation is ready to exercise delayed receipt and application restart.

Include receipt arriving twice. We once had a reassuring confirmation retrigger the next action because the program treated each arrival as new work. It was very responsive to the wrong thing.

Duplicate receipt exposed a second-start path. Maintainer removed it; delayed and repeated receipt now attach to the same exchange. Still checking interruption during result storage.

Can the operator tell an awaiting-receipt state from an outcome under review? The response to those messages should come from the agreed sequence, not be invented by the trainer later.

Different messages now, with the defined response beside each. Storage-interruption and second-restart tests pass; uncertain exchange stays unresolved. Shift lead is using those cases for the handover walkthrough.

Did the shift lead need either author to explain the distinction? That's often where a technically correct screen loses me.

Walkthrough completed without that explanation. Installed interface checks also passed delayed receipt, repeated receipt and the defined restart cases. Old pulse-only instruction replaced. Thanks, Leah, the duplicate case caught a real second-start bug.

Keep the agreed interface revision with both program versions; that is the combination those checks covered, not every later change to either side.