Our FR10 request vanishes while the screen says ready

PLC clears request on a timer. Screen reads request low as ready. The application can miss the whole pulse. So yes, optimistic is the polite word.

Request low cannot tell the screen whether a job was accepted, completed or never seen. Give those events explicit meanings and owners. A retained request with matching acknowledgement is one approach to review with both teams, including restart and timeout handling.

David, what do operators do when that ready comes back? If they press again, put that actual behaviour in the review. A timing chart on its own won't show why the screen is causing trouble.

Ben's question matters. Also show the support person the failed request identity, without making the operator read a wall of diagnostic text to find out they're waiting.

They press again. In the proposed display we now show request pending, accepted and result separately. Controls is changing the pulse arrangement; the unresolved case is what survives when the app restarts.

Does the attempt identity survive on both sides? If not, a restart can leave you with a retained answer that the application cannot confidently attach to its work.

I'd include a tutor walking through that case without the developer prompting. They can tell you whether pending is clear enough to wait, or sounds like a polite invitation to try again.

Leo, PLC retains it but the app currently doesn't. That's on the change list now. Ben, tutor walkthrough is booked as part of checking the revision, not done yet.

Keep the pending work visible after restart while it is reconciled. A blank page is how the old press-again lesson returns without anyone writing it down.