Our imported UR5e package stops intermittently while loading aluminium spacer blocks, and after 51 days my Alibaba seller ticket still consists mainly of a phone video and requests for more information; I want to make the next reply specific enough that somebody can investigate instead of asking me to film the same pause again.
Where is the spacer when the pause begins, Jack? Your description could mean before pickup, during the transfer or after placement, and the useful evidence would be different in each case.
I sympathise with the filming loop. I once sent a longer clip that still missed the only message support needed. More seconds were not more information. Can the person saving your machine messages identify which occurrence the video shows?
Farah, the block is already in the receiving fixture; Hazel Archer, the clip time matches one saved occurrence and its screen says waiting for fixture confirmation, although the phone view doesn't show the fixture indication.
Then ask for the active step and the source of that confirmation in the installed logic. A text message names the application's expectation, not necessarily the reason the input is absent. Include revisions so support reads the right definition.
Hazel Carter, only the message was saved; our maintainer has since retrieved the controller event export but it doesn't contain that input history, and David, the active step follows the placement request but doesn't itself prove the fixture received the block correctly.
David, yes. Jack's distinction is important: preserve the preceding command and its reported result, without promoting either to a physical observation. The missing input history is now a specific capture gap.
And what happens to the work meanwhile? Fifty-one days is a lot of somebody waiting by a phone. A named diagnostic contact and an update date are reasonable asks, even while the cause is unknown.
Alex, maintenance cover will collect it; Warren, we are using our existing manual route and purchasing now owns the support chase; Abigail, the seller identified the expected fixture input and has arranged a diagnostic session with our maintainer.
That is enough to make the session purposeful. I would have the maintainer compare the physical indication with the signal history at the same event; otherwise the camera and the exported bits could still be telling stories from different pauses.
The session found the fixture indication remained present while the controller-side confirmation dropped; maintenance traced a loose terminal in the interface enclosure under isolation and corrected it, but we haven't completed the agreed repeat check yet.
That supports a specific interface finding. Keep the before-and-after trace and the repeat-check conditions; don't assign every older unrecorded stop to that terminal merely because it was loose.
Agreed, Priya. The ticket names the traced occurrence and correction, with repeat checking still due; I have left the older pauses unclassified instead of declaring fifty-one days explained by one terminal.