Questions about AS features by KRL programmer

    Hello, so far I have worked with KUKA robots. Today I skimmed through this section of the forum, read the AS programming manual and now have some beginner questions. If I write something as a statement about AS and I am wrong, do correct me, please.

    To begin with- there is a question of whether it's feasible to rewrite a project we've already done with KUKA, to Kawasaki AS. I had a glimmer of hope that I could just write KRL code in AS syntax, but I see that won't work- AS is way different :smiling_face:

    The controller would most likely be E series.

    From my experience with KUKA, the manuals are correct, but incomplete- not all system variables and functions/procedures are mentioned. I suspect it may be similar with AS manuals, hence:

    1. Are there any procedures to calculate inverse kinematics (joint angles/positions from XYZOAT and Joint angles). How about a DLL for doing it externally? I am aware of INRANGE() procedure, hoping for more.

    2. Maybe I didn't notice, but how many interrupts max can be declared/started at the same time?

    3. AS evaluates non motion commands until the next motion/IO command. But for approximated motion, it should evaluate some of the motion commands after the current one? Does it and how many? (in KRL this is called Advance pointer if it means anything to you)

    4. I saw it mentioned that C controllers can have up to 3 process control threads, how many for E?

    5. From the lack of mentions and from the way variables don't need declaration, am I right to assume variable structures don't exist in AS? Looks like XYZAOT and JT1-JT6 are special cases. That seems a bit inconvenient; did you just learn to do without grouping values or found a different way to do it? Is everyone in Kawasaki really into lambda calculus? :grinning_squinting_face:

    6. Enumeration is probably replaced with strings?

    7. If I understood correctly, NLOAD/SLOAD can be used to programmatically download and execute programs from external storage devices?

    8. Do E series controllers still have 8MB of working memory?

    9. Are there any computational geometry procedures/libraries by default from Kawasaki or around the forum? I saw DISTANCE and CCENTER, is that the extent?

    10. Is there spline motion capability? I don't mean the approximated motion.

    11. What's the max depth on function nesting/recursion?

    12. I am sure capability to call procedures by string value (something not available in KRL) is immensely useful. Do you have any no obvious uses for it?

    • Best Answer

    I wouldn't consider any of your questions fall into the 'beginner' bracket if you are experienced with other industrial robot vendors.

    The majority of these could be answered using KROSET OLP, if you are going to work with Kawasaki, I would recommend obtaining this.

    As for straight forward conversion the closet to Kawasaki is Staubli - Both are based on VAL (Staubli more).

    Kawasaki IMHO is way more basic than Kuka from a programming perspective from what I've seen (WYSIWYG).

    1. What other ones would you like?

    2. No mention in the manual suggests there is no limit, I've just run a quick test on 10 which appeared fine.

    3. Not sure, maybe 2 - 3, would suggest to contact Kawasaki for a specific answer.

    4. 5 PC Processes simultaneously, there are 8 available to use (2 are option based).

    5. All variables require declaring prior to use, global or local.

    6. Provide an example?

    7. Yes, you can load from external device, but I think only programs can be executed in the controller or commands sent via external device using KRCCDLL

    8. Yes.

    9. What other ones would you like?

    10. Not that I'm aware of, would suggest to contact Kawasaki for a specific answer.

    11. Again, something to ask Kawasaki, I personally do not overcomplicate programming for customers to understand so would not really now - at least 8!

    12. By using TCPIP for program selections or other message transferring tasks.

    Thank you for taking the time and effort. Just about to install k-roset trial, another thanks for that!

    I am just beginning to delve into Kawasaki and I had some questions, but maybe that didn't make those beginner questions- sorry.

    1. It would be useful to have a procedure that could calculate the joint angles for a position expressed in XYZAOT (with either current tool/base or those given as additional parameters) with starting joint angles (to get Joint angles that are closest to starting configuration as several configurations may be possible to get to the same pose).

    Forward kinematics (provide joint angles and get where joints and tcp end up), but naive version of this can be done easily just using transformations.

    I found out that there is an optional module for kinematics, so that would likely solve it. It's very useful when making a procedure to get TCP home from anywhere in the cell or making a crude motion planner.

    2. 10 Interrupts is enough :smiling_face:

    5. But does the syntax allow to group a bunch of variables under the same name? E.g. struc Box Pose Start, real height, width, length; then accessing parts of it by Box.width = 36.2

    6. Enumerators are kind of like a variable type- similar to boolean, but instead of True or False, you can have arbitrary number of predefined values. I find useful to represent a states, errors, or unique conditions. They can be used in case sentence, witch is much easier to read than a bunch of if statements. Even more useful when they can be part of a structure :

    enum InvState Idle, Trip, Off, On

    struc Inverter int ID, InvState State

    then in program:

    case Inverter.state of

    Value Idle

    call someproc()

    Value Off

    call otherproc(0

    end

    I assume you just use SCASE and are really careful to keep the Strings unique :smiling_face:

    7. So it's more for loading data, instead of code.

    9. There is a quite a bit:

    Arc length,

    Circle intersection points,

    (spherical) linear interpolations,

    point on line segment closest to point,

    best fit line

    transformation between pose, transformation matrix, quaternion, axis angle

    Simple vector functions: Dot, cross products of vectors, min angle between them, etc

    It's all simple stuff, it would just be silly of me to write this if it's readily available :smiling_face:

    1. By use of POINT command directly forward and inverse is simply done:

    - POINT test_trans = #test_jt_angs

    - POINT #new_ang = HERE (Current TCP to angles)

    - POINT #new_ang = HERE+TRANS(x,y,z,o,a,t)

    - POINT #test_jt_angs = test_trans,#ref_posture

    - POINT new_trans = #HERE (Current angles to TCP)

    - LEFTY/RIGHTY/BELOW/ABOVE/UWRIST/DWRIST Changes Jt angle configuration to represent differing postures (section 11.7 in AS manual as reference).

    - TRANS provides direct entry of transformation

    - #PPOINT provides direct entry of joint angles.

    - Order of rotational is always O (rz) followed by A (ry), followed by T (rz).

    - In AS only 1 Tool and 1 Base is referenced (held within memory - values only), you need to use variables to access data as part of a compound instruction.

    - Cannot use Joint angles in any compound instruction - you would use #PPOINT in most cases

    5. Only way I am aware of is by use of array and elements/index value

    - Upto 3 dimensions can be used.

    - They used to limit max no. of array elements to 9999, but suspect this is higher now.

    - Of course using many array elements ie for machining is limited by usable memory available

    - I am under the impression machining maybe on one of your agenda's.

    6. I don't believe so.

    - Only form I can think of is by way of array and elements and using index variable to create.

    - Like in your case statement, the array index variable used as the CASE OF value

    7. Yes, just loading from what I know, in order to execute single commands (not in program) requires DO command prefix.

    - So you could use KRCC DLL to send single DO commands, but these would be point to point and not continuous.

    9. Majority of those would require hard coding in by using various iterations.

    - 3 points are used for circular command to calculate circle C1 and C2 move.

    AS is very flexible, and the manual suggests these are all single step commands, however they can be combined.

    In cases where you are returning values, you can combine those with other AS iterations for motion planning.

    Such as:

    POINT drp1[pall.no,lay.no,drp.no] = SHIFT(mas_bx_drop[1,1,1] BY 1*(-bx.lgt),stg*(bx.wth),(card.hgt+(lay.no-1)*(bx.hgt)))

    POINT #app_drp1 = SHIFT(drp1[pall.no,lay.no,drp.no] BY 50,50,(bx.hgt+20)),#mas_bx_drop[1,1,1]

    JMOVE #app_drp1;Approach

    LMOVE drp1[pall.no,lay.no,drp.no]; 1st drop

    ** when using KROSET or Real Controller **

    If using the built in editor to create/modify programs, there is a limit per characters per step you can enter (I think max 128 characters).

    So if longer, you are better creating offline in text file and loading in.

    1. Surprise operator overloading! :grinning_squinting_face: So simple I wouldn't have thought to try.

    I assume: POINT #new_ang = HERE+TRANS(x,y,z,o,a,t) would just throw an error and stop execution if inverse kinematics solution is impossible (outside work envelope, violating joint limits)?

    5. Yes, what I do falls under purview of machining and pick&place. Also I am quite lazy and try to write parametric/reusable code, so any abstractions I can get hold of are useful.

    9. Oh yeah, I program offline 99% of the time. Pendant I use for calibration and for program selection :smiling_face:


    Thank you again.

    1. Yes, upon execution of the either a processing step or a motion command you would receive a 'destination is out of motion range error'.

    - LMOVE HERE+TRANS(10000,20000,5000) if XYZ values created a joint angle out of it's mechanical limits.

    - LMOVE #PPOINT (1,2,3,4,5,6) if any joint values entered are out of it's mechanical limits.

    5. I don't provide any code unless I'm paid to write it, but will offer some examples on the forum.

    9. I can tell, this is why KROSET should come in very handy.........:top:

    Quote from Alexandru

    What kind of application are you working with the robot?

    Not yet working on any Kawasaki robots, but the cell that's implemented with Kuka and we are thinking of replicating with Kawasaki is basically a plotter producing custom paper packaging boxes. Not useful if you need thousand or more of the same box, but if you need a couple or couple hundred then it's kind of great- no need for humans except for loading pallets of fresh sheets and removing produce every 8 hours or so. Cut my teeth on rigid transformations and kinematics with this one.

Advertising from our partners