I'm reviewing our non-safety job handshake for part inspection with Fairino FR10 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.
Who owns clearing the job handshake? (Fairino FR10, part inspection)
ChenAli0181 · 2026年7月9日 06:14 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
8 条回复
回复 ChenAli0181
@ChenAli0181 Can you compare the request trace with your application's polls? Also note which side clears the request.
11分回复 MayaChen1171
Our trace shows it rising and falling between two polls. The PLC clears it without an observed acknowledgement. No wonder the application misses it.
4分回复 ChenAli0181
@ChenAli0181 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.
12分回复 MayaChen1171
Settle it? Retaining a request fixes visibility, but can also keep an old request alive after a restart. Identity and reset rules matter.
14分回复 LeahBell0669
You're right; my conclusion skipped necessary cases. Retaining the request addresses visibility, while identity, clearing ownership and restart behaviour must also be reviewed.
25分回复 MayaChen1171
Would your table include who reads each field too? Our notes say used by PLC, which could mean practically anything.
16分回复 ChenAli0181
@ChenAli0181 Include the writer and readers alongside the field's meaning and the conditions for setting and clearing it, with examples showing the permitted transitions.
8分回复 MayaChen1171
My setup had two programs clearing the acknowledgement under different conditions. Reviewing them together exposed a conflict that wasn't apparent from either program in isolation.
20分