FRAME in AS language

    Hi guys,

    a silly question about FRAME function.

    I understand how to create a FRAME from the AS manual, what I want to clear up is the best way to do it.

    Imagine that I create the frame: POINT user_frame1 = FRAME(org1,x1,y1,org1) and imagine that org1,x1 and y1 are created with TOOL t1.

    What happens if I change the tool t1? Is the user_frame1 different? All the position will be altered?

    Basically is better having a specified tool for creating a frame (that will be never changed) or a NULL tool?

    Thanks in advance

  • Go to Best Answer

    That's an excellent question...………:top:

    The FRAME is always an easy one to visualise, but in the Kawasaki AS Language, can open up a very complex discussion which can include lots of spiel...….

    I have rewritten my reply a couple of times today, as I have ended up spiralling around with my reply.

    Hopefully, this revised response will help.

    Quote

    Imagine that I create the frame: POINT user_frame1 = FRAME(org1,x1,y1,org1) and imagine that org1,x1 and y1 are created with TOOL t1.

    What happens if I change the tool t1? Is the user_frame1 different? All the position will be altered?

    Basically is better having a specified tool for creating a frame (that will be never changed) or a NULL tool?

    The FRAME command produces a result based on the calculation of the values used in the command.

    The result will not be influenced by ANY BASE or TOOL values, plain and simple.

    Try it, change the BASE or TOOL values, then execute the FRAME command again and list the location values each time, you will see the frame location values do not change.

    I always recommend when frame creating, to always use BASE NULL and a dedicated accurate machined tool that resembles your actual tool and tool values and if possible, a dedicated jig or dowel pins you can attach/remove to the peripheral to make it a little easier.

    What is important when you are creating the intended FRAME location values are:

    - Tool TCP is accurate.

    - BASE is fixed and correct during teaching of o1,x1,y1 and is correct if tickling them afterwards.

    - Do not worry about Tool orientation, concentrate on the accuracy of the locations.

    - Specifically Z values, differences between o1,x1,y1 will impose a plane orientation on the FRAME calculation.

    - Remember you are actually creating a 2 dimensional plane.

    - The Z axis is imposed using the ordering of the x1 and y1 in the FRAME command. (left hand rule).

    Remember the FRAME ignores the OAT values of the reference/element locations used.

    So, needless to say, you could teach the elements o1,x1,y1 in ANY orientation you like and also for smarts (I have never tried it), you could use different tool values to teach these elements too, just as long as the TCP is at the required XYZ location.

    In other words:

    1st and 2nd element set the X+ direction in relation from 1st to 2nd element (o1,x1)

    1st, 2nd and 3rd element then set the X-Y Plane (where the 3rd element predominantly is the Y+ direction (o1,x1,y1)

    The 4th element is where your intended origin of those vectors is to be placed at (o1,x1,y1,o1)

    After it has been calculated, the created FRAME location can be utilised just like any other transform.

    Therefore by using it with the BASE command, you could set the BASE to the frame location.

    BASE user_frame

    JMOVE posa

    By executing the BASE command and then POS MODDING the posa step, will result in transform values referenced to the BASE.

    Only problem with this, if you are using multiple frames, then you must make sure the correct BASE is used/executed prior to teaching a reference location and also to move to it.

    Alternatively, you could use the compound method (I prefer this method) by keeping the BASE NULL

    BASE NULL

    JMOVE user_frame+posa

    With this method just POS MODDING the step results in posa values being taught reference the FRAME location.

    If you are using multiple frames, there's no ambiguity with BASES, it is always NULL.

    The downside to this method is posa is not a location you move to, you will always need the FRAME location applied in the compound.

    Hi kwakisaki,

    of course thanks for you comment and for the time, you're always on top.

    Back to your post, about the first part: it works the same way of other robot FRAME instructions and I found it very comfortable coz I always use a procedure very similar to the one that you've described. What I would like to understand is this situation.

    Quote from kwakisaki

    Remember the FRAME ignores the OAT values of the reference/element locations used.

    So, needless to say, you could teach the elements o1,x1,y1 in ANY orientation you like and also for smarts (I have never tried it), you could use different tool values to teach these elements too, just as long as the TCP is at the required XYZ location.

    1. BASE Null, Tool t1= 0,0,100,0,0,0. Moving the robot I can create the 3 points that I need (org1,x1 and y1) so I can build the user_frame1.

    Then I create the job in BASE user_frame1.

    Then I "recalibrate" my t1=0,0,200,0,0,0 but I physically don't recreate the 3 points for the frame(I don't move the robot to the 3 points).

    Now with this operation I've shifted the frame1: so the points in the job all are moved to 100 mm in z direction?

    Hmmmm….not too sure what you're referring to here.

    1. BASE Null, Tool t1= 0,0,100,0,0,0. Moving the robot I can create the 3 points that I need (org1,x1 and y1) so I can build the user_frame1.

    Yes, straight forward...……

    Then I create the job in BASE user_frame1.

    Again, straight forward...….

    Then I "recalibrate" my t1=0,0,200,0,0,0 but I physically don't recreate the 3 points for the frame(I don't move the robot to the 3 points).

    Yes, straight forward...………

    Now with this operation I've shifted the frame1: so the points in the job all are moved to 100 mm in z direction?

    No, neither the BASE user_frame1 or org1,x1,y1 points should move/shift.

    Those values remain the same......The new TCP is offset against those values to compensate.

    What you have 'shifted' is made the Tool longer, and in that respect, the robot should move the TCP to the same points, what will happen, is the robot (minus the physical tool) will visually appear higher up, an increase by 100mm.

    But your TCP should still be at the same locations.

    Attached is exactly what you have written (as I am understanding it)…...so can you elaborate a bit more?

    Perfect.

    Now is clear the frame remains in its position regardless the TCP.

    As you write before:

    Quote from kwakisaki

    Only problem with this, if you are using multiple frames, then you must make sure the correct BASE is used/executed prior to teaching a reference location and also to move to it.

    That also means that if I want to physycally modify the points of my user_frame1, first of all I must be in BASE Null(of course I imagine to create it in this condition).

    Because as the video shows if I go to o1,x1 and y1 in BASE user_frame1 they are referenced to BASE user_frame1 and so "shifted".

    Quote

    That also means that if I want to physycally modify the points of my user_frame1, first of all I must be in BASE Null(of course I imagine to create it in this condition).

    Exactly...…………:top:

    Quote

    Because as the video shows if I go to o1,x1 and y1 in BASE user_frame1 they are referenced to BASE user_frame1 and so "shifted".

    Yes, but careful with terminology.....I understand what you mean.

    Values still remain the same, it is because of new BASE values, o1,x1,y1 appear to have shifted...:top:

    This is the most common problem with using FRAME location as BASE reference.

    Operators jump in and out of programs direct to motion steps to modify them without first executing the correct BASE command.

    Then they re-teach position with incorrect BASE, and creates many problems.

    I always refer to the FRAME command as a command that can literally 'turn your world upside down' if not utilized correctly...…:top:

    • Best Answer

    OK at the end just to give a contribution..I've created this job that allows to change a user frame "safely"(I think:thinking_face:),I've done a couple of test..... it seems good:

    Edited once, last by Motouser (January 30, 2020 at 2:10 PM).

    Yep looks good, easy to follow and uploads fine.

    As Alexandru correctly points out, the ANY does require an additional 'space' after it.

    I assume this is a subroutine as opposed to a standalone program with you using parameters in step 0?

    I only mention this, as the local variables used will be undefined otherwise.

    In addition to this don't whether this would over complicate matters but:

    You could change your user_frame variable to an array so that the .n_frame value relates to your frame no. in your CASE statement.

    You would need to change this in your all of your routines after though, but would remove the repetitive code in the CASE statement.

    CASE .n_frame OF

    VALUE 1,2,3,4,5,6,7,8 :

    POINT user_frame[.n_frame] = FRAME(org,x,y,org)

    BASE user_frame[.n_frame]

    ANY :

    ; print error

    END

    However, I do prefer a good CASE statement that's sequential and easy to follow, so your version gets a thumbs up from me......Nice work......:top:

Advertising from our partners