简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Our UR5e inspection request expires before the application reads it

EllaBennett0729 · 2025年12月27日 05:48 UTC

已关闭
EL
EllaBennett0729
The PLC trace shows our housing-inspection request asserted and cleared between two application reads. The operator sees no accepted request and presses again. This is the ordinary job interface for our UR5e fixture cell; safety is engineered separately. I want the PLC and application authors to agree receipt and clearing rather than leave the operator to guess whether a second press is new work.

16 条回复

HA
HazelChan1093

Our old instruction said to press again when nothing happened, which was easy to teach and a pain to untangle later. Is your request cleared by a timer or by something the application sends back?

25
EL
EllaBennett0729

A timer in the PLC. There is an application acknowledgement in the drawing, but the request clearing does not use it.

4
AA
AaronBaker0436

Ask the two authors to define a request identity, its acknowledgement and the conditions for clearing each, including unanswered requests. A longer pulse alone would leave the ownership question open.

20
NI
NinaChan1110

Would holding the request until it is acknowledged be an option for their review? The current timer seems to assume the application always looks in time.

6
HA
HazelChan1093

Nina, that's a sensible proposal to take to them. I'd want to hear what happens after a restart too, before turning it into the new operator instruction.

14
SO
SofiaBaker0456

What stops an old acknowledgement clearing a new request?

5
EL
EllaBennett0729

Nothing defined in the current notes. Both authors are reviewing a held request with matching identity, plus startup and late-acknowledgement cases. The revised instruction remains a draft.

20
NI
NinaChan1110

Sofia, that is the bit my suggestion skipped. Holding a signal solves only the short-window problem, not which request the answer belongs to.

5
AA
AaronBaker0436

Thank you for making that explicit, Nina. Put the late answer beside the new request in the review example; the ambiguity is easier to see than to describe.

-2
HA
HazelChan1093

Ella, does your operator screen currently distinguish requested from accepted? We found people read a lit request button as confirmation that someone had taken the job.

19
SO
SofiaBaker0456

And who answers if it remains requested?

20
EL
EllaBennett0729

Hazel, the same lamp covers both states. Sofia, the shift technician takes the call now, but the escalation detail is absent from the sheet.

19
NI
NinaChan1110

Show the waiting reason in ordinary words when they revise it. Two differently coloured lamps would still make the relief operator memorise a private code.

5
AA
AaronBaker0436

Have the shift technician join that wording review; they know what information they need from the caller and should not have to reconstruct it from button colours.

13
EL
EllaBennett0729

The technician has joined the review. Draft separates request sent and accepted, with a named escalation role; controls has not yet completed the restart cases.

11
HA
HazelChan1093

That should give the read-through a useful target. Please include somebody who has only seen the old lamp, because their old interpretation may survive your new labels.

19

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .