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分

讨论已关闭

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