What does everyone typically have the normal and reduced mode safety settings set at whenever they are not using light curtains, area scanners, or pressure mates for a UR 10? I have a unique challenge with my project. We want each robot to perform their tasks in ideally 20 second cycles, but our absolute max time is 23 or 24 second cycles. I was doing well with this originally but my boss didn't like how hard the UR would hit you before it stopped, the way I originally had it set up it met the guidelines laid out in ISO/TS 15066. So it was safe to work around but he is afraid people will see how fast it is moving and be afraid to work with it. I played around with the all of the settings and came up with a pretty good combination that stops quickly, but now the issue is with the changes the UR is significantly slower so we won't meet our cycle times for most of the stations. Right now this is what my settings look like, Normal Mode: Force 100 N, Power 80 W, Speed 3000 mm/s, and Momentum 10 kg m/s. Reduced Mode: Force 100 N, Power 80 W, Speed 2800 mm/s, and Momentum 7 kg m/s. Any thoughts on how I can make it stop with little force but move quicker? 
Thanks!

@abeachy_HG24
this is a really good challenge that you are facing. We ran into the same issue in the past with light curtains on a robot cell. Operators were constantly walking through the robot zone, making the robot go into reduced mode. However, the operator did not have to go next to the robot that often, the robot cell was simply just to close to a walking trail where operators would walk and take a shortcut that was entering the robot's safe zone. If like us, the operator does not have to work to much close to the robot, you can do like we did, we added a simple Danger plastic fence just to make sure people did not take the shortcut that was crossing the robot's zone. 

Otherwise, I know this may sound silly, but if you look at the variables that you need to address if you want to reduce force of the impact would be to increase impact time and dissipate impact force. Have you considered adding some sort of padding material on the UR like we see on the green Fanuc CR35iA? I did not see this anywhere else but I think it would be an idea.

@Grady_Turner @Cody_James Any insight on this matter with any projects you've been working on?

@Sebastien Our operators will be working placing parts into fixtures for the robot to pick up, and with the robot picking a part roughly every 20 seconds the operator has to be in that space quite often. We have considered adding light curtains so the robot could actually run faster than it is right now when the light curtain is not broke. But that means we would 30 more light curtains as we have 30 robots going into production. 

We have considered that, but my boss did not like that idea very much. He believes people would see that and think that it was too dangerous to begin with so we gave it sort of a "bandaid" to cover up the issue instead of actually fixing it. 

We had a similar issue, what we did was to create a safety plane right where the robot and human interacted. When the robot entered the human zone, crossed that plane, he went jnto reduced mode. Behind the plane where the robot was working in his environment he would go back to running at full speed so we could hit cycle times. This allowed the operators to feel that the robot was safe to work with but allowed the robot to run at full speed where possible to meet cycle times. 

We we just had a physical demarcation between the robot and the human/robot zones so the employees knew where the robot would slow down. 

Our operators will be stocking the parts within the pink box so this is where the robots and operators are most likely to come in contact with each other. It is possible that they could reach past and interfere with the other operations, they shouldn't but they could. Right now I have a horizontal safety plane set up about 6 inches above where the robots are picking the parts and the safety plane triggers reduced mode. What I have been considering trying is removing that safety plane and putting a vertical safety plane in right at the edge that is furthest from the operator. That way any time the robot is behind the safety plane it can run faster, but whenever it is over any of the parts it would be in reduced mode. Not sure if this would gain us the cycle time, but it might. 

That would probably help to speed things up. Another thought that we have done is to put the downward moves inside of an if loop that is looking to keep the force below a threshold.  Make sure you check the box for checking the condition constantly. This way if you are moving down and come into contact you could always pull back and then pop a message up to have the operator tell it to continue or it could just move up, wait a couple seconds and then try picking again. 

Just an observation, I recommend being careful using cable ties to hold the cables to the robot. We have had issues where the cable gets in a bind and we have cut the outer sheath on the cable and rendered the cable non operational. We were fortunate that it was not the pigtail coming from the gripper so it was an easy fix. We use 2 sided Velcro to hold the cables in place of our new cable management system we designed. 

Okay that makes. I like that idea, I might have to try that. 

Yeah we don't necessarily like the cable ties, they work but they are definitely not the best way to go about it. We have been talking about trying to come up with something different for the cable management. Do have a specific brand of the velcro that you guys like to use? 

It's a 3M product. Industrial grade. I'll see if I have a package lying around I can shoot a picture of. 

All of you are welcome to solve my problem here. I specifically tagged @matthewd92 
for I went ahead with his approach first. :)

@matthewd92
I tried your suggestion of defining safety planes by defining two simple way-points(one before the safety plane and one after)and it worked like a charm (by keeping same and different values in the general limit of safety configuration for normal and reduced mode). Thank you!
But then, I tried to implement the  same in my ongoing project at my university and the robot seizes to enter the safety plane altogether. It stops before entering the safety plane and gives me a protective stop message. I thought the General limits (in safety configuration) that I had defined for normal and reduced modes posed a problem. I was wrong there, as I tried to keep all the 4 values in the General limits (both normal and reduced mode in safety configuration) same and yet again the robot seized to enter the safety plane zone. Any inputs/ideas/suggestions as to why my UR is behaving so? 
Note: All the joints are well within their respective extreme limits
  

