April 24, 2019, 10:08:20 PM
Robotforum | Industrial Robots Community

 LIN_REL in FOR

Author Topic:  LIN_REL in FOR  (Read 407 times)

0 Members and 1 Guest are viewing this topic.

February 06, 2019, 03:48:29 PM
Read 407 times
Offline

Dimitry


Hello everyone,  :help:

I need to improve this :

BAS(#ACC_CP,10)
BAS (#VEL_CP,0.2 )
$APO.CPTP=10
$APO.CDIS=10
;ENDFOLD

FOR M_Inc=0 TO 18
   LIN_REL {X -0.5} C_DIS
   CONTINUE
   IF $IN[I_Blister_Coval]==TRUE THEN
      M_Inc=18
      EXIT
   ENDIF
ENDFOR


The fact is that i have a little stop before it will do the next LIN_REL. I've seen in KUKA a part in TeachBaseSrc.src using the same way !
Am I missing something ?

Oh and the part is done by a trigger (interrupt).

Today at 10:08:20 PM
Reply #1

Advertisement

Guest

February 06, 2019, 04:29:25 PM
Reply #1
Offline

SkyeFire

Global Moderator
Why not do it as a single move with an Interrupt?  As it's written, the Advance Pointer will probably cause you to move an extra 1-1.5mm after the input occurs anyway.


February 06, 2019, 04:33:11 PM
Reply #2
Offline

Dimitry


Thanks for the reply !

Just because, I'm already inside an interrupt. So, can I add an interrupt inside another interrupt ?

February 06, 2019, 04:39:38 PM
Reply #3
Offline

SkyeFire

Global Moderator
Should be possible.  You have to ensure you disable the "higher" Interrupt first (which is the first thing any interrupt service routine should do, anyway).  DECL the new Interrupt inside this routine, and have it call a subroutine dedicated to performing the 9mm X move.  Have the Interrupt call another subroutine that uses BRAKE and RESUME to terminate the 9mm motion.

February 06, 2019, 04:46:53 PM
Reply #4
Offline

Dimitry


Thank you very much, I will try this ;)

February 07, 2019, 01:56:59 PM
Reply #5
Offline

Dimitry


Hey, I'm back !

Unfortunately it didn't work. Apparently, the second interrupt is only triggered when I'm out of the first interrupt.
Well, now I have no more ideas..

February 07, 2019, 03:51:15 PM
Reply #6
Offline

SkyeFire

Global Moderator
Hm...  just working out of my head here, but
Code: [Select]
DEF Main()
  INTERRUPT DECL 1 WHEN $IN[1] DO FirstInterrupt
  INTERRUPT DECL 2 WHEN $IN[2] DO SecondInterrupt
  PTP P1
  FirstInterruptedMove()
  INTERRUPT OFF 1
  IF $IN[1] THEN
    INTERRUPT ON 2
    SecondInterruptedMove()
  ENDIF
  INTERRUPT OFF 2
END

DEF FirstInterruptedMove()
  INTERRUPT ON 1
  LIN P2
  INTERRUPT OFF 1
  WAIT FOR TRUE
END

DEF FirstInterrupt
  INTERRUPT OFF 1
  BRAKE
  RESUME
END

DEF SecondInterruptedMove()
  INTERRUPT ON 2
  LIN_REL {X -9.0}
  WAIT FOR TRUE
END

DEF SecondInterrupt
  INTERRUPT OFF 2
  BRAKE
  RESUME
END

With this structure, both Interrupts terminate the current motion and jump the program pointer back to Main.  So the key is to make each "motion" routine as minimal as possible, do most of the branching in Main(), and avoid nested interrupts.
« Last Edit: February 08, 2019, 02:14:12 PM by SkyeFire »

Today at 10:08:20 PM
Reply #7

Advertisement

Guest

February 08, 2019, 01:51:56 PM
Reply #7
Offline

Dimitry


Ok I see !

Now I'm stuck inside the first interrupt, due to an error telling me that I can not use the RESUME here.
I never understood the RESUME correctly..Why can I not use it to return to main program (interrupts delcared) ?

Sorry, but thanks again for the help ^^

Edit : It's giving me "Prohibited program structure with RESUME"
« Last Edit: February 08, 2019, 01:59:48 PM by Dimitry »

February 08, 2019, 02:13:45 PM
Reply #8
Offline

SkyeFire

Global Moderator
What is the exact syntax of the error message?

I can think of one thing I did wrong in that example -- I should have used a WAIT FOR TRUE to break the Advance Run Pointer at the end of each interruptible motion routine.  That might cause an error similar to what you describe.  I'm going to go back and edit the example to fix this.

Short version:  without a WAIT FOR TRUE, or some other similar command, at the end of the interruptible motion subroutine, the ARP can get back to Main() (and possibly even down into SecondInterruptedMove()) before Interrupt 1 occurs.  The robot's operating system can't really handle this, as there are too many potential variables.  So the onus is on the programmer to constrain the pointer situation.

So, while running a subroutine that is intended to be terminated by an Interrupt with RESUME, you need to ensure that the ARP never exits that subroutine until after the RESUME command has occurred. 
« Last Edit: February 08, 2019, 02:19:40 PM by SkyeFire »

February 08, 2019, 02:24:22 PM
Reply #9
Offline

panic mode

Global Moderator
RESUME command was discussed many times. if this does not help, consider KUKA courses. Forum is not a replacement for formal training.
1) http://www.robot-forum.com/robotforum/kuka-robot-forum/read-first/
2) if you want reply about robot, post it in forum
3) read 1 and 2

February 08, 2019, 04:26:34 PM
Reply #10
Offline

Dimitry


That's perfect. I forgot the ARP everytime..
Big thank you !

panic mode : I saw it. And about formal training, my company just don't care about at this moment, cause of difficult and urgent situation. But I understand your words  :icon_wink:

February 08, 2019, 04:52:08 PM
Reply #11
Offline

panic mode

Global Moderator
everyone cares eventually - when deadline is reached without solution :-)


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

xx
lin_rel and variables

Started by SteamPunkstress on KUKA Robot Forum

4 Replies
4973 Views
Last post April 29, 2015, 03:39:23 PM
by SteamPunkstress
xx
LIN_REL in tool coordinate

Started by ateknea on KUKA Robot Forum

2 Replies
2426 Views
Last post November 19, 2015, 08:41:16 PM
by SkyeFire
xx
Lin_Rel in Tool mode

Started by DRS on KUKA Robot Forum

1 Replies
146 Views
Last post March 15, 2019, 10:58:48 AM
by Fubini
xx
Lin_Rel movements with a base other than world

Started by king nothing on KUKA Robot Forum

4 Replies
1118 Views
Last post August 22, 2017, 01:19:21 PM
by panic mode