my tray count says empty but there's a sleeve there
KaiBell0628 · 6 Jan 2025, 11:04 UTC
14 replies
Where does your saved count change relative to release? A count alone cannot tell the operator whether the sleeve is still held, seated in the pocket, or somewhere else. You need to know which uncertainty you're actually dealing with.
20pointsCount saves after retreat. Sleeve was down, gripper hadn't finished moving away.
1pointsThat explains this case. Moving the save earlier only moves the awkward gap somewhere else. Ask your programmer for named transfer states and a recovery screen that can pause for a physical check when the last action is uncertain.
19pointsSo 'released' isn't automatically proof of 'in the pocket'. Got it.
5pointsExactly. It can be a command the program issued, rather than confirmation of where the sleeve ended up. What feedback do you actually have on the tool and tray? That decides how much recovery can be automatic.
6pointsWe saved an 'in progress' flag in our training job, which at least stopped restart pretending everything was fine. Still needed a human to settle where the part was... not glamorous, but nobody loaded an occupied pocket twice.
1pointsFinger position only. No pocket sensing. Cheers for the distinction, Luis.
21pointsDon't let someone turn that human check into a yes button people hit to get running. Show the pocket number and what needs checking, with the cell in its established safe inspection condition. Sorry, 'human check' sounds simpler than the handover actually is.
16pointsOur screen just says resume. That'll need changing before anyone else gets this job.
8pointsWe found ambiguous steps by walking through a stopped job on paper. Cheap exercise. Include a sleeve stuck in the fingers, not just a clean release.
3pointsGive the programmer that list of cases before they build the screen. Include a restart where nobody knows who last touched the tray. The recovery decision needs to restore an agreed state, not merely dismiss a warning.
20pointsMade the list. Missing sleeve and occupied pocket currently get the same answer, which looks daft now.
1pointsIt's a useful discovery while this is still a test station. Keep those as separate cases in the handover. If the physical state cannot be established, stopping for someone qualified to resolve it is a valid recovery outcome.
15pointsDid your programmer say whether those saved states survive a controller restart? Ours survived stopping the job but vanished after power off, which made for a rather short celebration.
10pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .