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.
Only thing I've been able to find: https://github.com/ros-industr…evel...isys-vision:ikfast.
They seem to be doing the same thing (ikfast appears to be an ik solver generation framework).
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.
Please see attached. I did this in Roboguide with a R1000iA/100F running Handlingtool V8.20.
I do not speak English, but I understand that you want to move the robot to an position outside of axis limit.
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.
