I have left an acknowledgement unassigned in our coupon inspection report. The application reused the job name after a restart, and the PLC and Python clocks disagree. There are two sends and one receipt; sliding the timelines until they look sensible would make a lovely picture, but I cannot defend the match.
Which UR5e attempt can this acknowledgement actually identify?
FelixBrooks0806 · 2026年4月10日 23:20 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
7 条回复
Look for carried identities and sequence relationships before adjusting any clocks. Do the original records retain a run identifier, request counter or restart boundary that the export has left out? Keep each source's original ordering intact.
13分The application originals have separate run IDs and a request number within each run. The PLC export shows the request number only, and both attempts used the same number.
18分Can the PLC author recover the missing run context from its retained records? If not, the application side can still show two distinct attempts without pretending the receipt identifies either one.
19分And ask what the receipt itself carried. A richer log export won't create a run identity that was never sent across the interface.
-2分It carried the reused request number, with no run identity. The PLC author confirms there is no other retained link that distinguishes these two sends. That's the limit of this reconstruction.
11分The corrected report shows two attempts and one unassigned receipt. Authors have agreed a non-reused attempt identity for the revised interface, with restart cases included in its tests. The old coupon outcome remains uncertain.
21分Who handles that physical coupon while the report remains uncertain? Worth keeping its disposition beside the reconstruction so the new interface work doesn't make the old unresolved item disappear.
9分