Forums Programming & support Handling two documented SDK response formats - read-only mode reporting Handling two documented SDK response formats - read-only mode reporting SaraBarnes0548 · 1 Sept 2026, 13:26 UTC
Reply to discussion 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.
6 replies Got sanitized success and failure examples? Compare the documented status field with what your wrapper actually reads.
Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant.
Replay both offline with a version-specific parser. Failure should return unavailable. That pair should cover the adapter.
That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error.
Fair point; I overstated coverage. Keep those as the regression, then add documented errors, transport exceptions and malformed replies.
@DanielBaker0478 Can our screen just say unavailable, but retain the reason?
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.
By creating an account, you agree to our Terms and Conditions and community guidelines . Read our Privacy Policy for how your information is handled.