Kawasaki RS007N odd cartesian values seen on the TP

    Hello,

    We have a Kawasaki RS007N robot and I suspect something is wrong with the cartesian coordinates displayed on the TP.

    The symptoms are:

    • When the robot's joints are all 0s, X value is close to 0, however, Y value seems to have an offset of ~128 mm.
    • When the robot is in the same position as described above, or other positions, its Z value is significantly greater than the robot's reach as described by the specification sheet of the robot (should be 730 mm, but values of up to ~1100 mm are seen).
    • The positions have also been compared against RoboDK and ROS models, and they do not match with what is seen on the real robot's TP. When the same joint positions are input for the models, the robot position itself looks correct (looks just like the real robot), however, cartesian positions do not match between the models and the real robot.

    What we've tried:

    • Making sure Base Coordinates are set to 0s
    • Making sure Tool Coordinate Data are all 0s (all of the tools are)

    The only other idea we have right now is to check Robot Installation Posture, as it seems like it could change the Base Coordinate system orientation. As i do not have physical access to the robot, I am waiting for updates on the status of these settings. However, i do not believe that this could explain such a great difference in Z positions when considering robot's reach limits :thinking_face:

    Would anybody have any other ideas regarding what other robot settings could impact the cartesian coordinates, or is there something being overlooked here maybe? :smiling_face:

    Thank you for any help in advance

    Edited once, last by coffeeBean (November 14, 2023 at 3:31 PM).

    Hello!

    It's a very strange behaviour. If you already checked BASE and TOOL coordinates, the only idea I have is to check the robot model in Menu -> Aux. Functions -> 8. System -> 4. Software version

    I once had such problem with an old second-hand robot, so that's my idea.

    Also, could you get a backup from robot?

    Robot monitor displays:

    - Current joint angles.

    - Current TOOL coordinate from current BASE coordinate.

    Joint angle and Cartesian are like comparing coffee bean to baked bean, both are beans, but that's it.

    Both are described as positions, but actually:

    - One is absolute posture.

    - One is transformation value.

    Quote from coffeeBean

    The positions have also been compared against RoboDK and ROS models

    LOL a sure path to face palming................ :pfeif:

    When did this start happening?

    What were you currently doing when this was noticed?

    Have you loaded any alternative programs or backups in?

    Has there been ANY collisions big or small?

    Have you checked and confirmed mechanical zero by using scribe lines.

    Can you visit previously stored locations such as dedicated HOME posture.

    What is SYSTEM SWITCH QTOOL set to and what values are displayed in Aux 0304?

    Also do you have FIXED TOOL enabled?

    How does the robot move in JOINT and BASE modes, do they move in correct directions and axis?

    Thank you both for the suggestions!

    kwakisaki After trying a couple of things it seems like setting QTOOL switch to ON solved the issue... however, I am still puzzled as to why, or rather what the real issue was :icon_confused:

    It is not really known at the moment what this robot was used for before. As I am not physically with the robot, I could only see through a video call how it looks like when it is jogged in Base mode, and it looked correct (although obviously it is not the best way to evaluate this, so emphasis on looked). When jogged in Joint space it looks and behaves as expected. The Aux 0304 all tool data is set to 0s for every tool. The Installation posture was also Floor with 0 degree rotation around the X axis.

    We also have another robot: RS005N. I checked the switches on that one, and QTOOL there is OFF - never encountered such a problem, therefore I suspect some other setting having the impact.

    As I understand from the manual, QTOOL ON implicitly applies tool transformation as predefined in the Aux 0304? Would that mean that now it is overwriting some different transformation? If so, what could it be/where could it be defined?

    With regards to FIXED TOOL enabled - we have not checked if it is enabled or not... :icon_frown: However, when looking at the manual, I formed an impression that it's like a "user frame" which the user can define with regards to the base coordinate system of the robot. If that is the case and the robot is set to be jogged in Base, wouldnt positions visible in the monitor display be: joint values of the robot and the TCP transformation in robot base coordinate frame? Maybe I'm missing something here :icon_confused:

    Also I should mention - after turning the QTOOL switch to ON the robot position data that we checked and believe to be right was using HERE function in AS language. I also requested a picture of the TP to see if it is updated in the monitor as well, or if we still see some different transformation applied there. Or would that and what HERE returns always match? In the manual it just says that it returns robot's transformation value, but doesn't explicitly say in which frame, whereas WHERE command will return it in base coordinates.

    Thank you very much for your help. I still want to try and understand what exactly is impacting this TCP transformation or in what frame it was being displayed.

    Kawasaki uses 2 standard coordinate systems:

    - TOOL

    - BASE

    In addition you can have FIXED TOOL (option).

    - Which is as the name implicitly implies, a fixed tool coordinate system.

    User frame terminology does not exist in Kawasaki.

    QTOOL is used to either:

    - ON is to use Aux 0304 values.

    - OFF is to use T0 values which is set by TOOL command in AS Language.

    These are fundamentals of Kawasaki programming courses and have immediate and permanent effects to current Cartesians (transformation values) unless changed by TOOL button on the teach pendant (QTOOL ON) or by programmed TOOL command in AS.

    Have a read of the following thread, this may assist you regarding QTOOL and the inconsistencies you are seeing:

    Tool mode motion incorrect, need hints on diagnostics & correction - Kawasaki Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Advertising from our partners