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

Our FR10 restart sends work that may already have happened

GabrielBaker0453 · 2026年8月21日 20:00 UTC

回复讨论
GA
GabrielBaker0453
My plate inspection job can keep going when the PC crashes between sending it and saving the result, but the restart screen calls that pending just like a job never sent and offers it again; how do I separate those without guessing what happened to the plate?

20 条回复

TO
TobyAbbott0057

Can the restart offer be disabled while you establish what evidence exists for each interrupted job?

10
NO
NoraBrooks0844

I would distinguish a job known not to have been sent from one whose outcome is unknown, but test the actual save and send boundaries because the names alone do not establish that distinction.

23
VI
VictorAdams0098

Nora, how do you know the first category is really unsent? If the saved record is old, pending tells you very little.

16
NO
NoraBrooks0844

You need an enforced ordering in which durable intent exists before dispatch can occur, and even that leaves an uncertain interval after intent is saved; I was not suggesting relabelling the current rows.

2
GA
GabrielBaker0453

I've turned off the restart offer in our PC application and kept the interrupted plate aside, and the current row has nothing saying whether dispatch started

16
PA
PatCampbell

What identifies the plate in the inspection result?

20
JO
John_Cook

Do not recover a queue before you can identify its physical work.

12
KA
KaiCarter0976

Does the controller retain a result tied to that particular job, rather than merely its latest completed condition?

0
GA
GabrielBaker0453

The plate has an inspection label but the controller result we're reading has no job identity, so I cannot use that last completed value to clear this row

20
VI
VictorAdams0098

That rules out automatic reconciliation from this value. It doesn't rule out an authorised inspection decision about the held plate. Those are different jobs for the recovery screen.

13
PA
PatCampbell

Who can record that decision, with the plate label and reason?

8
TO
TobyAbbott0057

And does recording an inspection disposition accidentally release another robot job, or can it remain a records-only action?

15
JO
John_Cook

Give relief staff a visible hold, not a retry button with a warning.

9
GA
GabrielBaker0453

Quality has identified the plate and kept it on hold while they decide how to inspect it; our software maintainer is separating that decision from any new dispatch

23
NO
NoraBrooks0844

When the maintainer tests this, include a crash after saving intent but before sending, since that will deliberately produce an uncertain record even though no physical job happened.

8
VI
VictorAdams0098

Yes. Otherwise someone will call that test a false alarm and quietly put the automatic retry back.

16
GA
GabrielBaker0453

Offline interruptions now leave a hold after intent is saved, whether the fake receiver gets the job or not, and an older pending row also stays held rather than being converted to unsent

13
KA
KaiCarter0976

What happens if the held row is opened on a second PC while the first operator is entering their decision?

25
PA
PatCampbell

Keep the offline results; they do not establish what the controller retains.

7
GA
GabrielBaker0453

Thanks Toby, the records-only question caught a shared button handler that could have sent work again; that is separated now, but the second-PC case and the real controller evidence still need work

13

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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