Universal Robots UR5e: A handshake built from notes and assumptions

JamieBaker0469 · 13 Aug 2026, 03:57 UTC

Reply to discussion
JA
JamieBaker0469
i'm reviewing our non-safety job handshake for sample verification with Universal Robots UR5e in a PLC-coordinated fixture inspection cell, using a fixture-mounted bracket. The PLC sends a brief request, and our application sometimes misses it. i can't find anything clear about who owns each signal or when it gets cleared. Safety functions are independently engineered; this is the ordinary job interface.

12 replies

HA
HassanBarnes0530
Replying to JamieBaker0469

@JamieBaker0469 Can you compare the request trace with your application's polls? Also note which side clears the request.

12 points
JA
JamieBaker0469
Replying to HassanBarnes0530

i've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.

1 points
HA
HassanBarnes0530
Replying to JamieBaker0469

@JamieBaker0469 Take an ownership table and a retained-request proposal to the interface owner. A request held until matching acknowledgement should settle the handshake in an offline review.

5 points
RE
ReeceBarnes0558
Replying to HassanBarnes0530

Holding the request addresses the missed pulse, but it doesn't settle the interface. A retained request needs identity and restart rules to avoid being mistaken for new work

-5 points
HA
HassanBarnes0530
Replying to ReeceBarnes0558

@ReeceBarnes0558 Yes, I overstated that. Retention addresses the missed pulse. The offline review also needs matching identity, reset ownership and restart cases before the design is complete.

19 points
JA
JamieBaker0469
Replying to HassanBarnes0530

@HassanBarnes0530 Would your table include who reads each field too? Our notes say used by PLC, which could mean practically anything.

17 points
HA
HassanBarnes0530
Replying to JamieBaker0469

@JamieBaker0469 Yes: writer, readers, meaning, set condition and clear condition. Then give each legal transition a concrete example.

3 points
GR
GraceBell0668
Replying to HassanBarnes0530

On my interface, both sides cleared acknowledgement for different reasons. Each program looked reasonable alone. Put them together and the answer vanished.

12 points
JA
JamieBaker0469
Replying to GraceBell0668

@GraceBell0668 i've checked our assignments and found that too: both sides can clear acknowledgement. i'll put both conditions in the review rather than quietly choose one.

-2 points
RE
ReeceBarnes0558
Replying to JamieBaker0469

Good. Renaming the field won't remove the second writer. The agreed ownership needs to match both programs

13 points
JA
JamieBaker0469
Replying to ReeceBarnes0558

i haven't established reliable request and acknowledgement behaviour for our interface. Finding the missed transient doesn't complete that design.

4 points
HA
HassanBarnes0530
Replying to JamieBaker0469

@JamieBaker0469 Understood. One explained transient doesn't amount to a verified request-and-acknowledgement design.

17 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.