Advertising

Pausing a program with an input

  • What’s the best practice for using a digital input to pause a program/robot motion when TRUE and continue from the same point when FALSE without reset or message clearing ?


    Also is there any part of the X11 that could act in this manner or do they all require acknowledgements from the smart pad?


    Essentially we’d like to set a program running AUT with the smart pad then disconnect it. Then have one button that would pause the program to allow for examination and then resume the program once examination was complete.


    KRC4 8.3.4

  • AD
  • Do you want to halt the robot anywhere along its path, at any arbitrary time? Then an Interrupt or abusing one of the system inputs (like $MOVE_ENABLE) is probably your only option. Dropping $MOVE_ENABLE would create a fault that would need to be cleared, so that's definitely not a preferred option.


    Another, slightly janky hack, would be to use the SPS to control $OV_PRO -- have the input turn $OV_PRO down to 0%, then restore it to whatever the previous value was when the input goes False.

  • Yes anywhere along a path at any arbitrary time, would be ideal.


    I have read around 10 or so examples of Interrupt code on here but all seem to be different and all seem to go about things in slightly different ways


    I've pulled the code below form the KRL-Syntax (please let me know if theres more info in a different manual) but can't get me simple little mind around it.


    So from what I understand if input 99 is true it will brake (controlled ramp) then PTP $POS_INT what does this do? Then resume back into Search() how does it know which part of the path to resume from and will it require a BCO run before resuming or anything to figure out where it is?

  • That example isn't right for what you want to do -- it's intended to physically search-to-contact, then cancel the search motion and send the robot somewhere else. You want to pause the active motion, then resume it again.


    You don't want to use the RESUME command -- it actually does the exact opposite of what its name implies. It cancels the active motion.


    BRAKE will bring the robot to a halt. Don't use the PTP $POS_INT, that will move the robot back to where the Interrupt fired, and might take you off path.


    So, in that example, your ERROR() routine should look a bit like:

    Code
    DEF ERROR()
    INTERRUPT OFF 25
    BRAKE
    WAIT FOR NOT $IN[99]
    INTERRUPT ON 25
    END

    INTERRUPT OFF ensures the interrupt doesn't fire again while the program pointer is in the interrupt routine. BRAKE brings the robot to a quick halt, without taking it off path or breaking the program flow. Then the WAIT basically pauses the program until $IN[99] goes False again. Then the Interrupt is re-armed so that it'll work the next time you use it, before the program pointer goes back to where it left the SEARCH() routine.


    Also, your BCO motions should probably be in MY_PROG, not in SEARCH. SEARCH should only contain the motions you want to be able to interrupt. BCO motions, starting/ending HOME positions, and similar should probably be located above the interruptable level.

  • So should the SEARCH() routine contain any INTERRUPT commands..!? what turns the interrupt on for the first time?


    Also thank you for this, the help is greatly appreciated.

  • search does not belong to this... the whole point in calling search is to stop (and abandon) motion when something is found.

    RESUME command would be used to abandon subprograms and continue running main program where interrupt was declared.



    and that is not what you want when pausing.

    you probably want something like

    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

  • btw. the example expected maintained signal.... (switch or button like commonly used for E-Stop function)


    if you want to use momentary button, logic need to be adapted a bit to keep track of changes. there a different way to do this.

    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

  • I thought that maybe the case, I’ll hopefully have the sensors soon so I can have a play with them and see what the outputs are capable of


    Is it possible to add a wait to slow down the sample rate of the sensor/input? It wouldn’t matter if the pause had a minimum time once triggered

  • what do you mean? using debounce logic to prevent rapid input change? how many inputs?

    you have input, programmable controller, timers so.. everything needed is in your hands

    here is an example for resampling 200 inputs


    DECL INT n

    DECL INT update_interval = 400 ; (ms) adjust as needed

    DECL BOOL IN_DELAYED[200]



    $TIMER_STOP[1]=FALSE

    IF $TIMER[1]>=0 THEN

    $TIMER[1]= - update_interval

    FOR n=1 to 200

    IN_DELAYED[n]=$IN[n]

    ENDFOR

    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

  • I was thinking simpler,


    So if you have one input and it pulsed for 30ms for example. So if it was capable of going from false to true and back again in under a second.


    I’m assuming 30ms pulse would be enough to turn the interrupt on and move the program to the pause routine.


    If you put a wait 5 sec before WAIT FOR NOT $IN[99] would this essentially stop if form checking the input for 5 sec to give the sensor/input 99 a chance to settle?

  • How are you going to use the resampling practically.

    i wouldn't unless there was a need for it. personally i din't recall such need, input modules in general have some 3-10ms built in and that seem to take care of the problem. the example was put together with SPS in mind, in reality if i needed something like this, i would rather do it in an interrupt.


    If you put a wait 5 sec before WAIT FOR NOT $IN[99] would this essentially stop if form checking the input for 5 sec to give the sensor/input 99 a chance to settle?

    sounds good...

    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

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