Interrupt not working in BCO Run

    Hello Everyone

    I would like to know more about the BCO Run and the Interrupt execution in KUKA.

    I have a condition for Interrupt execution to stop the BCO Run Process and ensured that the variable is not ON when the interrupt is turned ON. This was validated.

    In between process, there was a necessity of BCO Run. Theorotically the interrupt should be activated during the BCO Run to Brake the process.

    However the interrupt was triggered after the BCO Run.

    The BOOL Variable $MOVE_BCO is OFF during the BCO Run.

    Can someone support me to stop the robot at the BCO Run in Automatic mode. This is kind of an internal safety so that even when PLC permits, the robot should not be moved.


    Thank You

    this is what $MOVE_ENABLE is for for.

    btw this is a fail-safe signal - robot is allowed to move when signal is TRUE, not when FALSE. this means if PLC is not powered up or I/O is disconnected, robot remains in safe state .... stopped.

    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

    HI,

    BCO is only for AUT and not EXT (with PLC) just for safety.

    If you want to damage the robot or the part there is an easier way to that.

    Just take the actual positon as BCO and you are ready to go (you will find some posts discussing this issue)

    In case of an interruption of the program most of the people want to go to the safe point (BCO) in slow speed in order to prevent any damage by simply stopping the movement.

    regards

    MOM

    BCO is for all modes where human starts program, that includes T1,T2 and AUT.

    in EXT robot is normally started from some controller (PLC or whatever) so BCO here makes no sense and therefore exception is made - no BCO in EXT.

    the thing is that interrupts are edge triggered so missing edge would mean no detection.

    btw about a year or two ago i run into a interesting (or rather disturbing) scenario where turning off $DRIVES_OFF would not stop robot either (confirmed on KSS8.3 and 8.5). this signal seem to be also edge sensitive.

    this is why $MOVE_ENABLE is level triggered and should be used in cases like this.

    btw, if goal is to create an interlock or permissive... use simple logic and basic functions the way they are meant to be used. this is never the place to go rogue or use it as opportunity to showcase programming prowess. this is where KISS principle is way to go.

    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

    Hi panic mode,

    just to correct

    you are rigth BCO is for T1, T2 and AUT (not for EXT) - do you agree so far?

    As I mentioned earier - BCO is for safetey reason - do you agree so far?

    In T1 there is no problem because we are in slow motion anyway - do you agree so far?

    Problem is in T2 (I did not mentioned earlier) and AUT - do do agree so far?

    In EXT it make no sense because the robot start with full speed and may cause damaging parts starting from the wrong position, and this costs all lot of money - do you agree so far?

    A simple way to overcome the problem with BCO (I think this was the initial problem calling an interrupt to do preventing of BCO) is make a ptp movement to the actual position) - no interrupt needed - do you agree?

    You can do this - it is not safe (because of T2 or AUT you have to be out the fence) but you can destroy the part - do you agree?

    If one of or more answers is (are) yes why are you complaining about my previous post?

    regards

    MOM

    Hello Everyone

    Thanks for the kind reply. This is for academic purpose, so I hope you understand what we do here is not complying most of the standardized safety measures, which of course will be in future, but we try to take one step ahead.

    The standard way as suggested is stop move enable when PLC senses that $NEAR_POSRET is false and $ROBSTOPPED is False.

    However, i would like to stop is also from Robot.

    A normal interrupt is not executed in a BCO_Run. It does gets activated once the robot completes its BCO Run. I put a trace on the Flag controlling this Interrupt and found that the signals are complying to the Interrupt requirement. The KUKA doesn't obey the normal procedure here, this is what I found with. From their document, I also found that there is $MOVE_BCO internal variable, which according to their document should be true when a robot is in BCO_Run. But it remains false in all cases.

    So, I woud like to know if someone came across this situation already and apart from this signals, if there is another way, something like the workspace monitoring which stops the robot from entering into the not permitted zones, the robot behaviour in the BCO_Run and which modules are actually functional during this BCO_Run. As I can right now say, IO Module works, but Interrupt functionality doesn't.

    Many Thanks

    you really need to read the manual, most of your questions will be answered there. check pinned topic READ FIRST

    interrupts can be active but disabled. in this case events will be registered but not processed until later, when interrupt is enabled.

    BCO may be disabling interrupts and this can easily be tested though i am not in the mood right now to start OfficeLite.

    read the manual, BCO need to be done once. and when robot is on path there is no reason to do a BCO again. so $MOVE_BCO can remain false after BCO is done, which may be what you are observing

    yes there are different ways to stop robot, one of them is to use workspace and #INSIDE_STOP or #OUTSIDE_STOP

    if needed one can add in submit something like

    IF StopRobotRequested THEN

    $WORKSPACE1.MODE = #INSIDE_STOP

    ELSE

    $WORKSPACE1.MODE = #INSIDE ; or #NONE

    ENDIF

    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

    Hey Thanks for the reply

    Got to know from KUKA that Interrupt is override in the BCO Run and hence interrupts cannot be relied on.

    The $MOVE_BCO should be TRUE, however it is false during the BCO_RUN. Hence a KRCDiag is submitted to KUKA.

    Workspace would be tested and I will update here,

    Thanks

Advertising from our partners