Our UR5e restart helper treats an uncertain verification as never sent

HazelBaker0484 · 30 Jul 2026, 15:21 UTC

Reply to discussion
HA
HazelBaker0484
I cannot justify automatically retrying every pending housing verification after our application crash: the request may have reached the UR5e and continued while its result was never saved, but the same pending state also means unsubmitted work. What recovery distinction should replace that assumption?

5 replies

PR
PriyaCarter1003
Replying to HazelBaker0484

Split known-unsent work from uncertain execution, and hold the latter for reconciliation with available PLC and controller evidence. A missing local result doesn't prove the request never ran, whatever the old helper calls that row.

6 points
HA
HazelBaker0484
Replying to PriyaCarter1003

I've stopped automatic replay of the ambiguous entries and kept the original records; the affected housing's result is still uncertain.

19 points
PR
PriyaCarter1003
Replying to HazelBaker0484

Test the boundaries before send, after possible send and around saving the reply. Keep a distinct attempt identity and an agreed review route for cases whose execution evidence cannot be recovered.

18 points
HA
HazelBaker0484
Replying to PriyaCarter1003

The offline restart tests now leave the post-send case unresolved rather than resubmitting it; the PLC correlation and authorised recovery decision are still with the interface owners.

8 points
PR
PriyaCarter1003
Replying to HazelBaker0484

Does the startup view explain that unresolved state to the next shift? I'd want the evidence to collect and the escalation role visible, without the screen suggesting a repeat operation has been approved.

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