How the A:2,3 Limit Error is Calculated

  • Does anyone know how the A:2,3 MOTN-017 limit error is calculated? This error occurs when the arm is too bunched up on itself.


    It seems to be a consistent J2/J3 interaction number (-78.8 degrees on R2000s, and -81.2 degrees on R1000s), but it stops being constant once wrist center is below the J2 motor.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

  • Place your Ad here!
  • The number after the A is the hexadecimal digit that shows which axes are out of limit. The Hex indicates that the axis numbers are in hexadecimal format.
    Based on your message axis 1, 2 & 6 are out of their interaction limit. If you require further assistance you can contact me to give you the Hexademical table interpretation from the oficial FANUC manual.


    edit: A:2,3 is a bit misleading. If it is A:2 then its an axis 2 limit error. If it is A:3 Axes 1 and 2 are out of their interaction limit. If it is A:23 the Hexadecimal notation points to axis 1, 2 & 6 out of interaction limit. I never trust the motion planner when creating new programs anymore. Especially in my kinds of applications where the robot needs to move like a delicate human hand to perform fine grinding operations on small metal pieces. Motion planner apparently likes to mess up the rotation configuration of 4,5 & 6 axes for no reason when creating new points leading to a waste of cycle times and many times limit interactions. I made a habbit of always confirming kinematic configuration when creating new points.


    Hope this helps.


  • The number after the A is the hexadecimal digit that shows which axes are out of limit. The Hex indicates that the axis numbers are in hexadecimal format.
    Based on your message axis 1, 2 & 6 are out of their interaction limit. If you require further assistance you can contact me to give you the Hexademical table interpretation from the oficial FANUC manual.


    While this was the case on R30iA and earlier, the newer R30iBs just list the axes in question that are causing the issue. You no longer need to look up the hex code.


    Also, this doesn't answer my question. Some background: I am writing an offline inverse kinematic planner geared for the verification of boundaries in line tracking paths, and I need to know how the Fanuc controller generates the error listed in the subject of this post in order to accurately test the reachability of all points at all tracking locations (with various offsets to the path). While is seems to be a constant number depending on the J2/J3 interaction when the wrist center is in the positive Z range, it seems to vary once the wrist is below center.


    What I am looking for is an equation that would describe when that alarm is to be triggered, preferably with J2, J3, and link lengths as inputs.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

  • While this was the case on R30iA and earlier, the newer R30iBs just list the axes in question that are causing the issue. You no longer need to look up the hex code.


    No it doesn't. I cannot really help you with your project as it is a development part never touched by me but I can tell you for sure the numbers still refer to hexademical notation even on the R30iBs.


  • Please see attached. I did this in Roboguide with a R1000iA/100F running Handlingtool V8.20.


    Then it is robot dependant or Roboguide autotranslates the hexademical notation. My R30iB controlling M710iC robots still reports hexademical notation. The alarm manual for R30iBs still "talks" about hexademical notation too.

  • Then it is robot dependant or Roboguide autotranslates the hexademical notation. My R30iB controlling M710iC robots still reports hexademical notation. The alarm manual for R30iBs still "talks" about hexademical notation too.


    The manual does "talk" about hexadecimal notation, and it is still used on several different alarms, but not this one.

  • I have the same problem. I have an algorithm to do path planning and send trajectories to the robot with user socket messaging option. The robot is blocked sometimes when neither of the angles are beyond boundaries with the error being "MOTN-017 Limit error (G;1, A:2,3)". In the specifications for the robots, they usually specify the limits on j2/j3 interaction which is j2+j3 (upper and lower) but i'm getting this error even when i'm between the upper and lower limits.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners