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

Correct the ticket with that alarm, the unedited clip and the installed versions. Ask which confirmation is missing and who owns the next diagnostic step

Worth leaving my original description visible? It's wrong, but deleting it might make the replies look odd

@LucyBennett0741 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

@CalebBennett0754 On my setup, the arm and gripper contacts both thought the other owned the test. Naming one coordinator helped us get an actual next step.

I've checked our messages. Same gap here: each contact asks what the other said, but neither has assigned the test

That missing confirmation points to the gripper, so its contact should take the diagnostic lead

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.

You're right; I assigned the cause too early. Ask the package seller to coordinate tracing that confirmation across the interface, with both contacts involved as needed

Is that Alibaba support, then? I'm muddling the seller and the place you bought it

The unnamed seller who supplied your package. Alibaba is the marketplace; your technical request here is to the seller and their support contacts

Would you send every log I've? There are lots, and I don't know which ones cover the stop

Ask which diagnostic files they need and provide the ones you can tie to the event. Include collection context; unrelated bulk can hide the useful bit

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.

Guilty of the 'final' filenames. I also cut the original clip too tightly; it lost the wait leading into the alarm

Attach the full recording even if you include a short excerpt to highlight the symptom. The lead-in you found is relevant to understanding how the alarm arose.

Should they keep reproducing it until support can watch? Or is the captured event enough to start with?

Start with what's captured. Any further equipment test needs a defined procedure from the responsible support or integration person, especially with a workpiece still held

I've got a usable next request now: the corrected alarm and clip, version details, and a named diagnostic owner. That settles how I'll approach support; the actual fault is still to be diagnosed