Posts by kiwasuse

  • Block motion until signal is reset in ISR

    Quote from SkyeFire

    That doesn't sound right. The BRAKE command has been around for at least 30 years, and I've never encountered an issue like this. Can you show the code that generated this fault?

    Yes. Please see a screenshot below of the code and the error thrown.


    Furthermore, with hindsight, I'm realizing that an interrupt is indeed not the best to use in this case scenario.

    Still interested to understand why a BRAKE command causes a problem?

  • Block motion until signal is reset in ISR

    Quote from panic mode

    i do not like to see lengthy or long running interrupt code. interrupts should be short... just a little zing and get the heck out of there... let the rest of the code do its thing. adding wait statements, loops etc inside interrupt completely defeats the purpose of an interrupt.

    I am in total agreement with this - this ISR resulted in few code draft iterations. I aim to ultimately get rid of the wait and loops.

    Quote

    then next thing is priorities... i do not understand why people try to use interrupt 1. this is the highest priority and will preempt anything else... and running this in a loop or with some WAIT statements means that nothing else can work.

    As far as Interrupt 1 is concerned, I do not see why it can't be used or should be avoided at all times. I see it as a situational tool that should carefully be used. The ISR routine I provided is clearly not a good example.

    Best would be not using loops and WAIT statements, but interrupt 1 is not reserved according to documentation thus, can be used.

    Quote

    next, the ISR routine does not even stop robot. it calls another function that is meant to be used in submit interpreter... which is the slowest, least predictable, low priority task. if you want to stop the robot using an interrupt, why not use BRAKE instruction? and why not back off from whatever we just collided with and then display user dialog? it would allow for much easier recovery.

    I did try to use BRAKE. For whatever reason, it doesn't work when I replace the ROB_STOP with a BRAKE. The submit crashes with error KSS01425 Instruction sint() inadmissible at line 25 (line 25 correspends to BRAKE command).

    I am not able to back off from whatever the robot collided with as some of the operators somehow manage to collide the robot when jogging it.

  • Block motion until signal is reset in ISR

    Hi all,

    I'm rewriting some code I had running in a submit task loop to an interrupt for performance reasons.

    The aim is to have the interrupt triggered whenever a collision detection signal coming from a welding machine is FALSE. Whether a program is selected or not, the ISR should stop the operator from continuing the program and block any further motion as long as the signal is FALSE and as long as the operator does not acknowledge some MsgDialogs. I came up with the following:

    And I'm defining the interrupt as follows in the submit:

    Code
    &ACCESS RVP

DEF  weld_bg_task ( )
   GLOBAL INTERRUPT DECL 1 WHEN DI_limitSwitchFRONIUS == FALSE DO handleLimitSwitch()
   LOOP
      
   ENDLOOP
