Our UR5e mode display accepts an error-shaped answer

There's a success indicator and a separate value. I was converting the entire response to a boolean. Captured success and failure examples now sitting beside the versioned docs.

Give unavailable its own label. Don't dress it up as stopped because stopped happens to fit your enum.

Stopped was my default, yes. Removing that. Failed read will be unavailable, with the actual error detail kept for diagnostics.

Will the operator still see the last known mode? It can be useful context, but make its age and uncertain currency obvious so people don't mistake the old answer for the current one.

And what happens on the first read? No last known value then. A default can creep back in before the first successful response.

Sofia, last known mode stays in a separate labelled field with its original read time. NadiaAli, first-read failure has no mode value at all. Both cases are in the tests.

Does a response with an unexpected structure also become unavailable? The documented failure case will not cover a parser receiving something it cannot recognise.

It does now. Before, the exception handler quietly left everything as it was. Changed the handler to report interpretation failure without updating the last successful time.

That exception handler deserves its own test. Quietly left everything as it was is how a stale screen becomes everyone's favourite source.

Who gets the diagnostic detail when it fails? The shift should not have to copy a whole SDK response out of a tiny status field.

Maintenance gets the version, method and error detail in the diagnostic log. Display gets a short reason and occurrence time. I'm checking our export doesn't still use the old boolean helper.

Try that short reason with someone who hasn't read this discussion. I have seen communication lost interpreted as machine stopped, even when the designer thought the wording was perfectly clear.

Found the export doing exactly that. It wrote stopped for failed reads independently of the display. Both will use the interpreted result now, with unavailable kept distinct.

Are the previous SDK responses still supported, or is this a migration to one known version? That affects which response forms the adapter should deliberately accept.

One known version on this station. Keeping the old captures for comparison, not adding a guess-both-formats parser. Our deployment record will name the supported version.

Have maintenance check the normal launcher uses that version too. A correct record beside the wrong imported copy is no help on shift.

And retire the old export. Don't leave it one click away for someone who liked the old layout.

Read-only checks passed from the normal launcher. Failed, malformed and initial-unavailable cases agree on screen and export. Operator wording review still pending, so I'm not calling the handover finished.

Does the person doing that review know who to call when unavailable persists? I'd include that question with the wording, since a clear state still leaves somebody needing a next step.