Touch sensing in Arc weld robot

    I’m new to arc weld application


    In arc weld application we want to use touch sensing function.


    I enabled the same & tried.


    When I’m programming work detect is not happening.


    Request to suggest on Work detect function.


    thanks in advance :smiling_face:

    Maybe tell us more instead of keeping things dark:

    - What Welder is being used.

    - How is the IO configured between it.

    - Are you using BLOCK or AS Weld Programming.

    - What exactly have you tried already, for instance a snippet of your code would help.

    We're getting there.....


    - What soft signals, profibus, profinet, ethernet ip.

    - What are the signal allocation for Fronius controls a datasheet would help showing soft signal functions.

    - What are the signal allocation you have set Kawasaki with.

    - Where is your code and your inclusion of sending the signal to the Fronius to enable touch sense.

    Without any information, it is hard to say why things do not work.


    The only suggestions I can make at this point is:

    - Does Kawasaki and Fronius exchange signals ok and working.

    - Check Kawasaki IO signal allocation and dedicated signals for actual touch sense output.

    - Make sure dedicated signals are correctly allocated to communicate with Fronius.

    - Check Section 9.0 in Operations manual for Touch Sensing setup and usage.

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


    BLOCK programming is a set structure of commands created using parameters the programmer selects, which includes joint angles (positional data) unless NOP is used.


    You move the robot to a position, set the relative parameters and record them.

    There is no hard coding involved as the teach pendant produces the structure.

    This information is available in the operations manual provided by Kawasaki with your robot.

    - Includes touch sensing and work positioning.


    Attached is a video of basic touch sensing and work position checking from KRoset showing some of the BLOCK programming structure.

    I would like to know if there is any instruction that can skip an error of Touch sensing in BLOCK programming, I tried to use ONI but is not working, I want to implement a recovery after a wire check failure or work detect failure. I think I need something similar as SXAC: ignores workpiece non-detection errors in touch sensing.

    Why are you wanting to recover from a robot error stoppage automatically............ :hmmm:


    The errors are there to stop the robot and highlight to the operator/maintenance there is an issue that requires attention and the robot stops in the area where the error occurs providing vital evidence to allow easier restarting decision making.


    These errors maybe due to the robot itself or indeed the weld power source.

    So by leaving the robot in the current state and position, allows for easier troubleshooting for the operator or maintenance to then deal with:

    - Manually move the robot back to a known restart position, clear the scene and restart.

    - See if the problem can be resolved in situ and just carry on from there or go back a couple of steps.

    - Restart the main program (where a check program is executed and auto recover prior to restarting).


    I can never quite understand users wanting to implement a 'hit and run' scenario when it comes to dealing with errors and the 'police' show up at the scene with zero evidence of a problem...... :icon_confused:


    However, the above is just my opinion and in some cases of robot stoppage, then yes indeed some kind of automatic recovery maybe implemented and Kawasaki has some tools just for this.


    Check out the following (but you are limited by their functionality):

    - ONE

    - RETURNE

    - ERRSTART.PC (if using a PC TASK to manage errors).


    You can of course create your own PC Task to monitor for specific error events and invoke an automatic recovery procedure to manage errors and initiate robot recovery conditions.


    Some errors remove motor power, some errors retain motor power.

    Therefore certain errors will require treating differently in order to programmatically:

    - Acknowledge/Reset the error.

    - Determine from the error whether you can recover from it without causing further damage.

    - Cancelling/Setting of IO required to recover.

    - Setting the correct conditions to restart (call a different program, prime a different program etc).

    - Setting the correct motor power and cycle start conditions and moving.

    Thank you for your advice, I forgot to mention I tried to use the ONE and RETURNE but it did not work, I am not sure if I need to enable a special system switch or something else to be able to work.


    Also the current recovery is like you mentioned the operator has to move the robot to known position after he reviewed root cause of the fail, but at this point the operators need a faster recovery to be able to retry or bypass in auto mode.

    Quote from Sergio Falcon

    I tried to use the ONE and RETURNE but it did not work

    Just saying you tried to use it with no supporting code reference tells us nothing.

    No special requirements/setting as needed as it is a standard program instruction as per the manual.

    Provide the code you tried it with and may be we can point out where it is wrong.


    Quote from Sergio Falcon

    Also the current recovery is like you mentioned the operator has to move the robot to known position after he reviewed root cause of the fail,

    That makes sense.


    Quote from Sergio Falcon

    but at this point the operators need a faster recovery to be able to retry or bypass in auto mode.

    That makes no sense:

    - Retry what, from where................ :hmmm:

    - Bypass what in auto mode........... :hmmm:

    If touch sensing fails then it can only be a limited number of things to name but a few:

    - Weld power source may not have received the input for touch sense operation.

    - Weld power source may be in error.

    - Wire incorrect length, balled end (high resistance), wire not fed.

    - Tarnished area for touch sensing (high resistance).

    - If you are using touch sensing work for work deviation or path planning then touch sense distance distance may be too large.


    Simple and fastest way is reset error move robot clear (select previous step/approach and GO in teach).

    Check and clean all areas.

    Into repeat, motor power and cycle start to continue again.

    I don't know how you could speed up an already efficient troubleshooting scenario.


    I may be missing something your not highlighting here......I don't know....... ???

    I pasted a piece of the code I used. I am looking to jump to a different line when we have a error at wire check or measure instruction. The numpg is used for ONI or ON to change the status of 2336.


    When the robot fail at measure points, the request is to have an auto recovery in case they want to bypass the entire weld line and weld without any offset, using goto instruction and other conditions we can jump into a different place in the program.


    I tested also those 3 instructions


    ONI 2336 GOTO 100;

    ON 2336 GOTO 100;

    ONE ts_wchk;

    100

    ;

    SIGNAL (-2336)

    ;

    ; APPROCH WIRE CHECK

    AC JOINT SPEED1 ACCU1 TIMER0 OX= WX= #[-13.39, -5.12, -122.03, 17.65, -35.88, -0.63] ;

    ;

    ONE ts_wchk;

    ;

    ; AT WIRE CHECK POSITION (15mm part to contact tip)

    AC JOINT SPEED1 ACCU1 TIMER9 WIRE_CHECK OX= WX= #[-22.66, 13.44, -121.05, -17.35, -8.37, 21.95] ;

    ;


    .PROGRAM ts_wchk()

    TWAIT 2;

    RETURNE

    .END


    This is what I was highlighting above in my earlier post.


    Your ONE cannot work, as the wire check fail error will remove cycle start.

    This then stops execution of the main program, hence it cannot process the ONE program call.


    ANY error that the robot produces the following stops further execution in the main program:

    - Turns off cycle start.

    - Turns off motor power (this always turns off cycle start anyway).


    Does that make sense?


    AFAIK the ONE is designed to be used in a PC Task and not the main program area as it cannot contain any motion instructions.


    So if you decide to persevere with your intention, then you will need to either:


    1. Execute a parallel PC Task to monitor and handle that specific error only at that part of the process.

    - In the form of a simple PCEXE at the point you want to start monitoring in the main program.


    2. Constantly have a dedicated PC Task always running for ALL your error handling.


    Either way you can then have in the PC Task:

    - Grab information such as error code, program, step, position etc.

    - Using MC Prefix to reset the error, prime a different program, turn on motor power, cycle start etc.


    Attached is a small video clip showing a basic wire check prior to a weld called sequentially from pg0.

    First of all a simple execution (free of errors) to complete the weld.


    Then I invoke a wire check failure and you will notice, cycle start comes off ceasing any further execution and stopping the robot.


    I then implement a simple 'squirt' PC Task for the specific purpose of monitoring for the wire check failure around the area it is needed, which resets the error and re-executes pg0 from step 1, thus repeating the process again programmatically.


    I then remove the wire check error and it executes the wire check and weld successfully again.


    This is only a basic example of introducing how a PC Task can be implemented to run parallel to the main program and is by no means any kind of solution as there are better and more efficient ways of managing PC Tasks, but I think you will be able to take something away from the example to further development your application.

Advertising from our partners