I have the lead-in events this time, not just a film of a stopped arm. Our FR10 spacer-loading ticket has been open forty-one days, and the seller is reading the capture as if we have the old receiving fixture. We changed to the identified replacement fixture before this occurrence. The installed job and fixture references are in the ticket. How do I stop another round of advice about a sensor we no longer have?
Make them name the source behind the field they're interpreting. We've had a correct event file explained using an old drawing, so everyone sounded informed while talking about different hardware. Ask which installed mapping they're using for this occurrence.
Their screenshot uses the old mapping sheet. The raw field names in our export haven't changed, but one source assignment changed with the replacement fixture.
Was that change included in the supplied application revision, or only on a wiring drawing? You need the author looking at what the installed application expects as well as what is physically connected.
Included in the installed application revision. The maintainer has matched that and the wiring sheet. The support screenshot is from the earlier package, not our current export.
Could the covering technician send the same matched export without you? This confusion will return if the useful version is only in your email attachments.
Mia, waiting for receiving confirmation, no separate fault shown. Caleb, yes, the installed references and export route are on our shared support sheet. The seller downloaded the older attachment instead.
Then send one occurrence with the exact current attachment links and ask the reviewer to repeat the source assignment back. Don't alter the raw event names just to make their old screenshot look less wrong.
Henry, yes. The old mapping belongs with its old occurrence. Hassan, I'd leave it available but clearly superseded for this case, rather than erase why the first interpretation went astray.
Reviewer now confirms the correct source. They can see the receiving confirmation drop before the wait, and have withdrawn the suggestion to inspect the removed sensor. Finally we are discussing the fixture in front of me.
After seating, Mia. The event sequence shows confirmation present first, then lost. Maintenance is checking that current source with the fixture identity and occurrence attached; no component blamed yet.
That's a useful distinction for the maintainer. Include the time between those two events from the same source, not a delay assembled from phone-video and controller clocks.
Same-source interval added, and Caleb's export explanation is on the shared sheet. The ticket stays with maintenance and the application author until the physical loss is explained.
Please come back with what they find. I'm interested whether this is movement after seating or the confirmation path itself; the existing video may help once they know exactly where to look.