Why does my UR5e dashboard find a status inside a failed reply?

RosaAllen0292 · 1 Jul 2026, 14:29 UTC

Reply to discussion
RO
RosaAllen0292
Changed the software environment and our availability screen still looks reassuring, even when the request fails. The old SDK gave us a status value; this environment returns a container with more information. I'm comparing them on the maintenance bench. What should I inspect before I teach the screen another wrong interpretation?

11 replies

LE
LeoBaker0449
Replying to RosaAllen0292

Compare a saved successful response and a failed one with the documentation for that installed SDK. A plausible number inside a container is not necessarily the status you asked for.

5 points
RO
RosaAllen0292
Replying to LeoBaker0449

Found our adapter taking the last numeric field regardless of the result indicator. On the failed example it's diagnostic information, not an availability value. So the screen is helpfully decorating an error with a status name.

16 points
VI
VictorBaker0446
Replying to RosaAllen0292

Does the old environment also have a defined failure form, rather than always returning a usable status?

13 points
SA
SamCarter1029
Replying to RosaAllen0292

Test a failure before the first success too; there should be no invented previous reading.

8 points
LE
LeoBaker0449
Replying to VictorBaker0446

Victor's question matters if both environments remain supported. I would select a documented adapter for each, with the same explicit available or unavailable result above them. Not guess the version from whatever fields happen to parse.

14 points
RO
RosaAllen0292
Replying to RosaAllen0292

Victor and Leo, the old wrapper raises a documented read error; the new one returns a failed-result container. We've mapped both to unavailable and kept unexpected shapes as errors. Sam, startup has no value until a valid success. That check is now in the saved-response tests.

9 points
VI
VictorBaker0446
Replying to RosaAllen0292

What does the user see after a successful reading followed by a failed request: the historical value or a fresh-looking one?

15 points
LE
LeoBaker0449
Replying to VictorBaker0446

I would check that on the actual screen, Rosa. The parser can be right while a separate display cache leaves the old availability label looking current.

6 points
RO
RosaAllen0292
Replying to VictorBaker0446

That's exactly where the next failure was. Parser said unavailable, screen kept its green last value. We've removed the current-state styling on failure; the optional previous reading now says last successful read with its time. Thanks Victor, the parser-only test would have missed it.

16 points
RO
RosaAllen0292
Replying to RosaAllen0292

Both supported environments now pass startup failure, success then failure, recovery, and reopen checks with the saved examples. We also ran the normal documented read in each environment and checked the display transition on a controlled read failure. No diagnostic field becomes an availability state. Fix and handover accepted by our maintainer.

9 points
SA
SamCarter1029
Replying to RosaAllen0292

Keep those saved failures with the tests, since a successful screen alone never exposed this bug.

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