Different brake reactions when searching for one part

  • Hello all,


    About the robot:

    KR 180-PA.

    KRC2 / Win 95.

    Can't remember the KSS version now, I'll write it down next time I go to the customer place.


    In a palletizing cell I programmed a while ago once robot finishes putting all the boxes on the pallet, sometimes a wood cover must be placed on top of the boxes.


    Wood covers are placed in another pallet that can be replaced while the robot is stopped by an operator, therefore, in order to avoid any possible collision if the customer introduces a new pallet full of covers, I programmed the robot to perform a search every time it goes to pick a cover.


    The search works more or less well performing those operations:


    $TORMON for axis 2 and 3 are set to 50.

    An interruption is activated.

    Robot is sent to a position in which the vacuum cups would be on top of the pallet (this position can only be reached if no wood covers are present).

    Once a laser sensor finds the wood cover the robot brakes fast.


    See a fragment of the code involved:



    When the wood cover is found, another search starts, using another interruption, sensor... that ensures I'll get the vacuum cups touching the wood cover.

    I do this because the robot robot reacts differently depending on the height in which the wood cover is found in the first search.

    By "reacts differently" I mean the braking distance is different.


    When the part found is at a position higher than the robot base, then the braking stops the vacuum cups almost touching the wood cover which is perfect. But, when the part is found at a lower position, the vacuum cups can be stopped even at 400 mm from the wood cover.


    The problem with this is that the second search takes ages to finish.


    I could remember where have I've found the last wood cover and search only after a program start as the operator must stop the machine to replace the wood covers pallet, but that could lead to a collision at full speed.


    The inputs are normal ones, not connected to the $MEAS_PULSE... this should mean that I could have a 18mm of error due to the input itself, but never ever 400 (as 1,5m/s => 1,5mm/ms | 12 ms polling time => 12*1.5 = 18 mm of error max).


    Notice I'm using a CYCFLAG and not the direct input, as the code comment explains, I did this to allow them to add another sensor to have some redundancy (more safety for the robot clamp),


    What would recommend me to avoid this difference on the brake behavior?


    Is that normal?


    Could the TORQMON affect the braking distance?


    Thank you very much in advance for your time and help.


    :thumbs_up:

  • your concern is speed but there is nothing in your program to set speed. i assume second search is pretty much the same.

    in the past i used laser sensor to determine height of the top part, then send robot there directly, try to pick and check if vacuum is made. this is fast, measurement can be done ahead of time, while robot is someplace else so no advance run stop, no search.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Hi panic mode !


    Yes it is (line 25 in the code snippet):


    $VEL.CP = 1.5 ; Speed at which the search will be performed.


    Just before calling the movement routine.


    The first search runs at 1.5m/s while the second one runs at 0.06m/s and I can tell you the change it's very noticeable.


    The second search uses a code quite similar as the one shown before, mostly the only difference is the speed.


    What you did in the past sounds much better than all I can do here, you know where the part is and send the robot there... and of course after all this you have a vacuum sensor that tells you if the part is fixed or not. I have only two 1/0 sensors adjusted at a certain distance (brake / stop) and I don't have a vacuum sensor, so I go down fast till the first sensor changes to 1, then I perform the second search till the second sensor changes to 1, send the robot to the top position and, if the first sensor is lost, I retry.

    I've only programmed this robot and other people have decided what sensors are mounted everywhere... I did it with CYCFLAGS to have some kind of redundancy and put a couple of sensors for each operation, but the customer at the end decided only one sensor would be enough. Go figure.


    I've spoken to a KUKA technician this morning, he told me CYCFLAGS don't add reaction time compared to a normal digital input so that won't be the reason.

    I've not remembered to ask him about the TORQMON, but without this his only idea is that the mechanical compensation device is badly adjusted (very old robot) and that, the lower the robot is the harder the mechanical compensation affects the movement and therefore the robot could stop before...


    This Friday I will go there to take a look at it.

  • you are right, speed is there, but not acceleration. if accel value is low, robot will still move slow.

    btw. i like to put all motion parameters next to motions (tool, base, speed, accel,... all in the same sub), that way if call order is changed, or anything got modified in calling program, motions in sub are not affected.

    $CYCFLAG[] are very fast, they are not the problem

    $TORQMON[] is used to check (compare) actual torque, it does not change axis torque

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • How sure are you that the sensor response isn't changing? When I've had issues like this in the past, 95% of the time the sensor was triggering at a different distance from the target, due to external factors.


    Offhand, the lower Torque settings should not affect how quickly the robot stops on a BRAKE F. The robot's age should not be a factor, either -- a BRAKE F does not engage the servo brakes, it simply uses a high but controlled deceleration on a controlled path. BRAKE F is more like a Category 2 stop than a Category 0.


    Hmmm... what are your payload settings during the Search motion? If the $LOAD values are set high, and the robot reach is awkward at different stack heights, it's possible that the robot decelerates differently depending on its physical pose. Still, that should not be enough to account for a 400mm difference, unless the MADA has been tampered with somehow.


    At the moment, my best suggestion is to collect data using the KRC's Trace function -- build a Trace that records the robot motion, and the sensor input, during the Search path, and run tests at different stack heights. This will show you the exact relationship between the moment the robot sees the sensor input and when it begins decelerating, as well as how quickly it decelerates. This will provide real, hard data that eliminates much of the ambiguity.

  • panic mode yes, me too, I read somewhere speed had to be changed out of the interruption otherwise the speed specification did not affect the search movement. At this moment I can't remember if I tried it or not, nor the result of it... I guess this is done like that for that reason.


    The acceleration has not been changed at all in the program, so it should use the same one in all the movements. So it should not be the reason of the difference in the braking distance.


    SkyeFire I will try that this Friday... Given the robot came from Detroit years ago, then changed hands in Spain and now (after a few years of working is at that customer) and that the sensor is brand new... I have not even thought it could be caused by the sensor, but anyway, I will try to set that Trace and collect some results.


    @Both:

    I will have to change one movement speed because the customer is telling me they must work at OV_PRO = 75% because in that movement at 100% robot has problems and stops working... I had produced multiple pallets before leaving that robot, at 100% speed... I'm sure that robot will die soon.


    Thank you for your help!


    :thumbs_up:

  • SkyeFire I will try that this Friday... Given the robot came from Detroit years ago, then changed hands in Spain and now (after a few years of working is at that customer) and that the sensor is brand new... I have not even thought it could be caused by the sensor, but anyway, I will try to set that Trace and collect some results.

    Depending on the laser sensor, they can trigger at wildly different distances depending on many factors. Some of the cheaper ones can be thrown off by hundreds of mm if the color of the target surface changes. I had another case where the sensor would react 100-200mm differently depending on whether the sheet metal was smooth, or had been abraded. Some even had 20% variance based on ambient temperature! Some could even be vulnerable to ambient lighting -- if, for example, part of the pallet stack has sunlight hitting it, and another part of the stack is in shadow, some sensors might react very differently.


    Looking at wood pallets, there are lots of opportunities for surface variance -- the beam could fall into a hole, could hit a nail head, different pallets are often different colors, or could have bits of metal/plastic on them, etc. Heck, just the wood grain and texture could throw the cheaper sensors off some.


    The "dirty little secret" of many of these "laser sensors" is that they are not "laser" sensors -- they're simply a narrow beam of light, and the receiver side of the sensor just uses a filter, and the reflection intensity. Sometimes just a cheap laser-pointer diode serving as the light source. Slightly more expensive models use an offset Fresnel lens and linear CCD for slightly better performance, but still are vulnerable. The only ones that are reliable across many surface variations are time-of-flight sensors, which are substantially more expensive, but have far less vulnerability to surface changes.


    For finding wood surfaces, even the expensive laser sensors would not be my first choice -- I would look at sonar sensors, personally. Siemens makes some good ones that produce an analog feedback and tend to be pretty reliable.

  • OK, never thought of that... clearly if that is the reason of the problem... I can't do anything to solve it except than remembering the last pick position and go directly there unless doors have opened.


    I don't like this at all... Anyway, I will try the trace thing. Never used it before, but I'll find some information in the manuals.


    Thank you very much!

  • i totally agree, TOF is a way to go.


    there is plenty to choose from but my favorite optical sensors are from Baumer (very best performance). short range sensors would need to be mounted on EOAT so they can can get close enough to take a measurement.


    when looking for low cost, long range and resolution is not critical (such as palletizing where tooling has compliance due suction cups) O1D100 from IfmEfector could be used. it is not as accurate but it is long range and it will still get you within several mm even from long distance so it can be mounted stationary. good enough for tooling that is compliant enough and many suction cup designs are since using 'accordion'.


    ultrasound sensors can be used, specially for certain surfaces (laser could give you "wrong" reading if it looks through cracks). beware of interference from other ultrasound sensors. also make sure to understand size of the cone and potential misreads.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Nice to see things get solved magically...


    I went there, customer got a physical check of the robot and that braking operation works well now. I can't be sure what they did.


    Of course they did not told this to me and asked me gazillions of questions once I was there.


    Thank you all for your time and help.

Advertising from our partners