The arm pauses at a different tray pocket each time

It says waiting for release confirmation. The spacer appears to be in the pocket, but the video doesn't show the gripper status. So appearance isn't proving the release completed.

Right. Ask what produces that confirmation in your supplied application. It could be a signal, a state calculation or something else; the words on screen don't tell us the implementation.

The supplier says it's based on the gripper interface state. They've asked for its reported state and the application log from one occurrence. Those were missing from my first report.

That gives you a targeted request. Get their capture procedure if you don't already have one, and identify the same occurrence in both records instead of combining unrelated examples.

Also ask which interface state is expected, because a state being different from the application's expectation could mean a tool issue, an interface issue or an incorrect expectation in the application.

They sent the expected-state definition. I can capture it through the existing diagnostic screen. No setting changes requested. We're waiting for the next occurrence during approved supervised use.

Note whether the last reported state is current or stale. I should have asked that earlier; a held value on a screen can masquerade as the gripper's present state.

Include the diagnostic timestamp or age indicator, if available, with the state capture.

And state when that information isn't available. The point is to show support exactly what you observed, not improve an incomplete record by guessing its freshness.

Who receives this evidence while the supplier investigates? Your next shift should not have to rediscover the capture procedure from a month of purchasing emails.

A shared incident entry would help, with occurrence identifier, evidence files and configuration. How far did you get with the first capture?

Captured one. The interface state stopped updating before the application wait, while the diagnostic connection indicator stayed green. Support has both records and the installed versions. Maintenance owns our incident entry.

That is narrower than 'robot stops'. Have support explain what the green connection indicator actually guarantees; it may not mean new state data is arriving. The stale interval is the part worth investigating.

They reproduced stale state handling in their application test and are reviewing a change. We haven't installed anything. I'll update when there's a documented fix and verification, not just a promise.

Please include whether their verification covers recovery after updates resume. Detecting stale data is useful, but the application also needs a defined decision about the interrupted operation.