Posts by kwakisaki

    I'm from the UK so do know many, but what you mentioned above are probably the bigger authorised system integrators I've 'heard of'.

    Most authorized integrators, usually have very good connections with the 'mothership' so spares, technical advice and support is usually very good.

    An emergency stop is a condition as opposed to any function the controller provides, but you can monitor for that condition and provide an action to it.

    There is also a dedicated output called under emergency stop located in Aux 0602 one of the last pages can be used, if you wish to use that.

    In the SYSTEM SWITCH area, you can monitor for:

    - Teach pendant emergency stop button status

    - Operation panel emergency stop button status

    - External emergency stop button(s) status

    - Controller emergency stop condition (which is looking for the OR of the above).

    To monitor for a SYSTEM SWITCH status you can effectively use any iteration.

    A basic example to toggle an output based on the emergency stop condition:

    IF (SWITCH(EMERGENCY)==TRUE) THEN ; Emergency stop condition is active

    SIGNAL 20


    SIGNAL -20


    You also have the individual emergency stop conditions you could monitor for in the same way if you wish to itemize them:

    IF (SWITCH(TP_EMG==TRUE) THEN ; Teach Pendant emergency stop condition is active

    SIGNAL 21


    SIGNAL -21


    IF (SWITCH(OP_EMG)==TRUE) THEN ; Operation panel emergency stop condition is active

    SIGNAL 22


    SIGNAL -22


    IF (SWITCH(EX_EMG)==TRUE) THEN ; External emergency stop condition is active

    SIGNAL 23


    SIGNAL -23


    A blanket cancellation of ALL general purpose outputs could be simply:

    IF (SWITCH(EMERGENCY)==TRUE) THEN ; Emergency stop condition is active



    Kawasaki is a retentive system.

    You turn on something, it remains on until turned off, so latching is automatically carried out until otherwise programmed.

    Dedicated signals are controlled by the system and therefore cannot be manually controlled.

    Pushing the button is activating the dedicated signal, that is it's dedicated purpose for manual control/testing of the GAS ON.

    So in answer to your question, unfortunately no.

    You're using and butchering my code....I don't usually publicise 'debugged' code, just you run risks if you don't completely understand it.

    Just be aware, as I hold no liability if it's used and there are problems.

    I was actually referring to the 'old plasma cutting code', this would give you an indication of how it was configured before and possibly provide you with examples of how the code was operating.

    So it looks like you are (forgive the words)...'band aiding the code' together to try and get your results.

    Unless you are utilizing all the weld signals that get interfaced between the arc welding software and weld power source, I repeat you will run into issues with the lack of signals the Kawasaki requires in order to utilize the AS Arc weld commands (like you're using) and will have to 'code' around it.

    I would personally ditch the 1GN, use the 1TW with a couple of relays and replace your code with standard AS and weld on/off signals.

    These signals do not need to be dedicated, you can setup general purpose ones instead.

    This eliminates any 'weld related errors' interrupting the process as you will just be using standard AS commands.

    For example below will not produce any arc weld related errors.

    - just requires an output from 1TW to input via relay to weld source

    - Just requires an output from weld source to input via relay to 1TW board.

    You could then incorporate 'trap' areas and user timers around the 'WAIT' that if a set time has elapsed without the signal being received, then to stop the process, recover or do whatever.

    You could go further and code in an interrupt that monitors for the loss of the 'current flowing' signal during the actual weld and dive into a different 'trap' area to cease the weld and cancel signals etc.

    Again, the above is just an example........

    It's a very good question, I can't recall ever being in a situation to confirm that.......:hmmm:

    If one of my clients asked me to 'try anything in a breakdown situation', I would definitely highlight specific risks and liability before trying.

    With the lack of spares now, it would kind of force you into a position where you would certainly try.

    Without accepting any liability::away:

    - If the part number is the same and it is mounting in the same slot and has the same connectors and layout then in my opinion yes.

    - Making sure dip switch and jumper settings are the same.

    - Watch out between servo firmware and system firmware incompatibilities, this maybe a factor.

    I suppose if you have the luxury of a couple of 'spares', some time and 'freedom' and a good 'pucker factor' to try, the most obvious test would be:

    - AVR/AVR1

    - 1BP Board

    - Power Blocks

    If you look at the block diagrams in the manual, they reference 1AE/1GE and the rest of the boards appear to be common.

    Kawasaki do produce 'vendor' specific systems and therefore you could introduce problems of incompatibility and failures based on this.

    Again, the above is just my opinion and the risk of trying would rest on you.:yessir:

    Attached are a couple of manuals (not sure if you have them).

    Main Installation for a dedicated arc welding robot including 1GN pinouts.

    External IO - Useful for looking at the signal timing charts.

    AS Arc Welding Manual - Reference AS Commands.

    If it was used with a plasma cutter, interfacing would have been fairly straight forward I would assume and probably didn't use the 1GN board, just 1TW.

    The old code used with that would give an indication of how it was interfaced probably.

    Can you post any of the previous code without compromising on company ip?

    With the issues I mentioned, to put into context:

    - When moving around a radius, as you will be 'linearly moving' the tip speed will change, you will end up with too much or too little wire for the weld pool.

    - Resulting in a very bad join, possible too little penetration or too much.

    - You would need to set different speeds for any radius specifically to match the wire feed rate, could be a headache, but with some tickling, made to work.

    - If the wire sticks or a problem at the weld power source, the controller is still outputting the 'torch trigger' and will continue to be on until told to turn off.

    - With your configuration, there is no mechanism in place to detect this, so the robot will continue moving through the program.

    - Likewise if the robot went into error, as long as the output was controlled and turned off to the weld power source, wire will stop being fed.

    - Otherwise the robot will stop, the wire is still being fed and possibly the weld power source is still providing current (but I think you have that covered).

    - At the end of the weld, the robot will want to move clear before disabling the wire feed, dragging the wire (as it's probably stuck to the weld pool).

    - Could cause some damage to the torch etc.

    - So this would need to be carefully managed in the code.

    Personally (if Ethernet/IP is not an option), if you ditched the 1GN completely and just used the 1TW with relay banks, this would get you closer to a result.

    Then you could map whatever signals you need to the 1TW and any piggy backing could be done simply in code with SIGNAL x,x,x commands.

    This would be the simplest method and keeps all your signals on the 1TW and in total control of them and freedom to synchronize what/where you want.

    Some of the issues above could be eliminated adopting this approach and using standard AS Commands.

    If you do really want to utilize the 1GN though as you've mentioned, you will need to use Arc Welding AS Commands.

    The WCR detection time can be delayed by use of WCR_ON_DTIME Command, which will give you up to 60s to feed the input before arc failure error.

    So there is some breathing room there too....that command is listed in the Arc Weld AS Manual attached.

    Difficult one to call with your setup though.

    As a test, you could do what you mentioned and see how you will either work or end up rolling doughnuts.

    Ah right, so you're Robot Model is not a dedicated Arc Weld Robot then RA or BA are usually this.

    Sounds like someone has put Arc Weld Firmware on it then.

    Never come across RS15X as Arc Weld before, only as Sealing or Handling.

    I maybe wrong, but I doubt the installation manual will have the information for the 1GN board then.

    As I haven't done TIG with the Kawasaki, what is 'jumping off the page' in my eyes is the following:

    - How will the the controller or power source know if either device is in an error state, or able to handshake between each other for status exchange.

    - How will the weld power source be able to adjust the wire feed rate with the torch tip speed of the around a radius.

    - How will the weld power source be able to detect the 'end of weld' so the robot will command a slow down sequence.

    Kawasaki Arc Weld Systems have all these features available to handshake with the weld power source as standard.

    Do you know if the weld power source has Ethernet/IP fieldbus protocol available to it.

    If it does, this will solve many problems as all you would need is the peripheral for your weld power source.

    Kawasaki will have Ethernet/IP available as a software option already in your robot.

    Then interfacing will just be an ethernet cable between the controller and weld power source, and just a case of IO allocation then.

    This would be my recommendation if the weld power source has this option (if I'm honest, I would be very surprised if it hasn't especially it its recent).

    I knew you'd say TIG Welding, I haven't done any TIG on a Kawasaki, but I do know there are options available...............:wallbash:

    I shall see if I can locate some further information on it and post back if I find any.

    What Robot are you using (Model) and have you got the installation manual for it?

    - That shows all the 1GN pinouts and functions.

    1TW boards are for digital signals only and are based on a supply voltage of 24VDC +/-10%.

    Per Input current is 10mA and Per Output max load is 100mA based on the external supply, so I don't think 9V will cut it.

    I don't think there is anyway around it but to use relay banks in between.

    I've never used 1TW for the signals before, so I cannot say, but as far as 'mapping' signals to the 1TW is concerned, you would just need to allocate the dedicated signal to the relevant signal on the 1TW

    What kind of welding are you doing exactly?

    If you have a 1GN board fitted, I suspect you have a dedicated arc welding system and may run into problems using the Arc Weld BLOCK or AS commands.

    When using arc weld commands, they automatically invoke the use of the arc weld dedicated signals without the need to code them in.

    Therefore, arc failure will be produced because the input is not received from the weld power source output indicating current flow.

    - This is the WCR input.

    So if you are not interfacing controller to the weld power source, then you will not be able to use Arc Weld BLOCK or Arc Weld AS instructions.

    You would need to set things up just using standard BLOCK (which you don't have on an Arc Weld System) or standard AS which you could use.

    If ALL of your parameters are being set in the weld power source, and ALL you are doing is turning weld on and weld off, then you will have to use standard IO signals and un-dedicate the dedicated signals.

    Seems like a real waste of resource if you already have a dedicated Arc Weld System already, just interface the weld power source with a bank of relays into the 1GN and you'll be golden.

    Can't understand why you don't go down this route, it will make programming a lot easier.

    p.s scratching again looks for io interface exchange between controller and weld power source - WCR input to tell it the controller current is flowing.

    Sounds like JT3 and JT6 are outside of their software limits......which indicates encoder data loss and it's possible other joints maybe affected to.

    So you will have to re-zero the joints after you've replaced the battery.

    Each joint has mechanical and software limits.

    Software limits are user adjustable between the max/min ranges of the specification of the robot used - Located in Aux 0507.

    If there is any zeroing data loss, it is probable that the encoder values will be different than to what it was calibrated before, therefore these 'new' values will be used to calculate joint angles and probably exceed either the minimum or maximum software limits.

    This only allows the particular joint(s) affected to be moved in one direction to bring it back into the software limit.

    - If joint angle displayed is 1000 deg, you will only be able to jog it in negative direction.

    - If joint angle displayed is -1000 deg, you will only be able to jog it in positive direction.

    So in order to jog your joint(s) in either direction, just carry out ONLY an Encoder Rotation Counter Reset to 0 degrees.

    This should allow you to drive them to the respective scribe lines.

    Then you could replace the battery and then zero the joints.

    The main procedure for re-zeroing should always be carried out in the correct order:

    1. Encoder Rotation Count Reset - Aux 050103 or ZZERO 10x command where x is the joint no.

    2. Zeroing of the axis - Aux 050101 or ZZERO x command where x is the joint no.

    A common mistake is to do one procedure and not the other, both procedures are always recommended.

    Glad you've resolved it..........:top:

    Be good to know which one it was.....

    X313 jumper on the MC Unit is mentioned in the troubleshooting reference I posted as a possible cause.....if you pull that off, this would confirm it.


    Sounds like a Kawasaki, the recent controllers house 1TW IO Boards......So I'll move it there.....


    1TR board has a couple of 'Dry contacts', also known as 'Potential or Voltage free contacts' which are dedicated for system use only and cannot be 'mapped' for alternative uses.

    You could purchase a 1GN board which piggy backs to the 1TW board (usually supplied as standard with an Arc Welding Robot), but I believe you would also need the relative Arc Software just to 'talk' to the 1GN board.

    Therefore, your only solution(s) (in my opinion) would be a couple of relays if you are going to control them from the 1TW.

    Alternatively, you can utilize the extended IO (if fitted to the Arm ID board) located in the manipulator arm.

    However, again you would need to add a couple of relays as the extended IO is also designed for digital IO control.

    This is in fact what you should do when you are not using the Kawasaki IO to switch digital signals.

    Kawasaki do not supply spot weld timer units as far as I'm aware.

    You would need to consult with the supplier for their respective details.

    As mentioned, communication between peripherals is nominally via exchange of IO between controller and weld timer.

    - The weld gun is controlled by the controller in terms of clamp numbers, clamp conditions for the opening and closing of the gun.

    - Weld timer requests (Weld schedules, Weld timer status).

    These IO signals are realized via either:

    - Standard IO exchange interfaced between controller IO board (1GW/1HW/1TW) boards and Weld Timer Interface.

    - Fieldbus IO exchange interfaced between controller and selected Fieldbus Protocol Interface and Weld Timer Fieldbus Protocol Interface.

    Back in the day, in the UK, Jaguar Spec Controllers were fitted with Interbus Fieldbus Protocol cards for Weld Timer communication lines.

    - Fieldbus IO modules in the field communicated to the controller (physical work clamps and part detection).

    - Controller was directly connected to the Weld Timer for fieldbus IO exchange for the start/stop of weld request..

    - Weld schedule sent a value to the Weld Timer, the Weld Timer then had preset current/voltage and weld parameters set for the weld characteristics.

    Attached image is from the standard operations manual.

    What are you looking for exactly?

    Standard Welding can be classed in either Spot (resistance) or Arc welding.

    Standard manuals provide information on Spot Welding and Arc Weld manuals provide information for Arc Welding.

    External IO manuals provide information on specific IO allocation.

    Fieldbus manuals provide information for setup and configurations relative to the protocol selected.

    Weld controllers will have their own setup and configuration manuals.

    I am not a huge fan on zeroing with Kawasaki robots regarding accuracy when using scribe lines as some models have scribe lines that can 'move'.

    In most cases though, they are sufficient enough to adequately zero the joints especially on larger manipulators.

    So I can appreciate people adopt various techniques in order to improve on this.

    Overall, though I do think some improvements can be made by Kawasaki to further improve zeroing accuracy on their robots.

    From what I can recall (someone correct me if I am wrong):

    - Each encoder has a backup capacitor fitted which can hold enough charge to power the encoder for up to 30mins upon electrical disconnection.

    - The encoder provides values which the controller can only read.

    - You cannot replace the data on the encoder itself by using any method I'm aware of (ie from a backup).

    - When zeroing, these values are used to reference the encoder rotation counter and the zeroing of the at it's current location (joint angle) that you specify.

    - Nominally, this is why you use scribe lines (these are the mechanical zero degree marks for the respective joint) or zeroing jigs/inclinometers etc.

    - You can also re-zero using a degree value of your choosing if you already know the degree value the joint is currently at.

    If power is not lost to an encoder, but during a controller off state, the encoder physically moves (ie the joint moves) then it is still tracked.

    - Hence the 'joint abnormality error', which can be reset and the data from the encoder is still referenced correctly as it is still being tracked.

    - Then a backup can be used to restore incorrect zeroing values if entered incorrectly.

    If power is not lost to an encoder, then as long as the encoder has not been replaced or been misread, the encoder values will be the same.

    - Then a backup can be used to restore incorrect zeroing values if entered incorrectly.

    However, If power is lost to an encoder or is replaced, the values produced from the encoder and read by the controller will be different.

    - Therefore the data in a backup cannot be used as you cannot rewrite the values in the encoder with old ones.

    - The backup data will replace the old backup data (which is the same) BUT the new encoder read values are actually different.

    - You then effectively re-zero the controller using the backup data values as the reference to the new encoder values = incorrect zeroing.

    So if power has not been lost to the encoder, or the encoder has NEVER been replaced since manufacture or since the previous backup made:

    - A controller could be re-initialized (emptying of data) and a backup used to restore it

    - A backup could be used to re-zero if for some reason you were re-zeroing and entered the values incorrectly.

    - The original supplied data sheet encoder values and offsets could be typed in Aux 050102.

    - BUT as soon as power is lost in encoder, or it has been replaced, the backup data becomes redundant.

    So the key is to identify the correct situation before applying a method.....I call this my OBA's

    The main procedure for re-zeroing should always be carried out in the correct order:

    1. Encoder Rotation Count Reset - Aux 050103 or ZZERO 10x command where x is the joint no.

    2. Zeroing of the axis - Aux 050101 or ZZERO x command where x is the joint no.

    A common mistake is to do one procedure and not the other, both procedures are always recommended.

    In your instance though if you think JT1 and JT3 are the only problems:

    1. Check to a known joint angle position within the program - JT2/JT4/JT5/JT6 will be correct (assuming JT1 and JT3 are only affected).

    2. The location data stored (angle degrees) for that position will include JT1 and JT3 values.

    3. Physically move JT1 and JT3 to the correct position visually.

    4. Re-zero JT1 and JT3 using ZZERO commands and type in the values from the stored location (joint angles) for JT1 and JT3.

    5. Then drive to 0 degrees and see just how far you were out.

    6. Check back to the known position and check other positions......they should be corrected....unless other joints are also affected.

    Alternatively, using a similar method:

    1. Check to a known joint angle position within the program - JT2/JT4/JT5/JT6 will be correct (assuming JT1 and JT3 are only affected).

    2. Take a note of the joint angles for JT1 and JT3.

    3. Physically move JT1 and JT3 to the correct position visually - If you cannot achieve the position, then other joint(s) may also be affected.

    4. If you can achieve the position, take a note of the joint angles for JT1 and JT3.

    5. The difference between before and after values are the values you would need to advance/retard at your scribe line position.

    6. Move JT1 and JT3 to 0 degrees then advance/retard the position by the difference you obtained earlier and re-zero there.

    7. Check back to the known position and check other positions......they should be corrected....unless other joints are also affected.

    Irrespective, it will probably take some time to 'tickle' your zeroing so that you won't have to 'tickle' your taught locations.