Hi all, I am having isues with the way my robot goes into reduced mode and stopped mode.  I have an omron safety area scanner.  When someone walks into an area the robot goes into reduced mode, then if they continue forward they could get into a safety stop.  This is fine and what we want. Although depending where the robot is at if its turning wrist 3 (seems to be the main problem) it will stopp. Also when they come out of the zone the robot wants to try to go full speed right away and deviates from path.  Is there a way i can make it go from reduced mode to say 60 % speed then 70% then 80% then 100%,,, I tried this with a script but it kept going back and fourth on me causing the robot to jerk around even more.   Thanks for any advice i can get. 

@harini26 are you using a blend in the waypoints from one side of the plane to the other?  If so, try taking the blend out.

@meeksy we are using the Omron safety scanner as well, we generally just due safeguard stop as soon as they enter the danger area, we don't have any cells where we are using a safety scanner where the robot should slow before stopping.  We don't have issues with resuming operation coming out of the safeguard stop.  The robot goes right back to 100% immediately.  Where we do occasionally have protective stops when entering the safeguard stop is points where the motion is blended.  Its not every time that it enters safeguard during those moves that it faults but I would say its better then a 7/10 chance that it will fault.

@harini26 I would check that the plane is setup for reduced mode not a hard limit, remember the only option that will make a plane cause reduced mode is the option "Trigger reduced mode" the other three are hard stops. 

@meeksy at this point Universal Robots does not have a fix to the potential "jerky" motion seen at the TCP when entering/exiting safety planes but there are some work around: The first I believe @matthewd92 mentioned already- set a waypoint just before the safety plane and just after with a slower speed going into the plane and a faster speed exiting the plane so that during each trajectory the TCP is a bit more controlled entering/exiting reduced or full stops. The second involves controlling the speed slider programmatically so ideally the scanner would first trigger this event in your program which will slow the robot to say 50% then it will enter the reduced mode then upon exiting the safety zone you can put the slider up to 75% or 100% just before it exits the plane and it will smooth out the motion. Further information and examples on this can be read here https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/setting-the-speed-slider-from-a-program-15293/ 

@matthewd92  and  @UR_USA
Thank you so much for your respective suggestions. It is working fine now. Another question on the same grounds is as follows:
Is it a bad idea to define a safety plane (with Trigger Reduced Mode) closer to the home position of my robot in my project? Sometimes, it so happens that the robot gives a protective stop pop-up if I tend to define the safety plane close to the home position in my project. Is it so, that the UR robot needs time to trigger and change the speed from normal to reduced mode? And, too close a distance refrains the robot from doing so? Any leads here would be helpful.

@harini26 I'm not sure where your home position is but assuming it is near the base of the robot it is easy to get protective stops with/without safety planes simply because it is easy for joints in line up and singularities to occur. Anther main drive for protective stops with safety planes is simply too large a difference between normal ad reduced mode so that 'jerk' faults the robot out. 

@UR_USA  Thank you for your response.
Let me put my question a little more in detail.

I currently have a Universal robot and a conveyor belt as a part of my project. The task of the robot is to pick a certain workpiece and place it on the conveyor belt. The home position of the robot (which is also my 1st waypoint and is pretty away from the base) is around 40-50cm diagonally away from the conveyor belt. My 2nd waypoint is 30cm straight above the conveyor belt. My 3rd waypoint is few centimeters straight above the conveyor belt. I have built a safety plane say around 10-15cm above the conveyor belt. The waypoints are such that my 2nd waypoint is above the safety plane and my 3rd waypoint is below the safety plane. The safety plane is set to 'Trigger reduced speed'. My normal speed value is 500 and reduced speed is 250. So my robot starts from waypoint 1, goes to waypoint 2 and then drops the workpiece after reaching waypoint 3. The safety plane is constructed between waypoint 2 and waypoint 3 (so as to make sure the robot drops the piece carefully!). But the problem is, my robot gives me a protective stop as soon as it touches my safety plane and seizes to enter further (which should not happen in the 'Trigger reduced mode'). I thought that the speed values (keeping in mind the speed change and jerk problems) could pose a problem and so I tried with the same speed values in the normal and reduced mode (just to test whether my robot at least enters the safety plane). Unfortunately, the robot did not enter the safety plane and stopped as soon as the gripper touched the safety plane. Whereas, a safety plane with 'Trigger reduced mode' constructed elsewhere in the same project works absolutely fine. Why is the Universal robot behaving this way with the safety plane, just close to the home position? 
If safety planes feature cannot solve my need of dropping the workpiece slowly on the conveyor, what other things can I possibly do to achieve the same aim? Any suggestions/ideas/inputs would be highly appreciated.

P.S: 
1. I tried to play around by changing the speed and distance values as per the basic formula of speed but none worked on the robot and it seized to enter the safety plane near the conveyor belt. 
2. Just to assure you all, none of my robot joints enter the safety plane. It is just the gripper and the workpiece that enters the safety plane near the conveyor belt. 
3. My robot works absolutely fine and performs all the tasks as required near the conveyor belt if I disable the safety plane on the conveyor (Just that it drops my workpiece little harshly).

Why not just use a slow speed for waypoint 3?  You can check the advanced box in the waypoint and then give it a different speed and acceleration from the rest of the move.