Wait on input during motion?

n0909 · Jun 1st 2021

Hi all,

Hoping to see if someone had done a smarter and more simpler way to auto search for a part? Parts are stacked vertically and robot will be incrementing Z everytime the program is loaded.

I am currently following the logic as below,

MAIN PROGRAM

HOME

LIN P1

LIN P2

IF NOT PARTFOUND THEN

REPEAT

PTP $pos_act

BAS(#VEL_CP, 0.25)

BAS(#ACC_cp, 10)

LIN_REL {Z -100} C_DIS

UNTIL (PARTFOUND)

ENDIF

;PART FOUND

DO SOMETHING WITH PART.

END

So how do I stop the current logic when part found in a simpler way apart from setting $ov_pro speed to 0 and interrupts and end the iteration.?

Just want to make sure the relative linear motion terminates when part present is detected by an input.?

Any helpful suggestions appreciated.

Kind regards

Mentat · Jun 1st 2021

This has been discussed quite a few times on the forum already.
You will want to use an interrupt that triggers from the input and run a search function that gets closer to the part. The interrupt will terminate the search function prematurely and from there the main program continues.

Similar problem

**SkyeFire** · Jun 1st 2021

Quote from n0909

IF NOT PARTFOUND THEN
REPEAT
PTP $pos_act
BAS(#VEL_CP, 0.25)
BAS(#ACC_cp, 10)
LIN_REL {Z -100} C_DIS
UNTIL (PARTFOUND)
ENDIF

Display More

What are you trying to do here? The PTP #POS_ACT will counteract the C_DIS on the LIN_REL, so the robot will do stop/go/stop/go every 100mm.

If you removed the PTP $POS_ACT, you'll end up stopping some 200-400mm lower than the position where PARTFOUND goes True, due to the Advance Run Pointer. This situation is what Interrupts were created for.

Your approach might work, if you used much smaller Z steps, and your tooling had a generous tolerance for height errors. So, if your gripper had spring-loaded suction cups with ~40mm of spring travel, and you used -10 in the LIN_REL instead of -100.

n0909 · Jun 1st 2021

Quote from SkyeFire

What are you trying to do here? The PTP #POS_ACT will counteract the C_DIS on the LIN_REL, so the robot will do stop/go/stop/go every 100mm.

If you removed the PTP $POS_ACT, you'll end up stopping some 200-400mm lower than the position where PARTFOUND goes True, due to the Advance Run Pointer. This situation is what Interrupts were created for.

Your approach might work, if you used much smaller Z steps, and your tooling had a generous tolerance for height errors. So, if your gripper had spring-loaded suction cups with ~40mm of spring travel, and you used -10 in the LIN_REL instead of -100.

Thanks skyefire,

Unfortunately the tool does not allow for tolerances so interrupts might be the only way forward as Mentat suggested.

I assumed the stop go stop would give the controller enough time to terminate the motion prematurely but looks like it doesn't.

But here's what I'm trying to do.

1.Search whether the part is closer. $IN[90]

2.Search when the part is in contact. $IN[91]

SO I will be needing two interrupts,

Can you suggest what the syntax might look like for two interrupts in the same program?

Tia

**panic mode** · Jun 1st 2021

what does it mean "part is closer...."?

if you want two interrupts just declare two instead of one...

make sure to avoid used ones or reserved range.

in your program insert something like:

Code

; your program is started...
INTERRUPT DECL 11 WHEN $IN[91] DO Part_In_Contact()
INTERRUPT DECL 12 WHEN $IN[90] DO Part_Is_Closer()
 
WAIT FOR NOT ($IN[90] or $IN[91])

INTERRUPT ON 11
INTERRUPT ON 12
; do something
INTERRUPT OFF 11
INTERRUPT OFF 12
; do something else

Display More

then after the END of your program add ISR routines

Code

DEF Part_In_Contact()
  ; your code... 
END

DEF Part_Is_Closer()
  ; your code...
END

For more details read the manual and check examples in the forum. This has been done many times...

n0909 · Jun 1st 2021

Quote from panic mode
what does it mean "part is closer...."?

if you want two interrupts just declare two instead of one...
make sure to avoid used ones or reserved range.

in your program insert something like:
Code
; your program is started...
INTERRUPT DECL 11 WHEN $IN[91] DO Part_In_Contact()
INTERRUPT DECL 12 WHEN $IN[90] DO Part_Is_Closer()
 
WAIT FOR NOT ($IN[90] or $IN[91])

INTERRUPT ON 11
INTERRUPT ON 12
; do something
INTERRUPT OFF 11
INTERRUPT OFF 12
; do something else
Display More
then after the END of your program add ISR routines
Code
DEF Part_In_Contact()
  ; your code... 
END

DEF Part_Is_Closer()
  ; your code...
END
For more details read the manual and check examples in the forum. This has been done many times...
Display More

Thanks panic mode,

Part is closer is turned on when the ultrasonic sensor gets to 100mm above the part to tell me to reduce speed and search for part to make contact. At this point the vac is turned on to continue lin_rel motion -2mm on Z until it senses vac made signal or does not go past the 100mm allowed travel and issue a fault

n0909 · Jun 2nd 2021

Quote from panic mode
what does it mean "part is closer...."?

if you want two interrupts just declare two instead of one...
make sure to avoid used ones or reserved range.

in your program insert something like:
Code
; your program is started...
INTERRUPT DECL 11 WHEN $IN[91] DO Part_In_Contact()
INTERRUPT DECL 12 WHEN $IN[90] DO Part_Is_Closer()
 
WAIT FOR NOT ($IN[90] or $IN[91])

INTERRUPT ON 11
INTERRUPT ON 12
; do something
INTERRUPT OFF 11
INTERRUPT OFF 12
; do something else
Display More
then after the END of your program add ISR routines
Code
DEF Part_In_Contact()
  ; your code... 
END

DEF Part_Is_Closer()
  ; your code...
END
For more details read the manual and check examples in the forum. This has been done many times...
Display More

Where does the pointer go to if I add a RESUME function in the part in contact?

**panic mode** · Jun 2nd 2021

when using RESUME, pointer returns to program level where interrupt is declared. this is why search motion must be also placed in a subroutine.

**SkyeFire** · Jun 2nd 2021

Quote from n0909

But here's what I'm trying to do.
1.Search whether the part is closer. $IN[90]
2.Search when the part is in contact. $IN[91]

SO I will be needing two interrupts,
Can you suggest what the syntax might look like for two interrupts in the same program?

The syntax would look like Panic's example. You can have several Interrupts ON at the same time (I don't recall the limit offhand, but it's 6 or more), although you want to be careful about having one interrupt fire while another interrupt's ISR is still running.

If you programmed a simple two-point search path (start above the top part, end just below the bottom part), you could have the robot do a single continuous motion. The first interrupt could reduce $OV_PRO, and the second would use BRAKE F (for rapid stopping) followed by RESUME to terminate the in-progress motion.

But if your tool has no compliance, your reduced speed may have to be quite slow -- there is always some I/O delay time in handling an interrupt, and the robot cannot stop instantly. Not to mention, vacuum sensors have delay time in "making" vacuum as well.

And, of course, after the "contact" interrupt, the main program would need to restore $OV_PRO to normal speed.

Alternatively, both ISRs could use BRAKE and RESUME if you want the move to contact to be limited to a certain distance past the trigger point of the ultrasonic sensor.

Quote from n0909

Where does the pointer go to if I add a RESUME function in the part in contact?

Interrupt Example

n0909 · Jun 9th 2021

Hi all,

I had populated the below and seem to be reasonably working well but will there be an issue with re-triggering interrupts in the same program over and over again?

Any helpful insights will be greatly appreciated.

Code

DEF part_st( )



CONTINUE
IF $ADVANCE==0 THEN
    GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
    INTERRUPT ON 3 
    BAS (#INITMOV,0 )
ENDIF  ;if $advance==0


INTERRUPT DECL 11 WHEN $IN[91] DO PARTCLOSE()
INTERRUPT DECL 12 WHEN $IN[92] DO STOPATPART()



WAIT FOR NOT ($IN[91] OR $IN[92])

PTP XP1
PTP XHOME

;STATIC POINT
LIN XP2

O_GRIP = FALSE

INTERRUPT ON 11
INTERRUPT ON 12

BAS(#VEL_CP,0.05)BAS(#ACC_CP,5)
;FAST SEARCH FOR part
LIN XP3


;CALCULATE DISTANCE TO Part
XP4.Z = rDIS_TO_Part - 100.00

BAS(#VEL_CP,0.01)
BAS(#ACC_CP,1)
;SLOW SEARCH FOR part
LIN XP4




 
IF (O_ABORT_OK ==TRUE) THEN
;DO NOTHING
;END PROG
ELSE
LIN XP5
LIN XP6
LIN XP7
$ADVANCE = 3
PULSE(O_PART_GRIP,TRUE,3.0)
ENDIF
O_ABORT_OK = FALSE
END







DEF RETRYGRIP()

INTERRUPT OFF 11
INTERRUPT OFF 12


O_GRIP = FALSE
O_GRIP_ERR = FALSE

LIN XP2
PTP XHOME
  

PULSE(O_GRIP_ERR,TRUE,3.0)
WAIT FOR ((I_GRIP_RETRY)OR(I_GRIP_ABORT))

IF((I_GRIP_RETRY)) THEN

    INTERRUPT ON 11
    INTERRUPT ON 12

    BAS(#VEL_CP,0.05)
    BAS(#ACC_CP,5)
    ;FAST SEARCH FOR part
    LIN XP3

    ;CALCULATE DISTANCE TO Part
    XP4.Z = rDIS_TO_Part - 100.00

    BAS(#VEL_CP,0.01)
    BAS(#ACC_CP,1)
    ;SLOW SEARCH FOR part
    LIN XP4

    INTERRUPT OFF 12

ENDIF



IF(I_GRIP_ABORT) THEN
    ABORTGRIP()
ENDIF


INTERRUPT OFF 11
INTERRUPT OFF 12

END












DEF ABORTGRIP()
INTERRUPT OFF 11
INTERRUPT OFF 12

O_GRIP = FALSE

LIN XP2
PTP XHOME
PTP XP1

O_ABORT_OK = TRUE  

END





DEF PARTCLOSE()
BRAKE F
PTP $POS_ACT
rDIS_TO_Part = $POS_INT.Z
INTERRUPT OFF 11
END



DEF STOPATPART()
BRAKE F
PTP $POS_ACT

O_GRIP = TRUE



WAIT SEC 2.0


$TIMER_STOP[1]=TRUE
$TIMER_FLAG[1]=FALSE
$TIMER[1]=-2000
$TIMER_STOP[1]=FALSE



WAIT FOR ((I_PART_GRIP_OK)OR($TIMER_FLAG[1]))


$TIMER_STOP[1]=TRUE


IF $TIMER_FLAG[1]== TRUE THEN
    RETRYGRIP()
ENDIF




IF (I_PART_GRIP_OK) THEN
;DO NOTHING
ENDIF



INTERRUPT OFF 12



RESUME



END

Display More

**SkyeFire** · Jun 9th 2021

Quote from n0909

will there be an issue with re-triggering interrupts in the same program over and over again?

There should not be, as long as you manage the INTERRUPT ON and OFF commands carefully.

The first thing any Interrupt Service Routine should do is turn the Interrupt that called it OFF, so as to ensure that any anomalous conditions (like a "flickering" input) do not cause the interrupt to fire while the ISR is still executing. When to turn the Interrupt back ON again depends on where you need it.

So your INTERRUPT OFF commands should be before the BRAKE commands.

n0909 · Jun 9th 2021

Quote from SkyeFire

There should not be, as long as you manage the INTERRUPT ON and OFF commands carefully.

The first thing any Interrupt Service Routine should do is turn the Interrupt that called it OFF, so as to ensure that any anomalous conditions (like a "flickering" input) do not cause the interrupt to fire while the ISR is still executing. When to turn the Interrupt back ON again depends on where you need it.

So your INTERRUPT OFF commands should be before the BRAKE commands.

Thanks Skyefire.

Much appreciated.

Wait on input during motion?

Advertising from our partners

How to see your Job Posting (search or recruit) here in Robot-Forum.com

Robotics Technician - Detroit/Ann Arbor area - Radwell International

Share

Tags