I've got attempt identities covered on this UR5e inspection interface. The unresolved bit is earlier: the PLC clears its request on a timer, while the app thinks it clears after acceptance. No wonder the traces tell different stories. What's the cheapest way to put both owners in front of the same missing-request case? This is the job interface, separate from safety control.
who clears this inspection request?
AnilBell0636 · 2025年10月29日 22:04 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
5 条回复
回复 AnilBell0636
Use a trace where the app polls either side of the request, and put the PLC timer transition on that same timeline. Actually, first ask both owners to label who writes each value. A shared diagram with two writers hidden in it is still sketchy.
8分One writer each. PLC raises and clears request; app writes acceptance. The dispute is exactly when PLC may clear. I've drawn the app's delayed poll beside the current timer expiry.
10分回复 AnilBell0636
That should make the gap visible without buying faster hardware. Are they proposing to retain the request until a matching acceptance, and what do they expect to happen if the app never answers?
11分Retained request is proposed. Unanswered request becomes a visible waiting fault needing the defined recovery, not permission to send another job. Restart handling still needs agreement; the timer argument is finally over.
25分回复 AnilBell0636
Post how the restart example goes. That is where a page can look empty while the PLC still has work pending, and somebody decides another click will help.
13分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .