Why does reconnect give our UR5e coupon another finished tick?

MarkBlair · 7 Dec 2025, 17:54 UTC

Closed
MA
MarkBlair
Our reporting app calls a retained PLC completion new work after reconnecting. Same coupon still on the bench. I'd like a traceable decision about the old check, not somebody clearing the flag until the screen looks tidy.

18 replies

LI
LiamChen1186
Replying to MarkBlair

What identity survives with the completion, apart from the coupon name?

9points
MA
MarkBlair
Replying to LiamChen1186

Recipe number and a local counter. The counter resets when the job is reopened, so its value appears in two runs. No shared run identifier in the export.

22points
AN
AnikaBell0682
Replying to MarkBlair

Does the duplicate exist in the saved report too, or only on the screen?

20points
CA
CalebAllen0319
Replying to MarkBlair

Replay the retained state offline. Keep the original history present, not an empty test database.

2points
AI
AishaBell0692
Replying to AnikaBell0682

Our shift once corrected a display total while leaving the exported report unchanged. The next planner reasonably trusted the file. I'd check both paths before describing this as a colour or counter problem.

15points
MA
MarkBlair
Replying to AishaBell0692

Both paths, Anika. Aisha's point applies: the extra row is saved, not just drawn. Developer has a replay with the existing history; the original retained state remains unassigned to either run.

14points
LI
LiamChen1186
Replying to MarkBlair

Keep that uncertainty after restart too. Otherwise the next launch forgets why it was held.

20points
CA
CalebAllen0319
Replying to MarkBlair

And repeat the same delivery. One successful reconnect test may still hide duplicate counting.

7points
AN
AnikaBell0682
Replying to MarkBlair

Who reviews the physical coupon while the software history stays uncertain?

20points
AI
AishaBell0692
Replying to AnikaBell0682

Mark, if quality can decide the physical coupon, link that reviewed decision without inventing a missing software sequence. We needed both the practical disposition and an honest explanation of why the old report changed.

24points
MA
MarkBlair
Replying to AishaBell0692

Quality owns that review. The proposed correction links its decision to the coupon and incident, leaving the unknown old attempt unassigned. I'm not treating the eventual physical decision as a recovered log.

23points
CA
CalebAllen0319
Replying to MarkBlair

Has the replay stopped another row appearing in the exported report?

19points
MA
MarkBlair
Replying to CalebAllen0319

In the developer's replay, yes. Repeated delivery stays one recorded event. Restart with the held reason retained is the next test, so not a completed fix yet.

19points
LI
LiamChen1186
Replying to MarkBlair

Include a genuinely different completion too. Rejecting everything would look impressively duplicate-free.

14points
AN
AnikaBell0682
Replying to MarkBlair

And show the held reason to whoever covers the next shift.

12points
AI
AishaBell0692
Replying to LiamChen1186

Liam's new-event case matters to the operator explanation as well. People need to distinguish waiting work, completed work and an old uncertain event without assuming every warning means they should repeat the inspection.

15points
MA
MarkBlair
Replying to AishaBell0692

New completion and retained-hold restart cases are added. Quality has released the coupon under the review process. Thanks Aisha, that kept the physical decision moving without pretending we found the missing run identity.

19points
LI
LiamChen1186
Replying to MarkBlair

Who approves the final report adjustment when those software checks are finished?

21points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .