Pausing a program with an input

Use interrupt.

If the robot worked in Automatic External mode, X11 can be used, the confirmation/program resume signal would be sent from the button. Otherwise, as spiral suggested, use interrupt.

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.

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:

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.

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

DEF MY_PROG( )
INI
INTERRUPT DECL 25 WHEN $IN[99]==TRUE DO PAUSE()
WAIT FOR NOT $IN[99]
INTERRUPT ON 25

; do something with robot...whatever...
LOOP
  PTP P1
  PTP P2
ENDLOOP

END


DEF PAUSE()
  BRAKE
  WAIT FOR NOT $IN[99]
END

you may turn it off as well as needed... for example you may want to only allow pause during P1 motion.

sure but interpolation time is 12ms, changes faster than that may not be even registered.

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.

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

panic mode How are you going to use the resampling practically, is it in it's own submit interpreter? Would there be racing conditions - isn't it possible to read signals from two periods - if you are combining IN[1] and IN [196] for example.

Quote from dexterv

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.

Quote from Orange_Will

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...