the same inspection name belongs to two attempts
AlexAli0211 · 25 Mar 2026, 00:12 UTC
18 replies
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
19pointsPython 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.
5pointsDoes the controller retain that sequence with the request?
17pointsController history retains it, but the corresponding Python request details are missing. We have two attempted submissions under the same name.
7pointsClock 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.
9pointsIs the offset between clocks known for the occurrence, or measured only now?
13pointsOnly now. One laptop clock was corrected after the incident. I can't safely apply its current difference to those old lines.
5pointsWhat 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.
17pointsAnd keep timeout distinct from a rejected inspection.
21pointsIt 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.
8pointsThen change the explanation around that held state with quality. The operator shouldn't need this entire thread to discover what failed means.
17pointsFor the next recorder, retain an application attempt identity that is not reused on restart and its explicit relationship to the PLC exchange reference.
22pointsAuthor 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.
9pointsThat'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.
8pointsTest a restart with an old receipt arriving after a new attempt exists.
8pointsThat replay is specified, including the old receipt remaining associated only when its explicit identity matches. Unknown receipts stay unresolved. The implementation is not finished.
14pointsHas the covering operator seen the new held-state wording?
8pointsYes. 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.
18pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .