our fr5 dashboard finds an idle status inside a failed read

BenAli0196 · 7 Mar 2026, 05:39 UTC

Reply to discussion
BE
BenAli0196
The FR5 screen changes from busy to idle when this diagnostic read fails. New SDK response has several fields; our wrapper still picks a position from the old format. I've retained the failing reply.

15 replies

RA
RachelArcher0435
Replying to BenAli0196

Compare the wrapper's chosen field with the installed SDK's documented result. Check success before extracting a valid status; a diagnostic or error value can look quite plausible after being fed into your application's status labels.

7 points
BE
BenAli0196
Replying to RachelArcher0435

That's what happened. The old position now supplies a diagnostic value, and our local label table turns it into idle. Developer has the version and both successful and failed responses.

0 points
OM
OmarAbbott0056
Replying to BenAli0196

Does the report save that invented idle too?

20 points
BE
BenAli0196
Replying to OmarAbbott0056

Yes. Display and report both receive the wrapper's converted value. I've added the report row to the reproduction; it isn't only a misleading screen colour.

3 points
HA
HanaAdams0100
Replying to BenAli0196

What will the operator see instead when there isn't a valid current reading?

13 points
RA
RachelArcher0435
Replying to HanaAdams0100

Use an explicit unavailable result from the adapter and keep any previous reading separate with its observation time. Do not pass a made-up ordinary status downstream and expect each screen or export to recognise the trick.

13 points
DI
DineshBrown0908
Replying to HanaAdams0100

Hana, would you remove the previous reading altogether? I'm not sure whether keeping it helps the operator or leaves another tempting number on the screen.

23 points
HA
HanaAdams0100
Replying to DineshBrown0908

I'd ask the operator what they use it for, Dinesh, but I wouldn't leave it in the current-status position and hope a little timestamp explains the difference

21 points
BE
BenAli0196
Replying to HanaAdams0100

Operator uses the last reading when reporting a stop. We've kept it in a separate previous-reading section, with current reading unavailable above. They could explain both on the revised test screen.

-1 points
OM
OmarAbbott0056
Replying to BenAli0196

Has the parser fix passed, not just the wording?

4 points
BE
BenAli0196
Replying to OmarAbbott0056

Retained successful states parse correctly. Failed, incomplete and unexpected response shapes return unavailable. The same cases reach display and report without an ordinary status being invented. Installed workstation check remains.

6 points
RA
RachelArcher0435
Replying to BenAli0196

Include first startup without any previous reading, and a good read followed by failure. Those are different screen histories even though both end without current data.

-1 points
DI
DineshBrown0908
Replying to BenAli0196

Did the workstation comparison settle it, Ben?

18 points
BE
BenAli0196
Replying to DineshBrown0908

Yes. Maintainer checked the identified installed package with both startup cases and the retained response set. Current and previous status stay distinct, and the report records failed reads as unavailable. Operator handover accepted.

12 points
HA
HanaAdams0100
Replying to BenAli0196

Thanks for keeping the previous reading useful without dressing it up as the current one; that is the bit I would want the cover operator shown too

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