stop by $CORRECTION function ( reset or block selection required )

    Morning forum,


    Cell configuration:


    KR10 R1100 Agilus-2's (x2)

    KSS 8.6.6

    KRC4 compact

    Airskin


    KOP files:


    RoboTeam

    ForceTorque control

    RSI

    GripperTech

    Master/Master Topology

    FSOE


    Query / Issue:


    The cell in essence shares a workpiece via GEOLink within RoboTeam and "picks to places" an engine component. If at any stage a safety protocol is interrupted ( E-Stop / Floor scanner / Airskin ) then the cell Stops, waits for a RESET then resumes. ( Great )......However......if activating a Superposed ForceTorque Task to Velocity control a programmed path motion ( on detection of a load set the $OV_PRO = 0 via the task parameters ) , if a safety protocol is once again interrupted, we can of course RESET the safety, but the KCP displays the following message:


    Stop by $CORRECTION function ( reset or block selection required)


    I have via reading the RSI manual v4.1 come to conclusion this is to do with RSI and a bi-product to using the TASK within the TorceTorque package.


    I have since spoken to KRUK and they advise on reducing external correction inputs next time......( I'm still exchanging emails to progress this meaning)


    I recall seeing on the forum some time ago about a means to utilising the IR_STOPM to cancel this inhibitor message / condition and to allow for a controlled restart.?.


    Ultimately, having to go into T1 and Reset the .SRC while load sharing a workpiece is a trap door within itself for recovery that I just can't seem to feel is Kuka's only way around this scenario or set up.


    Anyone with any ideas would greatly be appreciated.


    Mike

    • AD

    It's been a looong time, and I only worked on the edges of this issue, but from what I recall, we used the built-in timeout setting of the FTC program, and used IR_STOPM to change the timeout value to something very small. This, IIRC, caused the FTC program to terminate "properly" and got us past the restart problem. Of course, we also had to set flags to ensure that, when the robot was resumed, that it did a clean "pull away" move to a safe distance before resuming the program.


    Hm... found an old backup that I think is good. Looks like we did it in the restart section of IR_STOPM, not the stopping section:


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now