$Move_enable switched off when robot is not in use

    Hi, we have (V)KRC2 cabinet and Kuka KR30-3 robot. Software ver: V7.1.7 SP05.


    There`s only one main program that we run in EXT mode and it works fine. When we go home and leave this robot on but not working for the night, sometimes there is message at morning that says "Ackn: General motion enable" so the move enable signal has been dropped at some point by itself. We have made a jumper for move enable in cabinet and it`s forced to true in sps.sub, in programs I didn`t find any command that would set it false either.


    This is not a big problem at the moment as this message can always be acknowledged but maybe it will develop into more serious way if we don`t find the cause for this behavior. Do you have any idea what could drop the move enable signal here?

    Edited once, last by ophakala ().

    What controls that signal?

    That is robot input so something external is controling it... PLC?

    Maybe robot stays powered but the PLC does not. Or it is PLC logic.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    The jumper is between Beckhoff IO cards, so when we set OUT[47]=TRUE then IN[84] is also TRUE. This output 47 is forced to TRUE in sps.sub.


    Code
    ;$OUT[47]->$IN[84] ;Jumper for MoveEnable
;$OUT[46]->$IN[85] ;Jumper for DrivesOn
;$OUT[45]->$IN[86] ;Jumper for DrivesOff
$OUT[47]=TRUE ;Force MoveEnable

    Are there any other messages that come up during the same time period?


    The fact that it's an "Acknowledge" message means that $MOVE_ENABLE was lost, but then came back. So whatever the root cause is, it's transient.


    Is there anything else that can affect the signal? Anything that could cause a power blip on the outputs of the I/O modules? You can lose output power on the Beckhoff cards without losing communications, so that could cause the symptoms you're seeing.


    Other than that, I would pull a backup from the robot, and run it through a search program for anything that touches $OUT[47]. There may be some odd bit of code somewhere that could ause $OUT[47] to "blip" briefly.

    I don`t know if this was the reason but in some interrupt program we had unnecessary $Move_enable=TRUE command because the signal was already on. There was also loose wiring in acknowledgement button (pushbutton) that I fixed. At least now it doesn`t give this general motion enable message anymore.

Advertising from our partners