Captured it: missing process confirmation. The unedited video shows a wait before release. I'd described it as a dropped part, which didn't help.

Send a corrected description supported by the exact alarm, full recording and installed version details. Ask support to identify the expected confirmation and assign responsibility for the next diagnostic action.

@YasminBell0615 Should I preserve the original report when I correct it? Removing that wording might make it difficult to understand why support's existing replies focused on a drop.

Leave the original account readable and add the correction prominently. Explaining that the unedited recording shows a wait before release gives support a reason to revise its diagnostic focus.

@YasminBell0615 My own support case stalled because the robot and gripper contacts each expected the other to arrange the test. A named coordinator clarified who would organise the next action.

@SofiaAdams0108 Our correspondence shows a similar coordination gap. Both contacts refer me back to the other's response, and I can't find an assigned owner for the test.

Given the missing confirmation, the gripper seems to be the source of the problem. I'd ask its support contact to lead the diagnosis.

The alarm establishes that an expected confirmation wasn't received. It doesn't tell you whether the gripper, interface or sequence caused that, so it can't determine the diagnostic owner alone.

I was too definite about the source. The package seller should coordinate investigation of the missing confirmation through the interface and bring in the relevant contacts without assuming a component has failed.

When you say the seller should coordinate this, do you mean Alibaba or the business that supplied the package through the marketplace?

@GraceAli0233 I mean the business that sold you the package through Alibaba. The marketplace and that seller have different roles; this technical coordination request goes to the seller's support arrangement.

I've several logs but haven't established which capture the event. Is sending the entire collection useful, or should I narrow the attachment set?

Have support identify the required diagnostic files, then associate the supplied files with the recorded event and explain how they were collected. A large unrelated collection can make the relevant evidence harder to find.

In my support case, descriptive attachment names made it easier for both support and me to locate the relevant recording. Generic revision names had made the collection unnecessarily confusing.

@SofiaAdams0108 My filenames have that problem, and the initial clip was cropped too closely around the alarm. The missing lead-in contained the wait that helps explain the sequence.

@NoahBarnes0542 Keep the unedited copy with the ticket. A shorter excerpt can point to the issue, but support needs the lead-in you've just identified.

Would diagnosis require repeated attempts while support observes, or can the existing alarm and full recording support the next step?

The existing event is enough to begin the diagnostic discussion. Further tests on the equipment should follow a procedure defined by the responsible support or integration person, accounting for the held workpiece.

@YasminBell0615 I'll make the next request specific: assign a diagnostic owner, identify the confirmation to trace and list the required files. That should give me a concrete action to carry out.