Sometimes the following code fails with a popup “the robot cannot reach the requested pose”…
if (is_within_safety_limits(pos)):
kin = get_inverse_kin(pos, qnear)
end
Theoretically, the is_within_safety_limits() function shall be used to avoid getting error popup from the get_inverse_kin() but for some positions it is not consistent.
We need a solution that will REALLY NEVER stop the program execution with that error message. What can we do?
See this screenshot from the script manual, is_within_safety_limits() takes into account safety plane limits and TCP orientation limits, where get_inverse_kinematics() will just return the joint positions of a given Cartesian coordinate, regardless of whether or not that position violates any of the robots safety.
Thanks. According to this manual, is_within_safety_limits is more restrictive than get_inverse_kin, so my sample code above should never fail, but it does. 
is_within_safety_limits(pose) does not take a qnear as argument, it uses the actual position as qnear therefore it may not get the same result as get_inverse_kin()
What is the use case? do you need to check for inverse kinematics solutions near singularities?
if you just call normal move commands, computing inverse is done behind the scenes?
The robot is calculating different path for different product sizes, there is no actual movement at this step. Of course the calculation must NOT stop with a popup.
I see that the exception is not very useful to you
You can consider what it helps you to calculate the inverse kinematics?
You cannot in general say if the path is achievable, only the end point. And depending on what q_near you choose, the controller may choose another joint path (that may or may not be achievable)
We use a vacuumgripper that has Y-offset in the TCP. Our goal is to evaluate several different paths and choose the optimal one (i.e. which gripper rotation is best for a specific pickup- and target position)
The inverse kinematics is one of the input parameters to our cost function that will choose between the possible movements.
Below is a specific example that produces the error on a UR10e. The qnear parameter is not in use.
set_tcp(p[0.0,-0.1,0.131,0.0,0.0,0.0])
tool_pos = p[0.25512,-0.0480101,-0.437914,2.21997,-2.22,0.016226]
if (is_within_safety_limits(tool_pos)):
invkin = get_inverse_kin(tool_pos)
end
For some reason, is_within_safety_limits lets the program run into get_inverse_kin which then fails with the exception.
Okay, I see your idea.
Currently we don’t have a way to prevent this to happen.
Actuallty when you call is_within_safety_limits(pos) a call to get_inverse_kin() with the target joint positions is called.
So the added value of the extra call to get_inverse_kin() is very little.
I suppose if you call get_inverse_kin() with get_target_joint_positions() as q_near then you wont get the error
I have posted a workaround in this post: