简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Who owns clearing the job handshake? (part inspection)

AdaAllen0303 · 2026年6月3日 04:36 UTC

回复讨论
AD
AdaAllen0303
I'm reviewing our non-safety job handshake for part inspection with Fairino FR5 in a training inspection cell with an ordinary job interface, using a sample housing. 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.

21 条回复

LI
LinBennett0705

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

9
AD
AdaAllen0303

Our trace shows it rising and falling between two polls. The PLC clears it without an observed acknowledgement. No wonder the application misses it.

17
LI
LinBennett0705

@AdaAllen0303 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.

14
OS
OscarBaker0445

@LinBennett0705 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.

21
LI
LinBennett0705

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.

11
AD
AdaAllen0303

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

5
LI
LinBennett0705

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

5
EL
EllaArcher0381

@LinBennett0705 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.

9
AD
AdaAllen0303

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.

3
OS
OscarBaker0445

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

20
NA
NadiaBennett0726

@LinBennett0705 Does the acknowledgement indicate that inspection is complete, or might it only mean the request was accepted?

21
LI
LinBennett0705

That depends on the defined interface. If it means accepted, completion needs a separate event. Don't make readers infer which meaning you intended.

9
AD
AdaAllen0303

@LinBennett0705 Our review will distinguish accepted from completed. I want a delayed result to look delayed, not mysteriously finished because a request was seen.

-1
EL
EllaArcher0381

@AdaAllen0303 A step-by-step example from idle to acceptance and completion, showing each field's value, can reveal missing transitions in the proposed interface.

3
NA
NadiaBennett0726

@EllaArcher0381 Should the offline review also follow a request that receives no acknowledgement, rather than only the successful sequence?

7
LI
LinBennett0705

@NadiaBennett0726 Yes. Show timeout as an unresolved exchange, with the defined owner responsible for recovery. Don't turn absence of acknowledgement into an automatic resend rule.

12
AD
AdaAllen0303

I'll add that case to our offline examples. The missing pulse and a retained but unanswered request need different descriptions.

3
OS
OscarBaker0445

What if acknowledgement belongs to an older request? Holding bits longer won't answer that.

21
LI
LinBennett0705

@OscarBaker0445 Add it as a mismatched-identity case. The interface owner needs to define how the supported exchange links a response to its request.

4
AD
AdaAllen0303

@LinBennett0705 I've answered why this request can be missed: our trace shows it entirely between polls. I'll treat the handshake fix as complete only after the interface owner reviews ownership and the relevant offline transitions.

-2

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。