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!". :icon_rolleyes: 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.

  • \Stop can be very hard on the robot, if you have a large payload it's quite ugly too see. \SStop is much better, in my experience the drift is limited, like 5mm at 200mm/s. What are you searching for?

  • 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.

    I've done the similar a couple of times to minimize cycle time. Also compliance in the tooling, incr/decr offsets, ...

  • 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. :puke:

  • 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)....

  • 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.

  • Did a call for a slower search for top-of-stack at top of routine that saved position added offset and ...

    Set flag for true for top-of-stack search done and used that to bypass.

    Cleared flag and offsets for any stoppage to force it to do new top-of-stack.

  • my experience (Client needs more save cycle time) ,

    keep instructions format and add some trick

    next approch more close to recorded position by Reltool (or Offset)

    IF Di20_Height_Reset = 1 THEN

    pTemp2 := pSearch_Start;


    MoveL Offs(pTemp2, 0, 0, 50), vMax, z10, tGrip;

    SearchL\Stop, Di01_PartSensor, pDetect, Offs(pRef_Position), v100, fine, tGrip;


    MoveL Offs(pTemp2, 0, 0, 50), v50, z10, tGrip;

    IF Di05_Vac_Pressure = 1 THEN

    Decr nLayer_Quaintity;


    IF nLayer_Quantity > 0 THEN

    pTemp2 := pDetect;

    ElseIF nLayer_Quantity < 1 THEN

    pTemp2 := pSearch_Start;


    MoveL pSearch_Start, v1500, z200, tGrip;

    ABB, FANUC, Hyundai, Kawasaki

Advertising from our partners