Movement stops

    In my program in R30iB, I have move instruction : J PR[30] R[49]% CNT70 Offset,PR[18] , and after that another move instruction :
    SKIP CONDITION RI[1]=ON OR RI[3]=ON
    L PR[30] R[50]mm/sec CNT10 Offset,PR[22] Skip,LBL[1000]
    Between the two motion instructions there are also some jumps to labels, IF statetements evaluating DI's, an assignment to a GO, a select statement.
    But no wait instructions.
    Although the first move instruction is done with CNT70 I have the impression the movement very shortly stops when starting at the lineair movement.
    Is it possible that certain instructions force a movement instruction (that is programmed with CNT) to stop at the end just as a 'fine' instruction?
    Maybe the assignment to the GO?
    Or is there a limitation of the number of instructions between two movement instructions?

    These are the code lines that are relevant for the problem, the move instructions are in line 45 and 60 :


    6: LBL[32000:BeginSelect] ;
    7: GO[2:PickSeqNumber]=R[2:Pick1cSeqNumber] ;
    8: SELECT R[2:Pick1cSeqNumber]=0,JMP LBL[1] ;
    9: =10,JMP LBL[10] ;
    10: =20,JMP LBL[20] ;


    40: LBL[10] ;
    41: !R[123:Angle1]=$SCR_GRP[1].$MCH_A ;
    42: !IF (R[123:Angle1]<(-20)) THEN ;
    43: !J PR[56:ToTop1c] R[49:SpdTopCove ;
    44: !ENDIF ;
    45:J PR[30:Pal1Cls_EndSrc] R[49:SpdTopCover%]% CNT70 Offset,PR[18:OfsPick1CloseUp1] ;
    46: ! Pause ;
    47: IF (DI[24:StopEndMove]=ON) THEN ;
    48: PAUSE ;
    49: ENDIF ;
    50: R[2:Pick1cSeqNumber]=20 ;
    51: JMP LBL[32000] ;


    55: LBL[20] ;
    56: OVERRIDE=R[9:SpdOverrideInt] ;
    57: ! Condition for detection cover o ;
    58: SKIP CONDITION RI[1:CovDet1a]=ON OR RI[3:CovDet2a]=ON ;
    59: ! Move ;
    60:L PR[30:Pal1Cls_EndSrc] R[50:SpdSrchCoverFast]mm/sec CNT10 Offset,PR[22:OfsPick1CloseAct] Skip,LBL[1000] , PR[99:PosFast]=LPOS ;
    61: JMP LBL[1001] ;
    62: LBL[1000] ;
    63: R[2:Pick1cSeqNumber]=100 ;
    64: JMP LBL[32000] ;
    65: LBL[1001] ;
    66: R[2:Pick1cSeqNumber]=30 ;
    67: JMP LBL[32000] ;

    A few things may be happening here. 1st, I don't see any lock preg commands. The motion planner cannot look ahead to blend PR movements if they are not write protected. 2nd, there is a lot of jumping around, which is a bad programming practice and may be causing the slow down.

    In many programming languages the JMP LBL was eliminated because it can cause the program to become disorganized and difficult to troubleshoot.


    Sent from my VS985 4G using Tapatalk

    The not locking of the position registers is probably the reason why the motion seems to shortly stop.
    But in my code I should want to stop if a condition (DI) is not ok. I should want to make that check at the start of the lineair movement (when the J movement is finished), or in this case at the approximate point of start of lineair - stop of joint movement. When look-ahead is active I suppose I will need the 'distance before' argument in my joint movement and also ad a call program, or point logic argument to my joint movement, in which I put my condition?
    Also in that 'call program' or point logic, can I just put 'wait DI' to check for the condition?
    If the condition is ok, will this stop the look-ahead (what I don't want, I want a continuous movement if condition was ok, and a stop if condition is not ok)?
    Of do I have to program something like : If (DI[1]=OFF THEN, WAIT DI[1], ENDIF ?

    A couple things occurred to me. You cannot use the lock preg command because the Quick Skip command needs to write to PR[99]. Maybe you can change that to a regular skip function. You can always unlock preg and record LPOS after the skip motion is complete. It looks like you already have a check on line 47 for DI[24] that will pause the program, but that would need a start signal to resume. Are you sure that isn't causing any issue? Also, does your movement go near a singularity point?


    I think the best way for you to solve this is to run a few tests. I would record the 2 positions as points into a simple little program and test different methods. That way you can rule out any other instructions that may be interfering. I would start out as simple as possible, 2 movements using points, (no PR's or Offsets) with a wait command in between Just 3 lines of code. If the wait doesn't work then try the regular skip command. If that works, then I would one by one add other instructions to replicate your more complex program until you find what breaks it. If you do this and find the issue please post what you found out.

    Edited once, last by HawkME ().

    High speed skip limits speed and CNT to a very low value so even if you try to increase it movement will be perform at this max values. If precision it is not a requirement use skip function as HawkME said and do some test in more simplified program. In order to not see a stop movement as it was a FINE try to use an intermediate movement to change speed between the joint and linear movement.

    I want to come back to the question of the check of a signal in between motions.
    If you first lock the PR, then have a joint motion with CNT, the you have check as :
    IF DI[1]= OFF THEN
    WAIT DI[1]
    ENDIF
    Then you have the lineair instruction (with no quick skip).
    then PR lock off.
    I should want to check my DI[1] if the tcp is at the endpoint of the first movement (or in this case the approximation because of CNT). But because of look-ahead of the program pointer it will be read far before that point I suppose?
    Is the best solution here to foresee a program call (to check DI) that is implemented by a 'distance before' on the first movement?

    Sorry to resurrect an old thread, but I think I know why the IF statement is before the wait. At least with Motoman robots, the IF statement executes a tiny bit faster than the WAIT statement, so I've seen code that is done that way to shave milliseconds off of cycle time.


    Personally, I don't see that it has much benefit, so I never write my code that way. If I need to shave cycle time, I do it by optimizing robot motion paths and speed.

Advertising from our partners