Our UR5e dashboard finds a normal status inside a failed reply

RaviBrown0911 · 24 Dec 2025, 10:07 UTC

Closed
RA
RaviBrown0911
Our replacement SDK environment returns a larger reply than the old one. Dashboard still shows a sensible-looking mode when the request fails. I need the maintainer to fix the interpretation, not pick a nicer field by eye

15 replies

DA
DanielBaker0478
Replying to RaviBrown0911

What does the complete failed reply look like, with its type and SDK version? Keep a successful reply too. I'd want those beside the documented return description before deciding which part means status.

2 points
HA
HarishAllen0315
Replying to RaviBrown0911

Does the current adapter check the request outcome before reading the status field, or does it treat any nonempty response as usable?

21 points
RA
RaviBrown0911
Replying to HarishAllen0315

Any nonempty reply, Harish. Daniel, maintainer has the full success and failure examples with the environment version; both containers pass that check

8 points
FI
FionaAllen0325
Replying to RaviBrown0911

Then the happy screen is entirely believable. The wrapper asked whether something arrived, not whether it contained a valid status. Stop that failed example reaching the mode display while the mapping is reviewed.

-7 points
JA
JackAllen0341
Replying to RaviBrown0911

Our old panel kept the last good value after an error and forgot to say it was old. Will yours distinguish unavailable now from the previous successful read?

15 points
DA
DanielBaker0478
Replying to FionaAllen0325

Fiona, agreed on withholding the failed reading. I'd make the test check the visible output as well as the adapter return, or another layer can quietly put the old plausible value back.

5 points
HA
HarishAllen0315
Replying to RaviBrown0911

Use the documented outcome and field types for that version, with unsupported or malformed responses rejected; a field position alone is not a stable interpretation.

7 points
RA
RaviBrown0911
Replying to JackAllen0341

Jack, it currently doesn't show age. Proposed display separates unavailable current status from the last good reading; maintainer is adding time and connection identity to that retained value

9 points
JA
JackAllen0341
Replying to RaviBrown0911

That would have saved us a pointless cable hunt. We were studying a perfectly steady number that hadn't changed because nobody was updating it.

18 points
FI
FionaAllen0325
Replying to RaviBrown0911

Have they tested starting with a failed read? There isn't a last good value then. And change connections in the test, so one controller's old reading can't dress up as another one's history.

19 points
DA
DanielBaker0478
Replying to HarishAllen0315

Include the full malformed-response cases in the support handover. A future SDK change should fail visibly against those tests, instead of reviving the same guessing game with another container.

20 points
RA
RaviBrown0911
Replying to FionaAllen0325

Initial failure and changed connection both tested now. No invented first value; old readings stay linked to their source. Version mapping passes offline examples, installed comparison still pending

15 points
HA
HarishAllen0315
Replying to RaviBrown0911

Who owns that installed comparison and the adapter's supported-version record?

10 points
RA
RaviBrown0911
Replying to HarishAllen0315

Software maintainer with our cell technician. They've accepted the work, not completed it. Thanks Jack for the age question; our screen really did hide that

7 points
DA
DanielBaker0478
Replying to RaviBrown0911

Please post what the installed comparison finds. Useful to know whether the captured examples covered the real responses, rather than only whether the revised tests were green.

19 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .