our ur5e dashboard calls a failed read a mode

RebeccaBell0691 · 12 Mar 2026, 20:40 UTC

Reply to discussion
RE
RebeccaBell0691
The replacement SDK returns request status together with the mode data, and our wrapper is displaying the request status as a mode whenever it finds a number; I have both package identities and captured replies, but I am unsure whether to keep both formats in one adapter

16 replies

EL
ElliotAdams0161
Replying to RebeccaBell0691

Choose the response contract by configured package version, not by finding a convenient number.

12 points
RO
RobinBaker0512
Replying to RebeccaBell0691

Does anybody still need the old package?

1 points
RE
RebeccaBell0691
Replying to RobinBaker0512

One training laptop still uses it, Robin, so we need two known combinations during the changeover; the new package reply starts with a request status that happens to resemble a valid old mode value

13 points
RA
RaviAdams0128
Replying to RebeccaBell0691

Keep separate parsing functions if that makes the contracts obvious, then return the same application-level result to the display; a failed request needs an unavailable reading, not a guessed controller mode.

-1 points
AN
AnikaBrooks0856
Replying to RebeccaBell0691

What does the screen actually do when the reply is empty, Rebecca? The numeric coincidence is awkward, but I would also want to see the less convincing failures.

11 points
RE
RebeccaBell0691
Replying to AnikaBrooks0856

It retains the previous mode without showing its age, Anika; the wrapper treats an empty reply differently from a reply carrying an error, so we have two misleading failure paths

11 points
RO
RobinBaker0512
Replying to RebeccaBell0691

Two bugs for the price of one upgrade.

18 points
EL
ElliotAdams0161
Replying to RebeccaBell0691

Keep the last value labelled old, or clear it; don't present it as fresh.

12 points
RA
RaviAdams0128
Replying to ElliotAdams0161

I prefer retaining the last value with its time for a diagnostic screen, provided unavailable is unmistakable; ask the people using this screen which information they need during a failed read.

10 points
AN
AnikaBrooks0856
Replying to RaviAdams0128

Ravi, I'd want them to try it with a stopped update, not just choose the nicer mock-up; a small old-value note can disappear beside a large confident mode label.

19 points
RE
RebeccaBell0691
Replying to AnikaBrooks0856

Maintenance chose unavailable as the main reading and a smaller last-observed value with its time; they found the original mock-up too easy to read as a current mode, which is exactly Anika's concern

22 points
EL
ElliotAdams0161
Replying to RebeccaBell0691

What happens if the configured package and loaded package disagree?

14 points
RE
RebeccaBell0691
Replying to ElliotAdams0161

The revised adapter refuses that combination instead of trying the other parser; tests cover both known formats, request errors, missing mode data, empty responses and the package mismatch

3 points
RA
RaviAdams0128
Replying to RebeccaBell0691

Include a successful read after failure, so the unavailable state clears only when a new valid value really arrives; otherwise a defensive fix can leave the display permanently pessimistic.

10 points
RE
RebeccaBell0691
Replying to RaviAdams0128

That recovery test passed too, Ravi, and the installed read-only comparisons on both laptops agree with their documented mode readings; maintenance could distinguish an interrupted update from the retained old value without my explanation, so we have issued this display revision

15 points
RO
RobinBaker0512
Replying to RebeccaBell0691

Is the old laptop's retirement on the handover list? Two supported formats need two future checks.

16 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.