What did you actually observe after reopening: another outgoing request, or another inspection cycle? Those are different failures to establish.
Our UR5e startup treats uncertain inspection work as never sent
RuthCampbell · 21 Jun 2026, 09:02 UTC
20 replies
I'd remove uncertain entries from the runnable list first. No new hardware needed to stop the file's vague wording from becoming a second command.
4 pointsOur retry problem also reached the report. Count identity separately from whether another execution is permitted.
10 pointsVictor, the outgoing request is logged again; I cannot establish a second physical cycle from what we retained. Beth, pending currently has no distinction for possibly sent.
3 pointsBeth's hold is sensible, but don't label every uncertain job failed. Ruth's first execution might have finished perfectly while the application was having its own bad afternoon.
8 pointsMark, the screen needs to say what is uncertain too, because an operator seeing failed will reasonably expect retry to be the next action.
18 pointsWho is authorised to reconcile the bracket's physical condition with that uncertain entry?
5 pointsI want that job to remain visible. A separate state is useful. Moving it out of sight would only exchange a repeat request for forgotten work.
11 pointsLin, yes, held and visible. I meant remove it from automatic dispatch, not remove the entry. The review itself also needs to survive another application restart.
16 pointsSam, our cell lead will own the physical review; Lin and Beth, I'll keep the entry on the main screen with automatic dispatch disabled while its status is uncertain.
18 pointsDoes the controller side retain anything tied to this particular request, rather than just a current finished flag?
19 pointsA finished flag alone won't identify Ruth's job. We needed identity to stop repeated observations becoming repeated counts.
23 pointsHana, same warning for a new number after restart. Giving the retry a fresh identity doesn't make it new physical work or prove the first attempt did nothing.
7 pointsVictor, not enough retained detail to tie the current flag to this request. The cell lead has the bracket held for review; I haven't declared either execution finished.
20 pointsThat wording is useful, Ruth; could the review screen also show the last known send and why the result is missing, without presenting the flag as an answer?
3 pointsFor the software check, interrupt it around each save and send boundary with dispatch mocked. Then reopen during review. I would want to see no automatic request for every uncertain case.
20 pointsRuth, has the startup change been exercised yet? I am interested in what the operator sees on the second reopen, not just the first.
8 pointsAnd who can release that hold after the cell lead's review?
7 pointsThe mocked restart checks now leave possibly sent work held, including a second reopen, and the screen shows the last recorded send; physical review and the release responsibility are still open.
14 pointsUseful software progress. Keep the unresolved release ownership beside it in the handover; the mock proving no resend doesn't settle what happens to this bracket.
18 pointsAdd 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.
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.