SearchL Stop Types

IRC5, RW 6.12.

I've used SearchL with \PStop a lot in the past, with good results. However, now I'm dealing with a customer that is adamant that the SearchL motion must be faster, and won't take any other answer. This means I need to stop faster to protect against collisions. So I'm digging into the other stop options.

The RAPID reference manual shows three options: \Stop, \SStop, and \PStop. Of the three, if I'm parsing the manual correctly, \Stop (stiff stop) is the fastest, but has the most drift off path, and the manual has a warning that it shouldn't be used above 100mm/s. Since my customer wants speed much faster than 100mm/s, I guess this one is out.

\SStop (soft stop) appears to be the next fastest stop, but has a warning that it tends to slide off-path at speeds higher than 100mm/s. This one's a maybe.

And \PStop (path stop) is the slowest stop, but guarantees(?) the TCP will stay on path while the robot decelerates. Which I've been using, with success, but I'm not sure it'll stop fast enough once I have to start cranking up the search speed.

Anyone with SearchL experience have any thoughts on the matter? I don't have a target speed from the customer, just "FASTER!". So I'm not sure what I'll end up at. And I can't have my SearchL inputs trip sooner for various reasons.

I'll probably just have to set up some tests and work it out experimentally.

Quote from Lemster68

Can you talk them into using a longer range sensor for a fast search, then switching to the current sensor for the slower search? Maybe that can enable a shorter distance for the "slow" search.

Maybe, but I'd have to fight this past some serious penny-pinching. That might be the only way to make this work, though. The annoying thing is, the "full slow search" is already working fine and ~10sec under the required cycle time.

With what I currently have to work with, I might have to shorten the range of my sensors so that they only trip if a part is further forward than the memory counter says it should be, so that the SearchL \xStop only triggers rarely, then use a high-speed SearchL with a \Stop or \SStop, whichever stops me fast enough.

Quote from Lemster68

Just what is it that you are searching for? Is it parts to pick from a pallet/bin?

Large sheet metal stampings, in a "hanging-folder" type of rack. Each part hangs in a slot, and each slot is ~100mm apart. The parts are hung linearly, front-to-back, so each part blocks access to all the parts behind it. I'm using a vision system to "fine tune" the pick position every time.

So in theory I could simply use a counter and blindly move to the Vision position for the correct slot.

Of course, programmed that way, the first time the counter doesn't match reality for any reason (say, someone loads a fully-loaded rack without resetting the counter)....

Quote from Lemster68

I had a job picking parts from trays, and whenever the tray present switch was broken and then remade the PLC would send over a reset input, whether it was the same tray with parts removed or a new, full tray.

Oh, will definitely have that. Unfortunately, there's no method to protect against a partially-filled rack being loaded, or someone moving parts in the rack, or just a failure to reset the counter b/c someone loaded a new rack in a non-standard way... the robot's search is literally the only way to confirm/deny the accuracy of the counter.