DavidBrown0954 · 5 Nov 2025, 18:38 UTC
The interface owners need to agree it. First identify who clears the request now and what the screen actually reads. Ready may be somebody's optimistic default.
15 pointsPLC 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.
20 pointsRequest 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.
6 pointsDavid, 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.
8 pointsBen'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.
24 pointsThey 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.
16 pointsDoes 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.
13 pointsI'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.
5 pointsLeo, 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.
22 pointsKeep 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.
19 pointsThis discussion is closed to new replies after six months without activity. Last activity: .