our fr5 unload video starts after the useful bit

Technical contact asked for the receiver-ready state and transfer acknowledgement around the event. Maintainer can capture those with the job version. My clips showed the next screen, not the transfer that stalled.

Which program owns clearing that acknowledgement?

That's unclear in the handover. PLC author says the receiving application clears it; application author thought PLC did. Both have the question now, with the same event names.

Kai, was this ever diagnosed as a gripper fault, or did the ticket title just drift that way? I'd correct it if it's only a guess. Otherwise the next support person may start by sending you the same mechanical checks again.

Do the authors agree what the acknowledgement means before they decide who clears it? Receipt of a message and completion of the physical transfer are rather different things to hide behind one short name.

Jack, my title said gripper pause, not a diagnosis, but I've changed it to transfer wait. Harish, they found their descriptions differ exactly there. One means result received, the other means transfer finished.

Give those two events different names in the proposed interface. The people implementing and teaching it need to see which one they are discussing.

Our lamp wording hid two conditions too. Does the operator screen use this same ambiguous name?

Caleb, yes, the operator explanation belongs beside the signal change, not after the next confusing stop.

Let the authors check the interrupted transfer and restart cases with those separate events. A successful complete cycle will not expose the disagreement that left this one waiting.

Kai, has a capture actually shown the old acknowledgement surviving into the next transfer? The naming mess is real, but it might not be the whole stop.

Yes, Mia. Retained trace shows the earlier receipt acknowledgement still set when the next transfer begins. Application waits for a change PLC isn't going to provide. CalebBennett, screen also calls both events complete, so that's being split.

Thank you. Have both authors agreed the event ownership now?

Mia's question was worth asking. I've watched teams fix confusing names and then discover the same old sequence underneath them. Kai, keep the captured order as a test case for the revised interface, with the operator view included.

Both authors agreed the interface and tested the captured order, interrupted transfer and restart in their offline checks. Old receipt can no longer satisfy the next transfer. Updated build and operator wording are with our integrator for the return checks.

Return checks completed with the identified connector job and receiving setup. The earlier sequence now finishes with its own acknowledgement, and the next transfer starts without borrowing it. Interrupted cases follow the agreed recovery. Thanks Hana and Harish, the ownership question got this out of the video loop.

That is a useful support result. Did they attach the corrected interface and screen wording to the ticket before closing it? I'd hate to inherit the old descriptions with the repaired package.