ABB Multimove freezing

    Hello guys,

    I would like to ask for advice about problem in ABB Multimove freezing.

    I have 2xABB IRC5 1200 Master/Slave

    Problem is happening only sometimes so:

    - Operator is entering the station with robots, which is done by TRAP routine at robot side (After robot allows enterance, PLC will shut down task and motors)

    - After leaving the station, operator press reset button and restart robots tasks (MotorsOn - Start), mostly it works

    - Sometimes however, after robot gain Start from PLC, only one task start its movement with PP. (more in pictures below) ROB1 is stucked without a PP according FlexPendant (but in RS i saw he is waiting at the begining of SystemStart routine. ROB2 is already OK and just waiting until ROB1 reach its destination. Main problem i think is, that FlexPendant has a message "Remote Write Access in Auto" which means the PLC is sending something but it is not (in this point we are stucked)

    - Both robots has a short Event Routines (Start & Stop, visible on the picture below) which is only for reset enterance to station & deactivation of CSS (because of manual mode)

    - I created a messages to log, so i saw before this frozen state that: ROB2 was finishing his Event-Start without problem, but ROB1 didnt even start it.


    - From PLC there is no robot system input active at this point

    - Also System Inputs are not overrided (checked with trace & watched in PLC as SystemInputBusy)


    - Quick solution is use StartAtMain (which stops the task and reset both program pointers, but its not what we want to do every time operator enter stations.)


    https://photos.app.goo.gl/f8bj2wNg3DPwKfYe6


    I will be grateful for any advices or tips. Thanks.

    Can you send the a backup of the robot code? The "Remote Write Access in Auto" means robot studio is connected or another client is connected to the robot controller.


    There is also a chance the run chain does not recover from the trap correctly. Lost PP's are a real issue for ABB to start with.


    Matt

    Thank you for answer Matt,

    First of all I already sent this as an issue to my contact in ABB, so maybe they will give me more informations.

    Also Im 100% sure there was not connected remote RS because i was the only one at the site in this time and also I am only one who can access it.


    I can paste here part of code for TRAP and Event which i think causing trouble:


    TRAP Enter

    ISleep intR1Enter;

    StopMove;

    StorePath;!---Save last position of PP

    WaitRob\ZeroSpeed;

    Set Do_R1_EntranceEnabled;

    WaitTime 1;!---Delay before PLC Stop Tasks

    WaitDI Di_R1_EntranceRequest,0;

    Reset Do_R1_EntranceEnabled;

    RestoPath;!---Load last position of PP

    StartMove;

    IWatch intR1Enter;

    UNDO

    Reset Do_R1_EntranceEnabled;

    RestoPath;!---Load last position of PP

    StartMove;

    IWatch intR1Enter;

    ENDTRAP


    PROC SystemStop()

    !---Robot after TASK STOP

    ISleep intR1Enter;

    ISleep intHMIspeed;

    SetDO Do_13_InitComplete,0;

    SetDO Do_R1_EntranceEnabled,1;

    Report\WARN,"Stop State Active",["","",""];!---Info to log

    ENDPROC


    PROC SystemStart()

    !---Robot after TASK START

    CSSDeact;

    SetDO Do_R1_EntranceEnabled,0;

    Report\WARN,"Start State Active",["","",""];!---Info to log

    ENDPROC


    All of them are same for both robots, different only in I/O (R1/R2)

    Event routines are set like this:

    I seems like I have seen the remote write access notification on the pendent before even though the laptop was disconnected. I would check this though. This would mean a client other than the pendent is accessing the controller.


    In one of your screenshots I see that you used WaitSyncTask\Inpos but in your trap your restoring a position in the case the robot moves or drifts, I assume. Could this cause a conflict somehow especially since you restore the path before the StartMove?


    In a multimove instance using StopMove or just Stop, you want to add the \AllMoveTasks argument to stop all the motion tasks. Otherwise the other tasks will continue to run until a WaitSyncTask is reached.


    I see your Event Routines. Are you sure a StopMove and StartMove will trigger the associated events? If so I see you would also be executing the ISleep intR1Enter; twice. I guess the PLC system signals would trigger the event routines but why not use the MotOnStart system signal from the PLC versus all the Trap code?


    Overall it seems like there is a simpler way to do this and in all the examples I have see, there usually is unless there is some special operation that is in play?


    Matt

    1, Yes, that is the problem i dont know how to find (Im sure that PLC is taking write access when sending System IO, so that could be it, but i dont understand why its stucked)

    2, At the screenshot is shown Autohoming routine (used in Initialization) and robot R2 is curently in home position and waiting at instruction WaitUntil R1=In Home (So not waiting at WaitSyncTask, its one instruction below)

    - Robots always starts and end in home position and dont have enough space, so WaitSyncTask is necessary but before it they always wait for signal Do_HomePos from second robot

    3, StopMove\AllMoveTasks cannot be used, because one of the robot could reach position to enable enterance, but second one not (and there he would be stoped in random position which could be unrecoverable here)

    4, Isleep is used twice for: (1, when trap routines continue after stop with start normaly. 2, when trap routine is canceled via UNDO handler by StartAtMain). MotorsOnStart cannot be used because of machine safety around robots (We need to trigger MotorsOnState at first and then after singal check separately Start) Most of the time Event routines works fine (i have Warning message to log every time they were executed) but here is the point when one of the robot became stucked at the begining of SystemStart event routine with "remote write access" notification


    Program is a bit complicated because of using standard structure for whole machine (overall 5xABB) and we need to solve every error/problem in automatic mode so there should not be necessary for operator to switch robot manualy (exclude collision, all of the problems could be solved by Initialization)

Advertising from our partners