Our UR5e startup treats uncertain inspection work as never sent

RuthCampbell · 21 Jun 2026, 09:02 UTC

Reply to discussion
RU
RuthCampbell
Our inspection request went out before the application crashed, but its result never reached the file; startup resends everything marked pending, including this fixture-mounted bracket job that may have continued without us.

20 replies

VI
VictorBrown0881
Replying to RuthCampbell

What did you actually observe after reopening: another outgoing request, or another inspection cycle? Those are different failures to establish.

18 points
BE
BethCarter1020
Replying to RuthCampbell

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 points
HA
HanaBennett0709
Replying to RuthCampbell

Our retry problem also reached the report. Count identity separately from whether another execution is permitted.

10 points
RU
RuthCampbell
Replying to VictorBrown0881

Victor, 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 points
MA
MarkBlair
Replying to BethCarter1020

Beth'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 points
AL
AlexBrooks0820
Replying to MarkBlair

Mark, the screen needs to say what is uncertain too, because an operator seeing failed will reasonably expect retry to be the next action.

18 points
SA
SamArcher0420
Replying to RuthCampbell

Who is authorised to reconcile the bracket's physical condition with that uncertain entry?

5 points
LI
LinBennett0705
Replying to BethCarter1020

I 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 points
BE
BethCarter1020
Replying to LinBennett0705

Lin, 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 points
RU
RuthCampbell
Replying to BethCarter1020

Sam, 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 points
VI
VictorBrown0881
Replying to RuthCampbell

Does the controller side retain anything tied to this particular request, rather than just a current finished flag?

19 points
HA
HanaBennett0709
Replying to VictorBrown0881

A finished flag alone won't identify Ruth's job. We needed identity to stop repeated observations becoming repeated counts.

23 points
MA
MarkBlair
Replying to HanaBennett0709

Hana, 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 points
RU
RuthCampbell
Replying to VictorBrown0881

Victor, 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 points
AL
AlexBrooks0820
Replying to RuthCampbell

That 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 points
BE
BethCarter1020
Replying to RuthCampbell

For 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 points
LI
LinBennett0705
Replying to RuthCampbell

Ruth, has the startup change been exercised yet? I am interested in what the operator sees on the second reopen, not just the first.

8 points
SA
SamArcher0420
Replying to RuthCampbell

And who can release that hold after the cell lead's review?

7 points
RU
RuthCampbell
Replying to LinBennett0705

The 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 points
MA
MarkBlair
Replying to RuthCampbell

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