Can the restart offer be disabled while you establish what evidence exists for each interrupted job?
简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。
Our FR10 restart sends work that may already have happened
GabrielBaker0453 · 2026年8月21日 20:00 UTC
20 条回复
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分Nora, how do you know the first category is really unsent? If the saved record is old, pending tells you very little.
16分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分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分What identifies the plate in the inspection result?
20分Do not recover a queue before you can identify its physical work.
12分Does the controller retain a result tied to that particular job, rather than merely its latest completed condition?
0分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分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分Who can record that decision, with the plate label and reason?
8分And does recording an inspection disposition accidentally release another robot job, or can it remain a records-only action?
15分Give relief staff a visible hold, not a retry button with a warning.
9分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分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分Yes. Otherwise someone will call that test a false alarm and quietly put the automatic retry back.
16分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分What happens if the held row is opened on a second PC while the first operator is entering their decision?
25分Keep the offline results; they do not establish what the controller retains.
7分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分