END

    However, this is not the behavior I'm aiming for because of few reasons:

    - WAIT FOR DI_limitSwitchFRONIUS == TRUE is more of a hack than anything else to allow the operator to acknowledge the error. The idea of this workaround is to let the operator acknowledge the error thrown by ROB_STOP_RELEASE then fix the welding torch back in position.

    - Ideally, I'd like to turn the drives off and force the operator to turn them on again. AFAIK, there is any variable nor KRL function to do so if the robot is not on external mode.

    Furthermore, I'm also aware I could make use of IR_STOPM, but I'm trying to avoid KRL routines provided by KUKA such as BAS, IR_STOPM mainly because of the way they are documented both in production documentation and in the source code.


    It'd be much appreciated to hear your ideas how to improve the ISR above.

  • External emergency stop XG11.1 on KRC5 Micro

    Quote from panic mode

    of course that will not work. the safety circuits are redundant. this means that everything is on two channels (Ch.A and Ch.B), and each button must break both channels. Since you have more than one button, you can daisy chain them but they still must have contacts on both channels.

    An example would be something like this:

    the way you drew it, each button would break just one channel. this not good because if the difference between channels exist (one broken and one not) safety controller would fault and also enter lockout state. typically, lockout state is only cleared by cycling power.

    Ah, that makes perfect sense. I gave this a shot and it worked just fine. Thank you panic mode!

  • External emergency stop XG11.1 on KRC5 Micro

    Good afternoon all,

    I'm currently having my first experience with a new KRC5 and KR8 2100-HW Cybertech. I'm having a bit of hard time getting the hang of the different XG11.1 safety interface compared to old X11.

    Basically, I'm trying to connect two emergency buttons one inside of a cell and one outside. Each emergency button is made up of:

    - Two normally closed contact blocks (Schneider ZENL1121)

    I tried the following wiring:

    But this didn't work.

    My electrical skills are limited, so apologies for such diagram.

    Any guidance would be much appreciated! Thank you.

  • Execute interrupt after emergency stop

    Quote from SkyeFire

    Nothing jumps out at me as being obviously wrong with that code. I might try putting the BRAKE command after the call to StopMidWeld (or eliminate it entirely? I'm not sure how it interacts with the E-stop condition). Maybe prefix the $CYCLFAG setting and Boolean setting in TurnOffInterupt with CONTINUE to ensure the Advance Run Pointer can't be coming into play.

    Get it. Thank you SkyeFire. I'll run some tests with your suggestions and see if the behavior is more consistent.

  • Execute interrupt after emergency stop

    Thanks SkyeFire.

    I did consider using IR_STOPM, but that unfortunately is not an option due to the fact I want to keep the logic of handling weld recovery (interrupt based) and arc trigger handling (submit task) separate.

    Furthermore, I found IR_STOPM (as other KUKA helper functions) to be rather opinionated to the point it dictates how you write code. That said, this ultimately comes down to personal preferences.

    What's also interesting is that the interrupt is triggered, but somehow the execution seems to stop at stopHandleMidWeldFail() when the interrupt misbehaves.

    Would there be any other approach or solution and most importantly, why does the interrupt work at a times, but is not consistent? Would there be some race condition?

  • Execute interrupt after emergency stop

    Hello,

    I'm currently using an interrupt to monitor a signal and trigger a subroutine depending on the condition.

    If the signal is FALSE, then I want to stop the robot, prompt a MsgDialog then take action according to the user's input.

    To put it in code, it looks like this:

    main_program.src

    Code
    BAS (#INITMOV,0 )
startWeld()
LIN { X 183.935, Y -202.468, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } C_DIS
LIN { X 363.850, Y -196.939, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } C_DIS
LIN { X 369.380, Y -376.854, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } C_DIS
LIN { X 189.483, Y -382.382, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } C_DIS
LIN { X 189.465, Y -382.383, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } C_DIS
LIN { X 187.914, Y -331.920, Z 57.010, A 86.7689, B 89.9992, C 0.0086, E1 -0.7420, E2 0.0000, S 'B00010', T 'B001010' } 
stopLongWeld()

    Inside startWeld, I am defining the following:

    And finally, my interrupt routine looks like this:

    In an Submit program, I'm also deciding when to turn off DO_weld. DO_weld is turned off when an emergency stop is triggered.

    The interrupt works, but in a inconsistent way. I am expecting the interrupt to be triggered whenever DI_arcPresence is False no matter where DO_weld is turned off from.

    I'm unsure why the interrupt is triggered every once in a while and sometimes not.

  • Coordinated motion approximation

    Quote from DannyDJ

    Can you post your code which you are trying to run or at least the initialization part of the code? You are saying that you cannot execute the program, but you are then somehow able to execute the code if you noticed that C_VEL doesn't have any effect on robot behaviour and robot still stopping exactly at points. Does robot generates any messages when testing the code?You also said you have parameter $advance=5, but in shared code there is no such parameter.

    Also did you calibrate the DKP-400 with the robot?

    Or maybe you can try first simple rectangle shape with just 4 points aproximated and see if that works.

    Please find the full program below:

  • Coordinated motion approximation

    Quote from DannyDJ

    Can you even execute this program? Or am I missing PTP move.

    First move in the program cannot be LIN move but PTP(you can use ptp $pos_act as the first move).

    In your program you are using C_DIS approximation with $APO.CDIS=0.25, allowing robot to only approximate max to quarter of mm. Did you tried to increase this value? Or use C_VEL approximation where you have set $APO.CVEL=100

    Also $APO.CPTP parameter is only for PTP moves.

    And in your program, you are missing INI line, so your $ADVANCE parameter could be also set to 0, so robot cannot approximate also. This parameter defines how many moves robot is looking in advance to calculate approximation path between points. Or use BAS(#INITMOV,0) in the first line of your program, which would set $advance parameter=3 by default.

    You are very right about not being able to execute the program. It's worth noting that I included just a part of my program to keep it short and concise.

    Furthermore, I did try increasing APO.CDIS. I could notice some improvements, but the motion was still not as continuous as I'd like it to be.

    My advance pointer is set to $advance = 5.

  • Coordinated motion approximation

    Hello,

    I have a KUKA KR C60-3 with a DKP-400, KSS 8.5.7 HF1

    I am expecting the external axis' motion to be approximated between each target. Instead, what's happening is some sudden moves.

    I did check the manuals, but I couldn't find any information about the external axis approximation.

    I am setting my base the following:

    Code
    BAS(#TOOL, I_numTool)
$BASE=EK(MACHINE_DEF[I_MACHIDX].ROOT, MACHINE_DEF[I_MACHIDX].MECH_TYPE, BASE_DATA[I_MACHIDX])
$ACT_BASE=I_BASENO

    And my program is:

    Any help would be much appreciated

  • UserTech: error when triggering a status key when jogging the robot

    Quote from panic mode

    I am not near computer to check the settings you use but... IO are treated differently from other variables. Outputs are sometimes protected, for example when program is running. Try something g else, a flag or your own BOOL variable

    Thanks for the help. Triggering a FLAG instead of a digital output does work. This is quite unfortunate that it is not mentioned in the UserTech documentation.

    Out of curiosity, what is the reason why UserTech wouldn't let one trigger a Digital output while moving the robot?

  • UserTech: error when triggering a status key when jogging the robot

    I have the following status key defined in a .kfd:

    This works as expected; when pressed, function Key1Pressed is triggered, and when released, Key1Released is triggered.

    Problem arises when pressing the button, then right away jogging the robot using the keys. Key1Released will not be triggered when the status key is released while still jogging the robot.

    The following error is returned SETVAR (FULLPATH[] "DO_MANUALWELD", VALUE[] "FALSE") failed. Script WELDKEYS.KEY1RELEASED ABORTED

    Unfortunately, the documentation does not give any information for this use case.


    Is there any way to make it work when multiple status keys are held pressed simultaneously?

    KSS 8.5.7 HF1

    UserTech: version 3.4.2

Advertising from our partners