Application shows 'awaiting tray ready'. Controller display isn't visible in that recording.

Then describe that wait. The clip doesn't establish a controller fault.

Agreed. Ticket currently says robot fault; I'll correct it to observed application wait, cause unknown.

Is there a saved log covering the lead-up to it?

Found an application log. It enters tray-ready wait just after the recorded tray-change step.

Does it show the input state, or only the step name?

Include who performed the tray change and what they saw, where known, because a handover description can help explain the sequence without guessing from the software timestamp alone.

And ask what 'ready' means in this application. The label may hide several conditions.

Identify the tray used as well. If different trays share the same everyday name, support may assume the setup was unchanged when it was not.

That is a possible difference to document, not evidence the tray caused it.

Log records the step only. Operator noted a tray change; no input snapshot saved. Tray identity unknown.

Say those details are unavailable. Better than reconstructing them from memory as facts.

Send the log with your corrected account and ask the application supplier to explain the conditions that hold this wait. They can then specify what state capture is needed. Avoid changing the handshake simply to make the message disappear.

Sent. Asked for the wait-condition definition and a targeted capture procedure. Configuration remains as recorded.

When they reply, have the procedure available to the shift that actually sees the wait; otherwise the useful instructions may arrive in an office inbox while the evidence is on the workshop floor.

Put the capture instructions with the cell's support notes once approved. Also include where to store the files, so the next report can connect them to one occurrence.

I'd like to hear which condition was missing when support can establish it.