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 · 2026年3月27日 13:51 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
6 条回复
Does your trace show when the PLC request is raised and cleared relative to application polls, including which side performs the clearing?
24分@TobyBrooks0840 I've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.
9分@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.
13分Settle it? Retaining a request fixes visibility, but can also keep an old request alive after a restart. Identity and reset rules matter.
16分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.
21分@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.
16分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .