Universal Robots UR5e: Recovering inspection-cycle execution bookkeeping across a crash

SaraAllen0287 · 7 Jun 2026, 20:13 UTC

Reply to discussion
SA
SaraAllen0287
I'm fixing our startup bookkeeping after a crash between sending a inspection-cycle execution request and saving its result. The setup uses Universal Robots UR5e in a workshop fixture inspection cell, with a fixture-mounted bracket. The robot may have continued while our file stayed pending, and startup automatically resubmits pending jobs. That state currently covers both unsubmitted and uncertain work.

13 replies

LU
LucyBaker0480
Replying to SaraAllen0287

What is the last durable entry for this attempt? Compare it with matching acceptance evidence, without letting startup resend it.

14 points
SA
SaraAllen0287
Replying to LucyBaker0480

@LucyBaker0480 I've found persisted submission intent and matching acceptance in the controller history, without a surviving completion record. This attempt is excluded from our automatic resend queue.

7 points
LU
LucyBaker0480
Replying to SaraAllen0287

Preserve the uncertain attempt and use matching evidence for reconciliation. An offline crash replay plus a local transaction for state and count should provide atomic recovery.

5 points
PA
PavelAllen0266
Replying to LucyBaker0480

A local database transaction can couple your state and count, but it doesn't make remote acceptance atomic with them. Your recovery claim needs that limitation.

19 points
LU
LucyBaker0480
Replying to PavelAllen0266

@PavelAllen0266 Exactly; my wording was too broad. The transaction protects local accounting. Remote acceptance can still be uncertain after a crash, so reconciliation remains necessary.

13 points
SA
SaraAllen0287
Replying to LucyBaker0480

@LucyBaker0480 So persist intent first, but don't treat intent as proof of sending? That's where our pending label got stretched beyond usefulness.

15 points
LU
LucyBaker0480
Replying to SaraAllen0287

Correct: persisting intent records the local decision to submit. Evidence of sending, remote acceptance and completion are separate observations and shouldn't be inferred from it.

9 points
LO
LouisBrown0920
Replying to LucyBaker0480

If there's no acceptance saved locally, why not call it unsubmitted? Isn't that the only record startup can use?

5 points
LU
LucyBaker0480
Replying to LouisBrown0920

The remote side may accept the request before the application persists its acknowledgement. Crashing between those events makes missing local acceptance insufficient to classify the attempt as unsubmitted.

4 points
TO
TobyChen1188
Replying to LucyBaker0480

@LucyBaker0480 On my ledger, we simulated crashes before send but forgot the gap after remote acceptance. All the restart tests passed for the easy half.

10 points
SA
SaraAllen0287
Replying to TobyChen1188

Our offline replay will interrupt between remote acceptance and local acknowledgement persistence, then verify that startup preserves uncertainty without issuing another request.

1 points
SA
SaraAllen0287
Replying to SaraAllen0287

The classification question is answered: our evidence supports acceptance but no final result. This attempt stays out of automatic resubmission, and the startup fix still needs to pass the offline crash replay.

11 points
LU
LucyBaker0480
Replying to SaraAllen0287

You've resolved where the attempt belongs without claiming a completion you don't have. The startup verification remains clear.

16 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.