Function to set register at begging of the motion

  • Hi, is there any function, to set register at begging of the motion? Same as TRIGGER WHEN DISTANCE=0 on Kuka.


    I could use TIME BEFORE with function call (L PR[1] 100mm/sec CNT100 TB 30.00sec, CALL setreg(1)), but upper limit is 30 seconds, which could cause issues for slower movements.

  • What are you trying to accomplish ? I read your question I can think about 10 different scenarios

    Do you need to know if the robot is moving ?

    Do you need to know if it left the point ?

    Do you need to know if it approaching the point ?

    How precise needs to be ? 1 mm from the point, 10 mm from the point

    ....

    ....

    ....

    I can keep going and going

    Please , be more specific if yo can

    Retired but still helping

  • I want to set number to register when motion begun, so then if someone stop the robot midway and press go to home button, based on this register, I know where robot started and I can select correct path back to home.

  • Use the normal DB 0, so you have the last position, for the very first movement you don't need a DB or similar, you just can set the register the normal way in the line before the movement. For the first movement there is no problem with the advance pointer.

  • Ok

    This question has been answered many times in the forum but beside that Why don't you do what you just described me ?

    Your HOME routine is going to have many jumps . Something like IF R[5:Step]=7 JUMP LBL[7] and on label 7 you have points to send you home or to point 6 and then on point 6 you send the robot to point 5, etc, etc

    Retired but still helping

  • Yeah, I can do it this way, I just want to make a program as simple and readable as possible, so I want to use same number when going inside and outside (I'm using same points for going inside and back outside).


    I try to explain it on the image. If I going to use DB 0, so P1 have number 100, P2 200, P3 300. But When robot is going back through the same points, suddenly P2 have number 100 and P1 0 for example, which will be very confusing for maintenance. I could continue counting up 400,500 etc. but in real program I have way more points, so I would have to write way more code.


  • Because the simple Fanuc TP system doesn't support IF / ENDIF you will have to it a different style anyway, something like that:

    May be I have some errors in the numbers, and the syntax is not really correct, but it sould show the principle:winking_face:

    This is straight forward. And easy to implement, Just kind of finger exercises (If you have RG or ASCII load, otherwise it will be a pain).

  • The concept is perfect BUT there is one problem. P points are local, so P1 in the main program is different than P1 in the Home program.

    Yes, you can teach both at the same time but I wouldnt recommended it, because you need to keep track of any changes.

    The best thing to do is use PR[]


    One more thing, I dont know how fanuc works but lets say you are using CNT5 on one point, I dont think you are never going to achieve DB 0.

    Maybe the best thing to do is


    L P1

    R1= 100

    L P2

    R1=200




    Oops, I did not see hermann post

    Retired but still helping

  • Yes, you are right with the P[x] and position registers, so it's better to use PR[x].

    Or you use a logic where you create the homing procedure for every program locally in the program itself, and of course insert some code to jump to the homing or the normal production code.

  • Thanks for all answers, but that's not what I'm asking for.


    I'm already using PR register and case statement (SELECT). DB works fine with CNT 100. I can't set register straight (R[1]=100), because look ahead pointer.

  • I'm already using PR register and case statement..

    Then show us a real example of your program, not an abstract example that has nearly nothing to with your code, that's some kind of annoying. And we will see.


    In the case of f. e. opening a gripper/ waiting for inputs / using fine points you don't have the problem with look ahead pointer. Therefore you can use r[100] =x in that cases.

  • Hi, is there any function, to set register at begging of the motion? Same as TRIGGER WHEN DISTANCE=0 on Kuka.


    I could use TIME BEFORE with function call (L PR[1] 100mm/sec CNT100 TB 30.00sec, CALL setreg(1)), but upper limit is 30 seconds, which could cause issues for slower movements.

    "begging of the motion" is the important right? You are only using TIME BEFORE because there is no DISTANCE AFTER, correct?


    For clarification do you want to use two registers to keep track of your movement? One that gets set when a motion is started and one that gets set when a motion is finished?


    Something like this(doesn't actually work right but I hope it gets the point across):

    Code
    R[10:nextPos]=1;
    L PR[1] 100mm/sec FINE;
    R[11:reachedPos]=1;
    R[10:nextPos]=0;
    
    R[10:nextPos]=2;
    L PR[2] 100mm/sec FINE;
    R[11:reachedPos]=2;
    R[10:nextPos]=0;

    Or do you only want what I called "nextPos"?


    Apparently there is a TIME AFTER function maybe this helps?

    Edited once, last by TomTom ().

  • Correct, at beginning is crucial. Yes, there is no TIME/DISTANCE AFTER.


    Just one register, where number means last PR point, which robot came through.


    I've tried to explain it on the image. When robot is going inside it setting numbers 100 when reached point P1, 200 when reached point P2, 300 when reached point P3. But when robot is going back through same points, I have to set number for previous point, so it's 100 when reached point P2 and 0 when reached point P1. Reason is, if robot is stop mid way, I called home routine (on the right)and robot based on register go to home pos shortest way.

  • I also wasn't aware of this but I just checked and there is indeed a TIME AFTER function. No DISTANCE AFTER though.

    Edit: nope doesn't work, TIME AFTER gets executed after the completion of the motion

    Edited once, last by TomTom ().

  • I just took a closer look at your example.


    If you don't want to let the robot to return to certain position then don't save them to the register. In this case I think you don't want the robot to return to P3 so R[1]=300 should never be set. Like this the robot will never try to return to P3 during homing. Your homing prog doesn't need a case for R[1]=300 if you do it like this.


    If your homing contains special instructions(for example opening and closing of the gripper) when the robot is on P3 then this solution gets more complicated though.


    Edit: You can also only do this with "end points" where you only go backwards from. If your P3 for example went to a P4 then you HAVE to save P3 to the register.

Advertising from our partners