Posts by kwakisaki

    Sounds like power block (IGBT Modules) issues or possibly the driver modules (1DD/1DT) to me.

    Bugger to test out unless you have spares though.

    Motor power will always go off as it is classed as a fatal error. and any power block related issues usually will not show their face until actual motor power is applied.

    So you are unlikely to see it during startup, only when demanding motion.

    Have you checked any of the documentation here specifically the AD Electrical Manual for further assistance and checks, it contains a lot of good detailed information that may help.

    A and AD Controller Documents - Manuals, Software and Tools for Kawasaki Robots - Robotforum - Support and discussion community for industrial robots and cobots (

    Sadly I have never used them and from all accounts, not all that popular either as integrators tend to stick with their own developed/integrated solutions.

    I do believe in Kawasaki's wisdom that it is not just a software application that this consists of, I think arbitrary hardware is supplied with it also, including PC, Lighting Unit and Controller and License USB hardware dongle.

    I believe the software has many different 'learning/training' tools though and would speculate (as with many Kawasaki products) a high degree of flexibility.

    For this reason, I doubt it would be a cheap price tag either and therefore I would certainly contact your local distributor for more accurate information and it wouldn't surprise me if they offer demo units or at least be in a position to demonstrate the products full capabilities.

    You are not using QTOOL at all anyway, I was merely making a recommendation should you be using the aux func 0405 to make things a little easier.

    If your tool direction or orientation is not changing and you a merely bringing the tcp closer to the centre of your flange and increasing the length of it, then yes, just by adjusting the Y and Z values should be applicable.

    Dependent on how accurate your tcp is going to be used, then will depend on whether you should just alter the values or actually re-teach it in as these values are representing the new physical tcp for the robot.

    Do not assume the 'fastest route' is going to be the best route.

    You have several ways of defining tool values when using QTOOL OFF:

    1. Locally setting tool values, does not store values as a location (not in a program).

    - Typing in TOOL and pressing enter and then setting the values and pressing enter again.

    2. Create a location and then recalling the values and applying it to the tool coordinate (used in program).

    - POINT new_tool = TRANS(0,300,900,90,90,90)

    - TOOL new_tool

    3. Entering direct values (can be used in a program)

    TOOL NULL+TRANS(0,300,900,90,90,90)

    What is your use of 'arm' meaning here, as what you are saying doesn't quite make sense?

    I am assuming you are talking about some part of the tool assembly but assumptions can often lead to incorrect advice.

    What are your current OAT values you are using?

    If it is a case of 90 degree difference only, then dependent on how it's mounted to the flange relative to the null tool coordinates, then it may be as simple as adjusting O and T values.

    However, I would probably teach it in.

    Have you read and tried the 'unknown tool method' available in the AS language Manual, I think somewhere in section 11, this is an alternative to auto tool teaching and uses the robots compound transformation calculation to return the tool values....only use 2 positions called the A&B method?

    How are you intending to get the applicable XYZOAT values into the controller for the new tool?

    Using Aux 0405 or using CAD data?

    If you are using aux func 0405, I would recommend:

    - Turn QTOOL ON

    - Set the Tool1.

    - Teach the TCP and store the values for Tool1

    - Then create location using keyboard - POINT new_tool = TOOL

    - Turn QTOOL OFF.

    - Then use TOOL comand to set tool - TOOL new_tool

    Using this method, if someone buggers with QTOOL, then by default you will also use the same tool values from aux 0304 (assuming no one changes the Tool no. using A and TOOL keypad button).

    You could go over the top and set aux func 0304 tool1 to tool9 to the same values as your tool.

    I don't usually do this, but when I started out, I applied this so to ensure my tool was always relative to my fitted tool (if never changed) and if someone wanted to use BLOCK with my current tool, they could freely turn QTOOL ON and not really have to remember to turn it OFF as I included QTOOL and TOOL as a programmed command in my startup sequences to ensure correct tool is used.

    I have added some additional info to my previous post relating to the D controller, including a link to relevant post which you maybe interested in reading.

    No.3.......try it out by toggling QTOOL ON/OFF.

    EOAT is always a 'cloudy' area in the Kawasaki as there is much flexibility within the controller setup and configurations as opposed to being 'forced' to set something.

    I really wish when using Kawasaki, this topic is firmly understood as it could lead to disastrous consequences if not fully understood.

    This is no fault of your own, Kawasaki documentation and training do not sufficiently cover this either.

    So in short order:

    Kawasaki controllers have 2 programming conventions:

    - BLOCK

    - AS

    Kawasaki controllers are usually supplied as default with a system switch turned on:

    - QTOOL ON

    Kawasaki controllers can operate quite successfully mixing BLOCK and AS conventions.

    Now it you are using mixed conventions, QTOOL settings need to be controlled appropriately.

    If you are only using one convention permanently, then QTOOL should be set to the applicable condition, either ON for BLOCK or OFF for AS.

    The key points to remember here are:

    1. QTOOL ON - Generally used for BLOCK programming conventions.

    - Uses Aux Func 0304 Tool1 to Tool9

    - Selecting a Tool no. (A and TOOL keypad button) when in tool interpolation uses Aux 0304 values.

    - This Tool no. is stored within the BLOCK programming step when recording a position.

    - If changing tools inside BLOCK is used, then you would simply select the required Tool no.

    2. QTOOL OFF - Generally used for AS programming conventions

    - Uses something known as Tool0 (but you never see/hear anyone speak about this).

    - TOOL command is used to directly apply an XYZOAT value, or use a transform location to set Tool0.

    - If changing tools inside AS, this requires TOOL command to be used.

    3. Now the bonus round - You are using D Controller.

    QTOOL ON will display Tx number T1-T9 in Tool interpolation icon (using Aux func 0304 Tool1-Tool9).

    QTOOL OFF will display T0 in Tool interpolation icon (using AS TOOL command to use Tool0).

    Check out the following thread, as this may be of interest:

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

    Also look at the video I posted in #8.

    The Qtool setting is also off, which I thought should be on. I have values for the old tool dimensions in x, y, z when I do a list/l command. The original tool was set up by an integrator.

    This makes total sense and tells me you are using AS and not BLOCK and the above is correct.

    1. All you would need to do is to setup another transform location in the location register and then use the TOOL command to set those values.

    2. Or you could directly use the TOOL command to use entered XYZOAT values instead.

    3. Aux Func 0304 values are not applicable.


    I would love to see the 'big picture here', as what I am reading, I think I may be mis-reading things.

    Imposing restrictions (for good reasons) should be understood between programmer and end user.

    You will never 100% make a system 'human proof', but applying too much can also reduce the 'freedom' to the end user in using their own purchased/owned equipment.

    I am not criticising, but offering points of consideration.

    1. What if they use teach mode and move robot to unsafe start position and leave there before start.

    Have you any check to ensure robot will not wipe something out?

    2. Your PLC.

    - Sends the relevant bits to select which subroutine is called.

    Why is your PLC not controlling the priming of pg0 using automatic output from robot also?

    3. Your Subroutines.

    - Are checking for a watchdog value set in pg0.

    No need for watchdog if you set in the subroutines to re-read the PLC bits and carry out HALT instead.

    4. Your autostart program.

    - When in repeat and motor power on and cycle start on, will attempt to kill and prime pg0.

    This will result in an instant 'Cannot KILL program that is running' error and stop the autostart task.

    5. Problem with uncontrolled priming of program.

    If robot stops mid production run end user will not see program and step of failure due to prime.

    6. SYSDATA command.

    - You cannot remove change step functionality - 'A' button and up/dwn cursors always allow change.

    You can use SYSDATA(MSTEP) command to read step no. for comparison check.

    7. WHICHTASK command.

    You can use command for checking program in program window is correct.

    8. PRIME command also has additional parameters.

    Used in conjunction with WHICHTASK could ensure correct program is primed.

    Used in conjunction with SYSDATA(MSTEP) value, could force correct step is always used.

    9. How is the robot actually going to be started for production run for motor power and cycle start.

    - Teach Pendant or PLC/HMI?

    What you are planning/agreement with end user may suffice already, but always worthwhile exploring other options for application to make sure best methods are applied to full fill requirements.

    I refer to an R-30iA Controller Maintenance Manual I have revision B-82595EN-1/05.

    Specifically there are emergency stop output contacts made available on TBOP6 of the panel board.

    Labelled ESPB1/ESPB11, ESPB2/ESPB21, ESPB3/ESPB31, ESPB4/ESPB41

    These are potential free dual contacts directly driven from the TP or Operation panel emergency stops buttons or if the controller power is off and there are 2 pairs of dual contacts available.

    - Both/either button pressed or controller power off - Contacts are open indicating safety loop is open.

    - Both buttons released and controller power on - Contacts closed indicating safety loop is closed.

    These are not safety checked though, so it is recommended to use these outputs to drive the dual channel inputs of a dedicated safety relay (which will safety check them for mismatches or shorts) and provide a suitable safety dual channel output which can be used for safety disconnection purposes.

    Back in the day I am sure it was not recommended to disconnect the output of the VFD to the motor by way of safety disconnect, due to transients caused during the opening of contacts associated with AC circuits, but to remove power to the VFD or an initiation of a stop category (if available) in line with machinery directives and suitable risk assessment.

    I don't know if this has changed now due to technology, so you would need to consult the VFD documentation relative to safety disconnection recommendations and design the circuit accordingly.

    As for the PLC, I think this will be down to your own conclusions on how this should be controlled.

    The other alternative if your PLC has safety rated devices attached is to use the outputs to drive the safety inputs of the PLC to control the safety outputs of the safety disconnect of the VFD.

    As always when implementing safety circuits, ensure all local and national regulations are followed and suitable risk and methods are applied and in line with directives associated with your locale.

    Negative Y of what exactly BASE, FRAME or TOOL?

    You say you have compared data values to be correct, so how can you say it is negative Y of anything.

    The problem has happened before, and has been corrected with reteaching to the settings that the robot was doing without issues.

    What does this mean exactly?

    - Re-teaching positions.

    - Re-loading an earlier backup.

    - Zeroing, changing configuration settings.

    There is no 'quick fix' until the source of the problem is correctly identified.

    Some answers to many of my listed points would help me advise you to determine where the problem is.

    and now it seems to for no found reason and no alarms

    There is ALWAYS a reason, or else it wouldn't happen.

    Without ANY details, just what are you asking, if it has been seen before, then yes.

    If you are then asking for an answer, then this is where details are required along with your story.

    If the robot is not showing errors, then it is very likely doing exactly what it is told to do with the configuration, settings, programs and data associated with how it's been setup with.

    1. Why do you think this is an encoder issue when no errors or alarms are being produced.

    2. What is 6 to 8 inches at least off mean.

    3. In what direction is 6 to 8 inches at least.

    4. Does it go from good position to 6 to 8 inches, or does it gradually drift until someone notices.

    5. Is 6 to 8 inches your measurement values or the robots measurement values.

    6. Values would help - ie programmed position values vs actual position values when noticed.

    7. Has the robot suffered ANY form of collision.

    8. Are there any loose bolts ANYWHERE relating to mounting points.

    9. Have you checked all mechanical zeroing for all joints.

    10. Have you tried and identify which joint(s) are causing this 6 to 8 inches.

    11. Have you run a simple test program to try and replicate the problem using joint angles.

    12. Has the external axis been correctly configured.

    13. What programming are you using AS or BLOCK.

    14. What steps are you referring to when you say reteaching steps.

    15. Have you checked whether these steps need reteaching.

    16. Are locations calculated and creating shifts from a reference position.

    17. What about providing some code example of what is being executed.

    18. Have you got any holy water to sprinkle on the application - Just in case you do need to call a priest.

    Any program executes from step 1 to last step and finish.

    If autostart program does not contain infinite/conditional loop, then it will only execute once.

    PCEXECUTE autostart.pc,-1 is the specific command to execute PC Task infinitively.

    You must study AS Language Manual for best way to achieve for your application using variations of:




    IF (condition match or condition does not match) GOTO LABEL

    Also you must study PC Control commands in AS Language Manual for:








    For instance you could use simple instructions like:



    IF (condition match) THEN

    'running code goes here'

    GOTO again



    WHILE (condition match) DO

    'running code goes here'




    'running code goes here'

    UNTIL (condition match)

    Please start a new thread in future as this is not relevant to this thread.

    Your file name is too long.

    Reduce the size of it to 8 characters ensuring your start with a letter and not including any special characters.

    ie maineos1

    Kawasaki supplied different spec C controllers for North America, Europe and Asia which are basically the same hardware but have different firmware, settings and sometimes settings bespoke to a specific client such as Ford spec or Aus spec relative to the safety and standards for that location.

    (C2x, C3x, C4x Controller variants).

    A hardware reinitialization completely removes all of these settings relative to the installed firmware used and sets them to a default for that firmware so unless you know these settings or have a known backup, then hardware initialization usually renders the controller in-operable.

    Hardware initializations should only be carried out when a previous known backup is available and 1GA/1HA is suspect of corruption, being bad, or for firmware upgrades.

    Unfortunately as of late, many people are carrying this hardware initialization out BEFORE making sure they have some means of restoration and at this point.......everything is lost and the controller is rendered in-operable until basic configurations are set.

    Usually for a client to 'empty' the controller of all user data (not system configurations), they would just carry out a software system initialization which is via Aux 100.

    This only removes user data and resets non operational critical settings and does not impact on the core functionality of the controller/arm.

    There's a section here at Robot Forum you can advertise freely should you decide to sell it:

    Used Robots and parts - Robotforum - Support and discussion community for industrial robots and cobots (

    Also Global Robots in the UK buy and sell 2nd user systems, they maybe interested.....not sure just what they would offer, but worth contacting them should you decide to sell.

    20 years old then...............nice.

    Another example of Kawasaki Robots longevity, but as you say if there's not a lot of working hours on the clock, then it could certainly be re-purposed or possibly sold on.

    You're welcome, I love the C Controller and recently more and more of them are re-appearing on the 2nd user market for re-purposing and returning the controller to a default condition or in your case where they have left dormant for years.

    As long as the hardware is functioning, then getting them back into operation is always good to see,

    Also, the backup you sent me back. what changes did you make? i feel like some configuration was set wrong?

    Back in the day upon a failed 1GA/1HA board, Kawasaki would send a replacement already loaded with the correct firmware level and then you would just need to carry out an initialization and the load in a previous known backup to return it to operation.

    In theory a 5 min job.

    What we have done is apply the same procedure but addressed the AS firmware issue.

    As you didn't have a previous known backup, then specific settings applied at manufacture/delivery state are lost and these usually include features/functions that maybe improvements based on the firmware used which do not get set at the firmware level.

    So it is these I have set for you so that you have the bear minimum configuration to use the robot.

    These settings would have been included in a previous known backup.

    I don't publicise specifics as sometimes they are not required and if applied incorrectly could render the controller in operable or sometimes create dangerous issues,

    The only thing I will say, is download a program called winmerge.

    Use this to compare a live backup with the initial backup you sent, and you'll see several settings changed, these are the minimum settings required for your controller.