Our FR5 sleeve-loading job sometimes waits with empty pockets visible. The seller calls it a full-tray wait from my video, but I cannot tell whether it is looking at the physical tray or just reading the screen. The clip begins after the stop.
I have kept the current job export and the tray that was in use. What would connect those to the application decision without guessing from the empty spaces?
I've had the same phrase used for a physical sensor and a software count. Ask which condition this application calls tray full, then attach the retained history for one occurrence. The empty pockets are worth showing, but they don't tell us which condition the application used.
Also show which recipe the screen says it is using. Not asking you to switch recipes to see what happens, just put the visible selection beside the tray identity already in your evidence.
Chloe's pairing should help. One old support ticket of mine had two plausible video matches because a message was reused. I'd rather have one clearly identified occurrence here than a compilation of stops that might belong to different jobs.
SamBrown, eight sleeves in the identified tray. Chloe, the selected recipe is named for this sleeve family, not the tray. The retained application history reports capacity reached at eight.
Eight pockets. That is why I asked the integrator to compare the selected configuration, rather than asking the operator to fill the remaining pockets another way.
Could be the older tray setting, yes. But let the integrator confirm where that eight comes from; it could also be a deliberately restricted use of the larger tray.
SamBrown's point matters for the person reading the eventual fix note too. Twelve physical holes doesn't mean somebody here should type twelve into an unknown setting.
Loaded copy and supplied copy both retained. The integrator found the eight-pocket configuration under the twelve-pocket shortcut. Its current handling layout expects the larger carrier; the shortcut still selects the old capacity file.
Both shift accounts are in the integrator's check. It has corrected the mapping and is checking the two defined tray jobs separately, with the appropriate tray identities and pocket counts.
Yes. The supervised verification completed the defined twelve-pocket sequence, and the eight-pocket job still stopped at its own capacity. Both shift shortcuts selected the intended files. The screen now names the tray job as well as the sleeve family.
Thanks, Priya, for asking what full meant here. The empty-pocket video showed our complaint; the configuration comparison explained it. We've closed this ticket with those checks attached.