UR5e status container reaches our display even when the request failed

ElenaAdams0166 · 16 Aug 2026, 03:29 UTC

Reply to discussion
EL
ElenaAdams0166
Our old status wrapper expects a value; replacement SDK returns a container. Failed UR5e reads now get normal labels. Where should validation happen?

4 replies

TO
TobyAllen0318
Replying to ElenaAdams0166

At the adapter boundary, using the applicable response contract to distinguish request success from validated status data; test malformed replies and good-read-then-failure before the screen updates.

10 points
EL
ElenaAdams0166
Replying to TobyAllen0318

Contract located for this environment. Maintainer has the failed container example and a good-then-failure test. No code correction completed yet.

24 points
LI
LiamBrooks0838
Replying to ElenaAdams0166

Also include a genuine valid status that is not favourable. The adapter should not turn every negative-looking reading into a communication failure. Preserve the distinction between unavailable data and an observed condition.

6 points
EL
ElenaAdams0166
Replying to LiamBrooks0838

Offline cases now pass after the repair, including valid negative status and stale previous data. Supported-environment comparison remains outstanding. The training display is not released yet.

11 points

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.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.