Safety Distance when reaching under a light curtain

[boup2341]

Hi everyone,

I'm looking for some help to better understand the safety distance calculation for a protective device (e.g., a vertical laser/light curtain) in a robotic cell, specifically when dealing with the "reaching under" scenario.

According to ISO 13855, the formula for this case is:
S = (1600 × T) + 8(de + HDB – 14) + Z

Where:

• S is the minimum safety distance,
• T is the overall system stopping time,
• de is the resolution of the detection system,
• HDB is the distance from the reference plane to the bottom edge of the detection zone,
• Z is an additional distance based on intrusion direction and approach speed.

Compared to "reaching through" or "reaching over" the curtain, this formula seems to always produce the most conservative (largest) result—even in cases where there's a very small (e.g., 5 mm) gap between the reference plane and the bottom of the detection zone, which physically cannot be accessed by a hand or body part.

Am I using the wrong formula in this case? Should the "reaching under" scenario still apply when the gap is too small to allow any intrusion?


Thanks in advance for your help!

 

[BrianPetersen]

If HDB is zero (no distance below the light curtain), and Z is not a factor, this formula becomes the standard one: S = (1600 x T) + 8 (de - 14)

If there is a gap underneath the light curtain at all, then yes, this formula very quickly gives a big safety distance.

If you have a 150mm gap underneath then this distance starts at 1.2 metres and goes up from there with stopping time. And this makes some sense, as someone's arm or leg could get in that far through a gap that big.

If you have a 5mm gap and the resolution of the light curtain is 30mm then S = (1600 x T) + 8 (30 + 5 - 14) = (1600 x T) + 168 so basically 168mm plus the stopping time factor. This is making an implicit assumption that the bottom beam is 35mm above the reference plane (barrier below light curtain), which might not be the case but this depends upon the specific light curtain in use.

If you can show that the gap beneath the detection zone is within the resolution of the light curtain (e.g. 30mm object held against the floor trips it and the light curtain has 30mm resolution) then perhaps one could use an explanatory note and use the main formula on those grounds. Otherwise, the situation seems normal.

Some of the application-specific standards may provide additional guidance in this situation.

 

[boup2341]

Thanks for your reply,

I did not think to include the resolution in the gap underneath, which make more sense.

When you talk about application-specific standards, is it ISO Standard? I want to install a zone scanner to create a curtain on one side for a collaborative robot that moves boxes. Is there a different standard I could use?

Thanks again,

 

[BrianPetersen]

It sounds like you need to look at ISO 10218-2 and ISO/TS 15066.

And now, I have to ask the same questions that I asked of many integrators in the process of talking them out of using collaborative robots (LOL)

If you are operating the robot in collaborative mode (with speed and force limitation active - the moment it bumps into anything, it stops, and it isn't going fast enough to cause a significant impact hazard to intruding arms and legs, and the stopping distance and time is basically nil) then why do you need the safeguarding? (If somebody's head or torso can get into a crushing point between the robot and a fixed obstruction, such that even a small stopping distance presents a serious crushing hazard, then you should not be using collaborative motion at all, it won't get through a properly-done risk assessment.)

If you are running the robot fast enough so that you have to rely upon the safeguarding, and thus you have to apply all of the safety distances etc to stop the robot before anybody can get to it, then what's the point of it being a collaborative robot?

If the intent is to let the robot run fast when nobody is fiddling with it, and then slow it down and go into collaborative mode when somebody is interacting with it, and the application requires such interaction, then what's the point of allowing high-speed mode? If the process requires such frequent interaction then the robot is never going to be going into high-speed mode anyhow because the operator is always going to be in there.

Most of the applications that I crossed paths with, ended up running in collaborative mode all the time with speed and force limitation active all the time, and the safeguarding was less critical.