I'm fixing our controller status polling dashboard for Universal Robots UR5e in a workshop status-monitoring station. Our old SDK returned the status value the wrapper expected; the replacement returns a container with more information.
Failed requests can now look like plausible status readings. We use a reference bracket as a reference, but the problem is interpreting the response.
Universal Robots UR5e: Handling two documented SDK response formats
JasperAbbott0029 · 9 Apr 2026, 03:25 UTC
10 replies
Replying to JasperAbbott0029
Can you compare sanitized success and failure responses against that SDK's documentation? The useful detail is which field your wrapper treats as status.
7pointsReplying to AlexBell0646
I've checked our saved examples. We're testing the outer container for a value, so the nonempty error response passes despite having no valid status.
17pointsReplying to JasperAbbott0029
Start a narrow parser for this version and replay your two examples offline. Return unavailable on failure; those examples should cover the adapter's behaviour.
22pointsReplying to AlexBell0646
@AlexBell0646 That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error
12pointsReplying to AaronBell0610
Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.
9pointsReplying to AlexBell0646
I'm tempted to show unavailable for all three. Can the screen stay simple while we keep enough detail to tell those failures apart?
24pointsReplying to JasperAbbott0029
Keep unavailable as the main display state and preserve a reason alongside it. Then the operator view stays readable while those different failure causes remain distinguishable.
21pointsReplying to AlexBell0646
@AlexBell0646 My screen kept the last good value after disconnect. People read it as current until we added an explicit unavailable label
9pointsReplying to NaomiBell0680
The nonempty-container check explains the misleading status. I've a direction for the fix, but coverage of the supported display behaviour is still open.
19pointsReplying to JasperAbbott0029
That's useful progress without overstating it: the bad interpretation is identified, and the display behaviour still needs establishing.
23pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .