Our FR5 coupon inspection timed out, then the Python application restarted and reused the job label. I have a later acknowledgement in the PLC log, but the clocks disagree and I cannot tell which attempt owns it. I want the support account to show what we know without assigning that receipt by guesswork.
the same inspection name belongs to two attempts
AlexAli0211 · 2026年3月25日 00:12 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
18 条回复
回复 AlexAli0211
Keep each source's event order first. Look for an exchange identity or sequence field that survives across the systems, rather than matching the reused job name by the nearest clock time
19分Python has the reused name and a local counter that restarted too. The PLC acknowledgement has a sequence value, but Python did not save that value.
5分回复 AlexAli0211
Does the controller retain that sequence with the request?
17分Controller history retains it, but the corresponding Python request details are missing. We have two attempted submissions under the same name.
7分回复 AlexAli0211
Clock correction may narrow the window, but it won't create the link Python never recorded. Don't let a neat merged timeline make that receipt look assigned.
9分回复 AlexAli0211
Is the offset between clocks known for the occurrence, or measured only now?
13分Only now. One laptop clock was corrected after the incident. I can't safely apply its current difference to those old lines.
5分回复 AlexAli0211
What does the operator screen call the timed-out coupon at the moment? That's the bit somebody will act on while the logs are being untangled.
17分And keep timeout distinct from a rejected inspection.
21分It says check failed, which reads like a rejected coupon. Quality has the piece held because its inspection result is unassigned, not because a defect was found.
8分回复 AlexAli0211
Then change the explanation around that held state with quality. The operator shouldn't need this entire thread to discover what failed means.
17分回复 AlexAli0211
For the next recorder, retain an application attempt identity that is not reused on restart and its explicit relationship to the PLC exchange reference.
22分Author is adding that relationship. Support has accepted the existing event order with the acknowledgement unassigned, and is investigating the timeout without waiting for an impossible exact match.
9分回复 AlexAli0211
That's useful. Keep the known controller and PLC sequence in the ticket even though the Python side is incomplete. Uncertain ownership doesn't make every event useless.
8分Test a restart with an old receipt arriving after a new attempt exists.
8分That replay is specified, including the old receipt remaining associated only when its explicit identity matches. Unknown receipts stay unresolved. The implementation is not finished.
14分Has the covering operator seen the new held-state wording?
8分Yes. They identified the coupon as awaiting reconciliation, not rejected, and named quality as the next contact. The historical receipt still cannot be assigned; we have closed the misleading wording, not the old inspection outcome.
18分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .