Our dashboard for read-only mode reporting on Universal Robots UR5e expected a status value from the old SDK. The replacement environment returns a container with extra information, and our screen now shows a plausible status even when a request fails.
This is in a workshop status-monitoring station, with a sample housing as a reference. I'm trying to fix how we interpret the answer.
Handling two documented SDK response formats - read-only mode reporting
SaraBarnes0548 · 1 Sept 2026, 13:26 UTC
6 replies
Replying to SaraBarnes0548
Got sanitized success and failure examples? Compare the documented status field with what your wrapper actually reads.
7pointsReplying to DanielBaker0478
Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant.
14pointsReplying to SaraBarnes0548
Replay both offline with a version-specific parser. Failure should return unavailable. That pair should cover the adapter.
14pointsReplying to DanielBaker0478
That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error.
25pointsReplying to ClaraAllen0263
Fair point; I overstated coverage. Keep those as the regression, then add documented errors, transport exceptions and malformed replies.
12pointsReplying to DanielBaker0478
@DanielBaker0478 Can our screen just say unavailable, but retain the reason?
8pointsAdd to the discussion
Welcome to Application Robot
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.