FR10 spacer fault export carrying the previous fixture's input map

Installer extracted the loaded program and referenced table. The program label is current. The table reference still points to the old fixture mapping. Author has both files and the fitted fixture identity.

That is a concrete mismatch to investigate, but don't let it become permission to change whichever input makes the wait go away. The author needs to compare the intended mapping with the installed fixture and explain the correction.

Does the retained occurrence show which old mapped input it was waiting for? Give support that link, not just another screenshot of the program name

Yes. Author traced this wait to a confirmation from the previous fixture which is not part of the current arrangement. They are preparing the corrected mapping with the installer and fixture owner.

Was the old table loaded only after a restoration, or has the current job used it throughout? That may help establish which earlier reports belong to this explanation.

Current fixture ran with its intended mapping before a laptop restoration. The restored package brought back the old table under the current program label. We have the restoration record, but not enough retained detail for every older stop.

Correct the restoration set too, or the same repair will be undone at the next recovery.

And check how the restored files get identified. A current-looking program label fooled the first round of support here. I'd want the maintainer to verify the referenced table without having to rediscover which file silently survived from the old fixture.

We had capture coverage checked before support could use our newer occurrence. Same principle here: test what actually comes out of restoration, not the name of the folder handed over

Corrected mapping reviewed by the author, installer and fixture owner. Agreed spacer-loading checks passed. Maintenance restored the corrected handover set for comparison and verified the same program and table identities; that check passed too.

Which reports are you closing against that result?

This captured occurrence and the restoration-package fault. The earlier stops without the necessary records remain unexplained. Our handover now includes the referenced table identity, not just the main program name. Thanks, Liam; repairing only the running copy would have left us a repeat failure.