Posts by kwakisaki

    You use it when you want to use the functionality of it in the application.

    ie selecting programs from a PLC by way of IO signals.

    If they are operating off the same incoming voltage as the Mitisubishi plant, then I expect the incoming supply to not be a problem.


    D4x are Eurpoean Spec and D3x are North American Spec (operates off a higher voltage) so discounting that as the problem, it may well be in a decommissioned condition.


    From an automotive plant, it is very possible they had X9 configured for 'remote power on' which would have had the power on/off signal for the controllers controlled from a PLC.


    So 1KP connector X9 would be my initial check point.

    Check and confirm pins 1 and 2 are empty and pins 3 and 4 are linked.


    If the above is set, then the AVR should power up (pins 3 and 4 on 1KP are the enable AVR circuit).

    The controller should boot up and all the respective led indicators and voltages should be available to see/measure.


    If at that point no leds/voltages are available and the controller is not booting up, then it would either be:

    - Faulty RY1 or/and RY2 relay on 1KP.

    - Faulty AVR.

    - Short circuit somewhere causing AVR to shut down.

    Welcome to the forum.............:beerchug:

    Should be using a D3x spec instead of a D4x spec controller IMHO as they operate at higher incoming supplies, so I don't know if this is a factor with your dead controller.




    First thing is make sure ALL internal MCB/Trips/Fuses are good.


    Check 1KP board X9 configuration is set correctly for power up requirements:

    - Local power up X9 pins 1 and 2 empty, 3 and 4 linked (default setting).

    - Remote power up X9 pins 1 (24v input), 2 (0v input), pins 3 and 4 empty.


    The next thing would be to check aux voltages are being supplied to control logic 1KA/1RA and 1KP by using DVM to measure AVR aux supplies:



    Without the above operational and known working components, the controller will not show life.


    If this resolves it, you may also need to address correctly the other 1KP connections X7 and X8 for External Estop and Safety Fence and External Trigger connections.

    Below is the default configuration usually supplied directly from Kawasaki so that OOBE can be used straight away:




    Let us know how you get on.

    Under normal circumstances in teach mode when you have set:

    - hold run switch to run

    - motor power light is on

    - press deadmans

    - K1 and K2 energise followed by K3 approx 0.5s later.


    You need to check ALL safety circuits as explained.

    As this is ex jag, I would definitely check the UX arm limit switches and 1FG board to make sure all correct.

    Also make note of 1HY board relay led indicators and reference manual for status of these.

    Check 1HP board and fitted fuses.

    Do not assume that all E stops are working, teach/repeat switch is working - always measure.

    Do not assume cables are all correct, could be break somewhere - always check.

    This type of fault (as you can see from following circuits) could take time to locate, if you have spare boards then easy to confirm by swapping them.





    One of the errors maybe the result of the other error.


    1334 relates to brake release signal from AS software from 1HA to 1HP board to 1GB.

    You can confirm manual brake release function by using buttons inside Controller.

    *** Use brace or hoist to prevent major joints from collapsing***

    This will confirm brake operation is working from 1GB board.


    1337 relates to either of the dual channel safety circuits in mismatch condition.

    Kawasaki safety circuit is outlined in alarm circuitry in manual to troubleshoot and is very substantial.

    External Safety inputs to TB2.

    Emergency Stop buttons on TP and Controller.

    TP Cable.

    Teach/Repeat Switch on Controller.

    Limit switches on Robot Arm (which often are overlooked).

    1HP Board.

    1HY Board.

    1GB Board.

    Harnessing between 1HP and 1GB.


    Robot motion is achieved in simple terms of:

    K1 and K2 Contactors energising (one then the other)

    K3 Contactor then energises.


    Have you checked obvious supply voltages and internal MCB trip condition - clean out and cycle these.

    Can you achieve motor power (orange light on and stable)?

    Do any contactors try and energise in repeat or teach modes?

    Do you have small relay located on left side of TB2 Terminal Strip?

    As this is a safety device, I am not responsible for the implementation of this item and always will insist on you undertaking official training and any advice I offer is based on this training.


    In your application example folder referencing 'Description Table', this has been taken from the Safety Inputs section (11-29, 11-33) and states in the explanation what occurs when it is OFF or ON.


    Safety circuits should be fail safe and when working (confirmed by sending test pulses around the circuits to ensure integrity), then they are considered 'safe and working'.

    Therefore, safety inputs operate off the same convention, if on, all working so allow things to happen.

    So in most cases, the allocated input when turned off, activates the monitoring function allocated to it.


    Exactly what you have described with your OSSD's.


    This is why I have mentioned to use the rungs monitoring and you will easily see these in action.

    if some can die from milling foam with a robot...

    then people shouldn't be using angle grinders, cuss their boss will go to jail.

    Absolutely it could happen and a whole host of other injuries to limbs, eyes, ingesting caused by flying debris, damaged tooling.

    Containing the working environment and protection against man/machine falls under your regions regulations.

    Which you should adhere to, as in the event of an accident and seriousness of injury caused, could result in some form of investigation (again region dependent).

    Irrespective of whom installs, supplies and uses it, should an event occur, you are ALL responsible.


    Additional to this, you could be responsible for causing injury or worse to yourself/colleague/friend/family member and have to live with the guilt of short cutting regulations that could have prevented the event in the first place.


    Irrespective of application, these regulations should be applied, they are there for a reason.


    Totally agree with SkyeFire statements and quite frankly sent shivers down my spine and I hope your write up gives them the kick up the ass they need as that is a ticking time bomb.


    This is the point that is trying to be made, but your choice of words has been read as a total ignorance and naivety - which you may not of intended.


    Remember this is a public forum sharing advice and resolutions and at the forefront of EVERYONES mind is safety and going home to the family safe and sound at the end of the day is paramount.

    As far as the use of base and tool coordinates (or lack there off) and the AS Programing exclusivity, that was how the equipment was originally designed and sold by the integrator.

    I did not want to come out and say this as it steers away from your topic, but this is kind of my point.


    Kawasaki Systems certainly allow them to be very bespoke indeed, and as an end user, should problems occur, then the supporting OEM documentation or training you have received may not support your cells and you are totally reliant on the integrator should you experience errors, faults or strange occurrences.


    To be clear, I am not making any kind of statement towards your integrator in saying what they have delivered and setup is wrong.


    The point I am making is that where possible, always follow fundamentals as the OEM documentation will be relative to them.

    If these fundamentals are not followed, there must be a reason why.


    For instance, an integrator may re-zero JT4 (on a 6 axis robot) 180 degrees from mechanical zero to accommodate a service pack/harness installed.

    As an end user, unless you are aware of this and you needed to re-zero JT4 (ie motor failure/change), then it is very likely you will use OEM procedures and the result could tear the harness afterwards.


    If you come across a cell that doesn't follow fundamentals, then be aware/in agreement of them before hand between integrator and client and have it documented/pencilled into any in house training you are likely to offer so you can fully support it.


    Yes, Lemster68 has also suggested payload.....:top:

    Kawasaki uses AS Weight command or Tool coordinate aux function to apply payload, COG and moment of inertia values that will certainly allow for a more optimized system.

    Interesting topic and something I could spend hours on for sure based on my experience with end users and integrators.


    But to some things up generally:

    - Fundamental product knowledge is key - even if you are an operator.

    - How this fundamental knowledge is then applied.

    - Anything programmed can be changed unless access is prevented.

    - Just because it works, does not mean the pixies are not queuing up waiting for some fun.


    I completely concur with ShAdOwDrAgOnS

    Base and Tool go hand in hand as they are the 2 fundamental coordinate systems used.


    Whether you use BLOCK or AS, Base and Tool are fundamental to the robot and intended application.

    They need to be considered for ANY intended application and applied accordingly.


    Fundamental to ANY Robot is:

    - Correct zeroing.

    - Correct working envelope parameters (hard stops, limit switches and joint limits).

    - Correct EOAT values (Tool)

    - Correct internal working areas of the envelope (Base).


    Not setting these or applying them incorrectly is going to lead to a charity event for the pixies.


    You now have the added bonus of Cubic S to 'Police' the settings and stop the robot in the event of 'external influences', but Cubic S can only police the fundamental settings, if these are incorrect, the policing of them will also be incorrect.


    All OEM's provide training for their products, anyone dealing with robots should at least attend some fundamental product training.

    In house training often circumvents fundamentals for application training.

    Glad I could assist in some way and you've managed to resolve it.........:top:


    The thing is the issue only occurs around one weld, so you run the risk if changing gun settings, introducing problems in areas which are currently working.

    INTERP/SPEED and POSITION are the only real things you can freely change/test for.


    Kawasaki has some complex functions built in for Servo Gun operations, that not everyone uses and when you don't use them, sometimes you can find issues which are not obvious.

    Never tried it to be honest as I don't deal with Paint Systems.

    I do know there are issues within KROSET and spin axis moves and I'm not sure if they are resolved.

    - I think spin axis commands operate, but do not produce motion.


    Have you tried looking at the Paint Servo Package Manual and creating the project, maybe this would work and give you some further ideas, as I'm not 100% sure they use spin axis.

    The manual should be located in your documents folder in the Kawasaki\K-Roset\Hisui\Documents folder.

    So you are:

    - Rezeroing the robot after battery exhaustion.

    - Referring to UWRIST and DWRIST and there is no evidence of this in your program.

    - No idea how to make a backup.

    - Applying modifications without making any sort of backups.


    I am scared indeed.............:gaah:

    1. teaching the robot is done by using HERE command, when i teach HOME its not Responding fo r that new Home.

    This is not how you teach the HOME or HOME2 positions.

    You should read the Operations Manual (Aux functions) and the AS Manual for the correct command.


    Now I am very scared...........:away:


    I suggest you:

    - Contact Kawasaki for a training course.

    - Contact your integrator or Kawasaki to assist in resolving your problems.