Our FR5 reset button clears a request it did not send

Does reset also hide the last inspection result? We've had screen tidiness and result handling tangled together. It's easy to make the problem look gone while the saved data says otherwise.

A screen I reviewed used reset for clearing a message, abandoning a job and starting again. Three people demonstrated it three different ways. I'd ask an operator what they think yours does before the programmers agree on a fourth meaning.

Ben, the operator thinks it dismisses a message. Rebecca, it clears the displayed result too. The programmer included clearing the request so the next cycle could start cleanly. That last bit wasn't in the operator's explanation.

Then the operator is changing job state without being told. I'd take their explanation into the meeting as it stands, not coach them to repeat the programmer's version.

Callum's exchange sketch should include an interruption after acceptance. Otherwise changing the button may still leave maintenance unable to determine whether an inspection started before the connection was lost.

Bruno, exactly. And please don't cure it by adding a paragraph of warning text to the same button. Make it do one understandable thing.

Ben, separating the commands helps, but the application also has to reject an action that is invalid in the current state. Two clearly named buttons can still cause trouble if both always work.

Yep, fair point. I meant separate meanings, not two unconditional buttons.

We tried the sketch with the operator. She wants dismissing a message to leave the job visible. The programmers agree that it must not clear the PLC request. They are working out the separate cancellation behaviour.

Thank her from another person who reads inspection results. A message can go away without the unfinished plate disappearing with it. What happens to the result when someone leaves that screen and comes back?

Rebecca, that return visit is a good test. I'd do it during the walkthrough, not explain beforehand what ought to happen. People often reveal the confusing bit by asking whether they have to start again.

Has the revised ownership arrangement removed the timed clearing as well as the screen write? A single writer can still clear a request before the receiver accepts it.

Theo, the draft holds the request until a matching acceptance instead of that timer. Rebecca, leaving the page currently loses the displayed job, so restoration is another change we need. No new version tested yet.

Who gets the incomplete plate while the screen is being sorted out? Worth making that explicit for the operator, especially if inspection is stopped mid-job.

For the tests, include a late acceptance arriving after a cancellation request. Do not assume cancellation took effect just because its button was pressed. The two sides need an agreed answer to that race too.