Separate request acceptance from the inspection result. A timeout waiting for acceptance says nothing about the bracket's quality. Then define who owns and clears each part of the exchange.
简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。
Our UR5e screen calls a missed request a rejected bracket
CallumChen1143 · 2025年11月1日 14:58 UTC
15 条回复
Take rejected off that timeout path in the lesson draft now. We have been withholding a similar exercise until the normal and interrupted exchanges are agreed. It is a bad habit to teach confidently.
2分The rejected wording is out of the draft; the application owner confirms it is only a timeout label, not an inspection result.
12分Our reset-button review found the same problem from the other direction: a message action changed job state. Keep the request visible when explaining this timeout, so dismissing the message does not imply the work was cancelled.
9分Could the operator tell whether to wait or call somebody? Unknown is more honest, but a screen full of honest words can still leave them guessing what to do next.
10分Isabel's point matters if you add cancellation. A cancellation request needs an agreed response; do not treat pressing cancel as proof the receiver never accepted the inspection.
8分Hazel, yes. We used a paper screen with the person covering breaks and found the missing action immediately. Cheaper than discovering it during the practical session.
18分Mei, did your paper example use only information the real screen could obtain? I would not want a beautifully clear explanation of an acceptance state the interface never supplies.
5分That was a gap we had to fix. The walkthrough must use the actual agreed fields, not give the operator facts only the developers know. Thanks for making the limitation explicit.
7分Our current screen has no acceptance identity, just a connection indicator; I've asked both owners to define a matching acceptance and its retained information before we draw the recovery page.
6分Then the connected indicator cannot answer the question. I would show the failed request wait plainly and route it to the named support role until the new exchange exists.
18分Also agree whether the receiver durably retains an accepted request before the PLC clears it. An acknowledgement that disappears with the application process can leave the sender believing work is owned when it is not.
9分That storage boundary is still open; the two owners have agreed one writer for each signal, but no revised exchange has been tested.
13分Keep result unavailable distinct from no request accepted in the design too. They may both need attention, but the original bracket question differs.
12分Will someone outside the design meeting try the next paper version? Let them tell you what they think happened before explaining it to them.
10分讨论已关闭
此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .