On our sleeve tray job, the phone clip shows a green tray symbol while the arm waits. Support says the receiving tray must therefore be ready. The programmer tells me that symbol may be the last received value, not a fresh reading. What should we compare before accepting the green picture as evidence?
Compare the actual waiting condition and its source history with the display's update time; a last-known tray value should not be treated as a current confirmation
I'd ask the programmer what the screen does when updates stop. If it leaves the old green symbol unchanged, that is a display problem worth fixing even before support explains this particular wait.
It keeps the symbol and doesn't show an age. The recorded controller message is waiting for tray-ready. We still need the matching PLC history to see what that condition was doing during the filmed wait.
Does the tray-ready definition refer to the fitted sleeve tray, Aisha, or is support reading a generic signal description that might omit part of the actual condition?
Give the operator an honest stale indication in the proposed screen change, not a blank symbol that leaves them wondering whether the tray disappeared. I'd have a relief operator review the wording too.
Victor, would you keep the old value visible with its time, or only say the current value is unavailable? I lean toward both, but a tiny busy screen can become harder to read if every old fact stays equally prominent.
Current availability first, old observation secondary and clearly dated if it helps the task. I wouldn't preserve an unexplained green icon merely to avoid changing the layout.
Naomi, controls has confirmed the fitted tray's mapping and supplied the history. The required input was absent during the identified wait. That establishes the wait condition, not yet why the input was absent.
Send support that mapping and matched occurrence together, with the old display behaviour explained; it should stop the green symbol being used to contradict the actual input history
And include the tray and sensing arrangement in the technical review, since an absent input does not by itself tell us whether the physical tray was correctly presented
Did the relief-operator review happen, Victor? Or rather, Aisha, has your team tried the wording with someone who wasn't involved in finding the stale symbol? I don't mean Victor's workplace.
Keep the recorded input and physical observation separate in that review too, so the new screen does not teach that an absent tray-ready condition always means an empty tray
Luca, wording review is pending. Support has requested an installer check of the fitted tray-ready arrangement. We haven't ordered a sensor or changed the tray from the input value alone.
Will the installer have the intended mounting detail and tray identity, rather than just the signal name? That would make the requested check more concrete.
Yes, both supplied. Separately, the relief operator understood 'current value unavailable' but initially read the smaller green history icon as current anyway. Programmer is changing that presentation before another review.
Thank you for trying it. That is exactly the sort of thing a developer who knows the timestamps can miss; I would keep the old observation readable without giving it the same visual treatment as a live state.
Revised display passed the wording review and the saved stale-update test. The installer check is still outstanding, so the original sleeve wait remains unresolved. At least its screenshot now stops arguing with its history.
Give the covering shift that distinction in the handover: display correction done, cause of the sleeve wait still under investigation. Otherwise the improved screen may be mistaken for closure of the whole ticket.