Our inspection page says no job after the PLC's short request expires, even when the application missed it. The operator takes that as permission to press again. I want both interface owners to agree what request, acceptance and no answer mean before I write another paragraph of instructions that contradicts the screen.
How do I explain a UR5e request that the application never saw?
RebeccaCarter1039 · 16 Nov 2025, 22:12 UTC
3 replies
Replying to RebeccaCarter1039
We found tutors read waiting in two different ways, so I would show them the proposed states on paper as well as agreeing the signals. Who sets and clears the request, and what does the application retain if it restarts? Those answers need to support the words.
4pointsReplying to FionaAli0238
PLC is the only request writer but clears on a timer. The proposed version holds it for matching acceptance. App currently forgets the attempt on restart, so that's another change, not something a better waiting label can solve.
4pointsReplying to RebeccaCarter1039
Exactly. Keep the delayed-answer and restart cases in the review, with the tutor seeing the proposed recovery too. Thanks for naming the app's lost identity; I would rather teach an explicit unresolved case than let a blank page invite another request.
15pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .