Is it possible to pass a point as a parameter?

    Hello all,

    I am not in front of the robot now and I can't test it till the next week. So, to gain a little bit of time I've thought of asking for help here.

    I must store +/- 30 points and before and after all those points, the robot should move to a certain height.

    MAIN ROUTINE (pseudocode)

    Code
    CALL Move_To_Aprox(P[1]);
J P[1] 100% FINE    ;
CALL Move_To_Aprox(P[1]);
CALL Move_To_Aprox(P[2]);
J P[2] 100% FINE    ;
CALL Move_To_Aprox(P[2]);

    I could use Excel to create that text for me.

    Move_To_Aprox ROUTINE (pseudocode)

    Code
    PR[200] = AR[1];
PR[200,3] = 100;
J PR[200] 100% CNT25;

    Notice:

    * I've chosen using points instead of PR because there will be lots of programs and it could be a mess having all the points mixed.

    * I could use offsets, which would be simpler, but I should calculate the value every time the point is modified to ensure the robot goes to the desired height.

    * I could use a LPOS/JPOS instruction to read the coords of the robot once inside Move_To_Aprox, but that seems risky if CNTs are involved (which should not after the work point, but could be messy between the two union points).

    Is there an easier way in Fanuc to achieve this?

    Thank you all!

    With normal TP language you will not be able to transfer a point using a parammeter, the best you can achieve is to transfer an integer with a PR index and access it through indirect access on your new routine, but that won't work for you as you are storing them in P points.

    As you have said, LPOS will only work for you after reaching the point, not before.

    One option is to add the line Titusleptic has written just before the routine you are calling. THIS I think would be the most easy way to do it if you do not know to code in Karel or your controller lacks the option.

    Another one may be with karel opening the file, reading the point with the index you want and storing the point data into the PR, then modifying the Z and executing the motion instruction.

    I know for sure there is a way in Karel to read the data from a file and get a P point as I've done it on the past, you need to open the TPE program with the instruction "OPEN_TPE", then get the P point with the instruction "GET_POS_TPE", you can find it on the "Karel reference manual",

    Finally you can encapsulate this on a routine where you give the program name as a parammeter and also the index of the P point you want of that file, then on karel the routine will copy it to the PR and you can do all the other stuff on your TP routine.

    OK, given your answers maybe the best option for my case would be:

    PR[200] = P[1];

    CALL work;

    PR[200] = P[2];

    CALL work;

    PR[200] = P[3];

    CALL work;

    PR[200] = P[4];

    CALL work;

    ...

    And inside work:

    PR[201] = PR[200];

    PR[201.3] = x;

    J PR[201] 100% CNT25;

    J PR[200] 100% FINE;

    CALL plc_thing;

    J PR[201] 100% CNT25;


    This would make the program easy to maintain, as far as I remember I should be able to touch up the points and, if I make the function dependant on a dummy parameter noone should be able to call it directly from the pendant without having to jump lines of code manually.

    Maybe the best would be to use normal offsets to prevent problems while editing and manually setting the program pointer in the wrong line...

    Thank you all.

    Just remember that you need to have motion instructions to all your points in your "main"-program. One method is to insert an "END"-statement after your code and then put some dummy motion instructions after that:

    Code
    [code that will be executed]
...
END
J P[1] 100% FINE
J P[2] 100% FINE
J P[3] 100% FINE
...
...
<END>

    So if/when you need to touch up your points you can do it down below that END-statement (this is also a good way to structure the programs when using offsets to your motion, by providing a "clean" motion instruction without any offsets in case you want to move to a point without any offsets or if you want to touch up points and don't want to bother with the questions you get whether or not you want to exclude or include the current offset to the new point which always throws me off =D ).

    Quote from robotecnik

    And... would it be possible to loop to assign PR[x] to P[x] at the beginning?

    something like FOR x = 1 to 200 PR[x]=p[x];

    I could use the J P[x] after the END instruction and then everything would be very easy to do:

    In the same loop, I could execute all the movements and calculations only calling one function...

    Thank you all...

    Yes this would be possible. Remember to initialize the PRs that you will be using (they must have been recorded with *any* positional data), otherwise you will get an error.

    To keep things easier for the final customer:

      9:  PR[3,3]=0;
      10:  J P[1] 100% CNT25 Offset,PR[3] ;
      11:  J P[1] 100% FINE ;
      12:  CALL FX;
      13:  J P[1] 100% CNT25 Offset,PR[3] ;
      14:  PR[3,3]=0;
      15:  J P[2] 100% CNT25 Offset,PR[3] ;
      16:  J P[2] 100% FINE ;
      17:  CALL FX;
      18:  J P[2] 100% CNT25 Offset,PR[3] ;

    That way I can write whatever I need, they can touch up the points.

    A pity because it is a super verbose solution and it makes making modifications slow, but, a small excel VBA made it a breeze to make the code.

    Thanks all for your comments.

    Probably not directly applicable to what you're trying to do, but I've found this quite useful in situations where I wanted to have an indexed "list" of teachable positions:

    The "point list" was kept in a separate subprogram, and the "main" program would call this subprogram with an argument that was the index of the P whose position I wanted. This came in really handy when I needed to run the exact same operation on multiple different racks or pallets of parts where the points needed to be hand-taught for whatever reason, but my "main" program only needed the coordinates.

    In this case, the "main" program only used PR[101], and generated approach/depart positions from it using Offsets. But with multiple racks, with each rack holding multiple parts, giving each position its own PR would have gotten really unwieldy really fast.

Advertising from our partners