Our FR10 training station sometimes misses a PLC inspection request. The request is a brief pulse, then the application reports nothing received. I am trying to write a handover, but neither developer has specified who clears each ordinary job signal. Where should their agreement start?
What does the PLC expect to see before clearing the request? If the answer is merely that enough time passed, your handover cannot tell the next person whether the application actually took the job.
It expects nothing back before clearing. The application is supposed to catch the pulse. Developer suggests polling faster; PLC programmer suggests keeping the pulse longer.
Neither change settles delivery. Agree an acknowledgement and the conditions for clearing, then test a delayed application instead of assuming it always polls on time
Do a paper exchange first. One person plays the PLC, one the application, and you interrupt them halfway. Less entertaining than buying new hardware, but it makes missing ownership painfully clear.
Start with precise meanings for requested, accepted, busy and complete. Acceptance of a request should not be read as an accepted inspection result. What terms are on the current screen?
Requested and done. Done is used for receipt in one note and finished inspection in another. We are splitting those meanings before drawing the revised exchange.
Please include what happens to the report when a request was never seen, because I can already imagine 'no result' becoming 'failed plate' in somebody's summary and sending quality after the wrong problem.
And don't turn a missing acknowledgement into automatic resubmission. The receiver may have accepted the request before the reply was lost. You need attempt identity and a recovery rule.
Paper review showed that gap. Draft now has acceptance tied to a request identity and a separate result. Retention through restart is still disputed between the developers.
Give the shift one recovery contact and make the unresolved state visible, because a tidy signal table is little comfort to someone trying to find out whether their plate has been checked.
I would have the interface owner define where the authoritative attempt record lives. Both sides may retain information, but their disagreement cannot be delegated to an operator choosing the more plausible screen.
Use that as an explicit offline event sequence once they agree the interface, rather than adding random delays and hoping the awkward order happens during the demonstration.
Rachel, who is actually allowed to settle the disagreement? You may need someone owning the whole interface, not another meeting where each supplier explains its own half correctly.
Our controls lead owns the combined interface now. Ella, shift lead will escalate unresolved attempts to maintenance. Orla, result-during-disconnect was missing and is now on the review list.
Thanks for answering the separate cases, Rachel; I'd also keep receipt, completed inspection and quality disposition separate in the report, because 'done' has already been doing three jobs in this discussion.
Did the developers agree where the retained identity comes from? The paper exercise earns its keep only if the implementation has the same information, not a number invented for the drawing.
They agreed a retained attempt reference in the revised contract. Existing ambiguous attempts stay under review. Offline checks are next, including lost acknowledgement and result during disconnect; the training station is not released on the new interface yet.