error when using multiple trigger when distance DO X=X+1

ML_VS · November 26, 2018 at 8:33 AM

Hello there,

KRC4 , kuka OPC V8.3.21 HF1 , KR240 , workvisual 4.0.26

In one of my program, I'm using "trigger when distance" to keep track of which point has been reached by the robot.

$advance = 2

Code

TRIGGER WHEN DISTANCE = 1 DELAY = 0 DO programStepNbr=programStepNbr+1
      ;FOLD PTP P1 CONT Vel=50 % PDAT1 Tool[12]:CNThandling Base[1]:WORLD;%{PE}%R 8.3.38,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:P1, 3:C_DIS, 5:50, 7:PDAT1
         $BWDSTART=FALSE
         PDAT_ACT=PPDAT1
         FDAT_ACT=FP1
         BAS(#PTP_PARAMS,50)
         PTP XP1 C_DIS
      ;ENDFOLD



      ;STEP 6 MOVE TO FRONT CNT 2
      TRIGGER WHEN DISTANCE = 1 DELAY = 0 DO programStepNbr=programStepNbr+1
      ;FOLD PTP P2 CONT Vel=50 % PDAT0 Tool[12]:CNThandling Base[1]:WORLD;%{PE}%R 8.3.38,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:P2, 3:C_DIS, 5:50, 7:PDAT0
         $BWDSTART=FALSE
         PDAT_ACT=PPDAT0
         FDAT_ACT=FP2
         BAS(#PTP_PARAMS,50)
         PTP XP2 C_DIS
      ;ENDFOLD



      ;STEP 7 MOVE TO FRONT CNT 3
      TRIGGER WHEN DISTANCE = 1 DELAY = 0 DO programStepNbr=programStepNbr+1
      ;FOLD PTP P3 CONT Vel=50 % PDAT0 Tool[12]:CNThandling Base[1]:WORLD;%{PE}%R 8.3.38,%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:P3, 3:C_DIS, 5:50, 7:PDAT0
         $BWDSTART=FALSE
         PDAT_ACT=PPDAT0
         FDAT_ACT=FP3
         BAS(#PTP_PARAMS,50)
         PTP XP3 C_DIS
      ;ENDFOLD

Display More

But, when doing like this, the variable programStepNbr is only incremeted once when the robot reaches P3.

The only way I could make it work was to change TRIGGER WHEN DISTANCE = 1 DELAY = 0 DO programStepNbr=programStepNbr+1 by TRIGGER WHEN DISTANCE = 1 DELAY = 0 DO programStepNbr=7 , 8 , 9 and so on.

I suspect it'is due to the advance run (again). Is there an explanation why ?

Also, sometimes it can happen that 2 following points have the same coordinates (because while programming we put more points than necessary to create the trajectory). How will the "trigger when distance" behave?

Thank you in advance

**panic mode** · November 26, 2018 at 1:57 PM

it does exactly what is supposed to do... synchronize action with next motion where DISTANCE decides if it is begin or end of that motion.

**SkyeFire** · November 26, 2018 at 2:10 PM

For two points programmed at the same location in space, if each point has an identical TRIGGER command associated with it, the TRIGGERs will probably fire at the same time, but be sequenced by their order -- Probably, the first TRIGGER that the main run pointer encounters will fire first, with the second queued immediately behind it.

TRIGGER statements are used to 'bypass' the Advance Run Pointer, so I doubt that's your issue. Normally, I would have said that you shouldn't be using a mathematical expression in the DO section of the TRIGGER, but it seems like it's working at least once... odd.

My best suggestion at the moment is to create a small subroutine that performs the incrementing math, and call that subroutine from each TRIGGER (you will need to explicitly add the PRIO=-1 argument as well). I suspect this will resolve your issue.

ML_VS · November 26, 2018 at 2:42 PM

panic mode , the trigger when distance is working fine, the issue that I have is that, in my example, after playing the 3 ptp points, my variable pragramstepNbr is incremented only once, while it should have been incremented 3 time.

SkyeFire, thank you, I just tried using a subroutine and now it is working as it should be. Looks like it is indeed due to the mathematical expression in the trigger when distance.

Anyway, thank you guys!

**panic mode** · November 26, 2018 at 3:13 PM

maybe... it depends on when and where your variable programStepNbr is used or if you are monitoring it correctly (refresh?)

ML_VS · November 26, 2018 at 4:00 PM

panic mode, the variable is local (defined in the .dat), but for the sake of debugging I removed it from the .dat and made it global (in config.dat). It is only used in this program, not in the sps.
I didn't do anything else other than using a subprogram with the increment inside to solve the issue.

and regarding the monitoring, I'm using the built-in variable display on the KCP (I'm working in auto-ext mode).

Also, while debugging,I saw that if I put a wait sec between points , then there is no problem with the variable increment.

**panic mode** · November 27, 2018 at 5:12 AM

[size=1em]your $ADVANCE must be 3 or greater.[/size]
[size=1em]this means all triggers are initialized while first motion is taking place. at THIS moment value is zero for your variable (and each trigger takes a note of it).[/size]

[size=1em]so each trigger does work but... each of them takes variable value from the moment of initialization, then adds 1 to it. so in this specific example, they all get same result.[/size]

[size=1em]the best solution is to not do calculations, just do an assignment:[/size]

[size=1em]trigger .... DO programStepNr = 1[/size]
[size=1em]trigger .... DO programStepNr = 2[/size]
[size=1em]trigger .... DO programStepNr = 3[/size]
[size=1em]etc.[/size]

[size=1em]EDIT:[/size]

[size=1em]I am fascinated how often people try to monitor or micromanage each and every motion of the robot, for example have PLC check and bless each and every robot instruction. i find this just crazy, if that is the goal, why not use mxAutomation? even if this had value that i don't see, amount of work and [/size][size=2px]maintainability[/size][size=1em] of programs are not favorable[/size][size=1em]. it would be much simpler to monitor changes of $POS_FOR to increment some "motion counter" variable automatically, without sprinkling entire program(s) with TRIGGER commands or IO instrctions. and that would work with ANY robot program... just saying. or how about $PRO_IP1, or more specifically $PRO_IP1.SNR and $PRO_IP1.SNR_C[/size]

ML_VS · November 27, 2018 at 8:34 AM

panic mode ok it makes sense now.

Regarding your comment, if it was a simple motion program I agree with you, but in this case it is a program with motions , collision detection and tool operation inside(which is not a simple gripper). The whole program can be interrupted, so we need to keep track of which step of the program - being a simple motion or a tool operation - was in progress to react accordingly.

I'm sure there is most certainly an easier way to manage this. I will take a look at those system variables you suggested to see if it can be helpful in our current program structures.

error when using multiple trigger when distance DO X=X+1

Advertising from our partners

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