Dry contacts

I cannot even move this into the appropriate forum because you failed to tell us what make of robot, controller, etc.,

Lemster68

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

89Seth

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.

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.

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

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

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 robot.....ie around a radius.

- How will the weld power source be able to detect the 'end of weld' process......ie 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).

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 go......it will either work or end up rolling doughnuts.

see attached code. you actually wrote this code. i have just butchered it. the first one you helped us with worked very well. and we were able to machine out the holes. this code is to weld the holes back up.

there is no linear weld movements, its all circumferential.

once the welder is working with the robot, i can control the welder with 4T step signal, this will allow me to set 2 weld settings on the welding machine for the robot to change.

.PROGRAM trialholesweld () ; heat exchanger easy
  SIGNAL -2111, -2112
  GROUP 1
  SPEED 400 MM/s ALWAYS
  ACCURACY 1 ALWAYS
  program = 6
  W1SET 1 = 40,100,100, 0, 0
  pitch = 47.625; Hole Pitch
  POINT .tmp[1] = t2
  POINT .tmp[2] = w1s1
  POINT .tmp[3] = w2s1
  POINT .tmp[4] = w3s1
  POINT .tmp[5] = w4s1
  POINT .tmp[6] = w1s2
  POINT .tmp[7] = w2s2
  POINT .tmp[8] = w3s2
  POINT .tmp[9] = w4s2
  JMOVE SHIFT (.tmp[1] BY 200, 0, 0); Approach hole1
  FOR .tmp.hole = 1 to 11
    lMOVE SHIFT (.tmp[1] BY 100, (pitch * (.tmp.hole - 1)), 0); Approach
    lMOVE SHIFT (.tmp[2] BY 1, (pitch * (.tmp.hole - 1)), 0); start welding
    arc ON
    C1WC SHIFT (.tmp[2] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    c1WC SHIFT (.tmp[3] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    c1WC SHIFT (.tmp[4] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    c2WC SHIFT (.tmp[5] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    LWE SHIFT (.tmp[5] BY 0, (pitch * (.tmp.hole - 1)), 0), ; endweld
    arc OFF
    lMOVE SHIFT (.tmp[1] BY 100, (pitch * (.tmp.hole - 1)), 0); Depart
    lMOVE SHIFT (.tmp[6] BY 1, (pitch * (.tmp.hole - 1)), 0); Approach
    arc ON
    C1WC SHIFT (.tmp[6] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; start weld
    c1WC SHIFT (.tmp[7] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; in
    c1WC SHIFT (.tmp[8] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; in
    c2WC SHIFT (.tmp[9] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; in
    arc OFF
    LWE SHIFT (.tmp[9] BY 0, (pitch * (.tmp.hole - 1)), 0);stopweld
    lMOVE SHIFT (.tmp[1] BY 100, (pitch * (.tmp.hole - 1)), 0); Depart
  END
  swait 1010
  swait -1010

You're using and butchering my code....I don't usually publicise 'debugged' code, just examples......so 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.

    SPEED xxx mm/s ALWAYS ; Transition speed
    ACCURACY 1 ALWAYS ;
    CP OFF ; Allows for PTP motion
;
    LMOVE SHIFT (.tmp[2] BY 1, (pitch * (.tmp.hole - 1)), 0); start weld point
    SIGNAL x ; Turn on Output from 1TW to relay to weld start on power source
    WAIT (SIGNAL(xxxx)==TRUE) ; Wait here for input on 1TW - signal back from weld source to say current is flowing
;
    SPEED xxx mm/s  ; Match this speed to the wire feed speed
    C1MOVE SHIFT (.tmp[2] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    SPEED xxx mm/s  ; Match this speed to the wire feed speed
    C1MOVE SHIFT (.tmp[3] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    SPEED xxx mm/s  ; Match this speed to the wire feed speed
    C1MOVE SHIFT (.tmp[4] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    SPEED xxx mm/s  ; Match this speed to the wire feed speed
    C2MOVE SHIFT (.tmp[5] BY 0, (pitch * (.tmp.hole - 1)), 0), 1; weld
    SPEED xxx mm/s  ; Match this speed to the wire feed speed
    LMOVE SHIFT (.tmp[5] BY 0, (pitch * (.tmp.hole - 1)), 0), ; endweld
    SIGNAL -x ; Turn off Output from 1TW to relay to weld start on power source
    WAIT (SIGNAL(xxxx)==FALSE) ; Wait here for input on 1TW - signal back from weld source to say current is not flowing
;
    lMOVE SHIFT (.tmp[1] BY 100, (pitch * (.tmp.hole - 1)), 0); Depart
;

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........

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.

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

ELSE

SIGNAL -20

END

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

ELSE

SIGNAL -21

END

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

SIGNAL 22

ELSE

SIGNAL -22

END

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

SIGNAL 23

ELSE

SIGNAL -23

END

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

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

RESET

END