DoF - a Robotiq Community
Warning sign
The Dof Community was shut down in June 2023. This is a read-only archive.
If you have questions about Robotiq products please reach our support team.

I have a UR16e running URScript code I wrote where it is getting positions each cycle then using ServoJ to move. The issue is that it very frequently gets very non-descriptive "Violation" errors and locks the breaks. I understand that servoj requires that I give small incremental differences in position, and I am doing that. I am able to get this to happen when it is moving very slowly and the sensitivity to the issue seems to be very dependent on the TCP position. When the TCP is about a foot in front of the base, the issue is much more likely to happen than when the arm is mostly extended. When I was developing my application, I was testing on a UR3e which had none of these issues. In order to more reliably be able to reproduce the issue, I have been testing on the "most restrictive" safety mode, although I get the same issues on the "least restrictive" mode. At first I assumed the issue was due to not handling acceleration, but I now doubt that because my tests are moving so slowly and it frequently fails after it has been moving for a few seconds and not immediately when it starts moving. I have tried tweaking the TCP mass and center of gravity with and without tools and seen no difference. Also I have the UR16e mounted on its side with the installation settings configured to support that.

In order to make a repeatable test, I made a test script that causes the problem while moving a single joint very slowly. This causes the error on the UR16e in the "most restrictive" safety mode. As it is, it tries to move the base joint ten degrees in ten seconds and usually fails after about a second.

def main():
  joint_index = 0  # Specifies the joint to move
  joint_angle_diff = d2r(-10)  # Specifies how far to move it.
  joint_movement_duration = 10  # Specifies how long it should take to move it.

  #Calculate the total number of cycles and how much to move each cycle.
  #NOTE: This is divide by 4ms because servoj time of 2ms causes it to roll over into another scheduler cycle which means 4ms per cycle. WHY SHOULD 2MS BE USED??
  total_cycle_count = joint_movement_duration / 0.004
  cycle_angle_offset = joint_angle_diff / total_cycle_count


  #Get initial position.
  joints = get_actual_joint_positions()

  #Initialize counter.
  current_cycle_count = 0

  #Loop until the counter is done.
  while current_cycle_count < total_cycle_count:
    #Update the joint angles.
    joints[joint_index] = joints[joint_index] + cycle_angle_offset

    #Move to the new angles.

    #Increment counter.
    current_cycle_count = current_cycle_count + 1




Can anyone give me more information on this error? I'm having a hard time finding any information on it.
Thanks in advance.