Retained UR5e completion counted on every new connection

ZaraAllen0308 · 22 Mar 2026, 00:37 UTC

Reply to discussion
ZA
ZaraAllen0308
The first reconnect read finds a completion already in our plate-check history, then adds another completed check. I want its job identified without clearing the retained result or resending inspection.

11 replies

CL
ClaraBrooks0785
Replying to ZaraAllen0308

Compare the retained attempt identity with saved processed history. What identifies the result besides the completion flag? The connection's first observation is not necessarily the producer's first completion.

0 points
ZA
ZaraAllen0308
Replying to ClaraBrooks0785

Job counter and plate label survive with the result. Our seen list belongs to the connection and starts empty.

13 points
EL
EllaBarnes0555
Replying to ZaraAllen0308

Move that check to retained history, but confirm the job counter's scope first. Does it start again when its producer restarts?

5 points
ZA
ZaraAllen0308
Replying to EllaBarnes0555

Yes. Producer restart resets the counter, so counter plus plate label could match an earlier run too.

13 points
DA
DanielBell0652
Replying to ZaraAllen0308

Have the author provide a retained run identity with the attempt reference. Making the laptop remember more won't fix a producer identity that gets reused.

1 points
LE
LeoBaker0449
Replying to ZaraAllen0308

Keep the old ambiguous entries unresolved where the run cannot be recovered. Do not invent a run link merely to make the new key fit existing history.

17 points
CL
ClaraBrooks0785
Replying to DanielBell0652

Has the author settled that run identity, Zara?

3 points
ZA
ZaraAllen0308
Replying to ClaraBrooks0785

Yes. Revised records include producer run and attempt identities. Reconnect now reconciles known results through saved history; old entries without a recoverable run link stay marked for review.

3 points
EL
EllaBarnes0555
Replying to ZaraAllen0308

Test a repeated delivery within one run and the same counter in a new run. The first should be one record; the second must not disappear as a duplicate.

13 points
DA
DanielBell0652
Replying to ZaraAllen0308

And assert that reconnect sends no new inspection request. The bookkeeping repair should not acquire a helpful retry on its way through the code.

14 points
ZA
ZaraAllen0308
Replying to DanielBell0652

Both run-scope cases passed, including application restart. The recorded commissioning replay also sends no new request on reconnect. Saved history and displayed check totals agree; unmatched old entries remain visible for review.

9 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.