I'm fixing our controller availability reporting dashboard for Universal Robots UR5e in a training cell with a read-only dashboard. 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 sample housing as a reference, but the problem is interpreting the response.
The SDK changed shape and my parser didn't
AnikaBrooks0856 · 2026年6月8日 08:52 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
9 条回复
Can you compare sanitized success and failure responses against that SDK's documentation? The useful detail is which field your wrapper treats as status.
25分回复 LucyBell0654
Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant.
2分@AnikaBrooks0856 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.
17分回复 LucyBell0654
That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error.
-4分Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.
20分回复 LucyBell0654
@LucyBell0654 Can our screen just say unavailable, but retain the reason?
6分@AnikaBrooks0856 Yes. One unavailable display state, distinct reasons in the result.
17分回复 LucyBell0654
I can't yet trust our displayed status across the supported responses. Finding the container check explains a bug, but doesn't give me a verified replacement parser.
11分That status fits the gap you've described: a diagnosed mistake, with the replacement still unverified.
22分