I'm reviewing our non-safety job handshake for fixture inspection with Universal Robots UR5e in a sample-checking cell with separate safety controls, using a reference plate. 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.
@AmyBarnes0554 Does your trace show when the PLC request is raised and cleared relative to application polls, including which side performs the clearing?
I've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.
@AmyBarnes0554 Draft one writer and clear conditions for each field, then review a request retained until matching acknowledgement with the interface owner. That should settle the handshake offline.
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.
@HarishCarter1011 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.
On my interface, both sides cleared acknowledgement for different reasons. Each program looked reasonable alone. Put them together and the answer vanished.
@WillBrooks0835 Our code also lets both sides clear the acknowledgement. I've identified the competing conditions and will bring them to the interface review for an explicit decision.
@SofiaBennett0717 Use the interface's explicit definition. An acceptance acknowledgement is distinct from completion, so both meanings need separate representation if both are required.
@NathanChan1069 Our review will distinguish accepted from completed. I want a delayed result to look delayed, not mysteriously finished because a request was seen.