简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

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

SaraAllen0287 · 2026年6月7日 20:13 UTC

回复讨论
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 条回复

LU
LucyBaker0480

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

14
SA
SaraAllen0287

@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
LU
LucyBaker0480

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
PA
PavelAllen0266

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
LU
LucyBaker0480

@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
SA
SaraAllen0287

@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
LU
LucyBaker0480

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
LO
LouisBrown0920

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

5
LU
LucyBaker0480

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
TO
TobyChen1188

@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
SA
SaraAllen0287

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

1
SA
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
LU
LucyBaker0480

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

16

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。