Our application sometimes misses the PLC's brief request for sample verification.
I'm reviewing that ordinary, non-safety handshake for Fairino FR10 in a training inspection cell with an ordinary job interface, with a fixture-mounted bracket in the setup.
Signal ownership and clearing conditions aren't clearly documented.
The safety functions are independently engineered and separate from this job interface.
Fairino FR10: Where should request ownership be written down?
MinaArcher0424 · 27 Mar 2026, 13:51 UTC
6 replies
Replying to MinaArcher0424
Does your trace show when the PLC request is raised and cleared relative to application polls, including which side performs the clearing?
24pointsReplying to TobyBrooks0840
@TobyBrooks0840 I've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.
9pointsReplying to MinaArcher0424
@MinaArcher0424 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.
13pointsReplying to TobyBrooks0840
Settle it? Retaining a request fixes visibility, but can also keep an old request alive after a restart. Identity and reset rules matter.
16pointsReplying to NoahArcher0368
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.
21pointsReplying to TobyBrooks0840
@TobyBrooks0840 Should I record readers as well as the single writer? Our existing phrase used by PLC doesn't distinguish setting, reading or clearing a field.
16pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .