Posts by Mentat

    If I understood you correctly, then you want to do translation and scaling. Changing base/tool coordinates by offset can only perform translation (hence the "whole contour is displaced").

    I suppose you could find the center of the part and translate all the points towards it.

    From KRL side of things, I suggest looking up structs (and using them to group parameters), enums instead of booleans (because you will want more than two values) and switch cases instead of If sequences ( because I lose a bit of sanity every time I have to fix someone else's code and see those existing for no good reason).


    But if you want to save your sanity, don't try to do anything, but the most basic stuff with KRL. It's not a good tool for complex things. If you must have dynamically created code, create it externally and use something like Directory loader.


    I would like to know about the Variable Path CIRC command behavior, specifically, if this type of CIRC omits or not, part of the rotation components in order to get to the final orientation.

    I will try to express it better: in the manual images (attached) for this type of CIRC it seems that the tool rotates in the axis normal to the plane that contains the circle (as the constant path CIRC does) and also that it rotates in the axis tangential to the circle in each point along with the move, but (this is my duobt) it seems that no rotation is made in the radial axis... in other words if the rotation in the radial axis is omitted the move won't reach to the orientation of the final point of CIRC command definition...


    I hope I have expressed myself correctly... Thank you for your answers !! :winking_face:


    Const path keeps the same angle between arc starting position orientation and tangent vectors throughout the motion, so yeah, it kinda ignores rotation components of intermediate and end positions.

    $pos_int is read only variable. I suggest saving the $pos_int value in the interrupt function to another pos/frame variable and using that.


    As for seeing variable values- Monitor->Variable->SIngle

    like it doesn't exist in the program.

    Exactly that.

    A semicolon in KRL denotes a comment. ";FOLD" ...;Endfold allows to create named envelopes for code sections, thus allowing to describe what that code section does (and to minimize the amount of screen estate they use when you close it). Still, everything in the line after a semicolon is considered a comment (unless you have it as a char value). So you can write

    Code
    ;fold Make me a god emperor of the universe, sans the bureaucracy
    ;endfold

    and it will compile it, but won't execute those lines ( I tried).


    I suggest spending half a day reading the expert programing manual, as I suspect you are trying to write KRL without in line forms, but in the same style.

    The code could use indentation. Don't bother to read the thread titled "READ FIRST".

    In the future, don't describe your problem as "it doesn't work", because that description is too verbose and provides way too many details. Don't even mention what you expect or want to happen and what is actually happening. Let other people try and guess, we enjoy it.


    Code
    ;FOLD PTP VisorPose[1,1] Vel=100% ;
       ;ENDFOLD

    This is a titled fold, I wouldn't have one just empty like that, but to each their own :smiling_face:

    If I understood correctly, you have a turntable with a base at it's axis of rotation. You want to calculate the the new base, depending on the turn angle of the table. That's easy:


    Assuming table's axis of rotation is base's Z axis/ angle A (and they rotate in the same direction)


    CorFrame = $Nullframe

    CorFrame.A = TurnAngle

    NewBase = TableBase : CorFrame


    If they don't rotate in the same direction, just put minus before TurnAngle

    Hello, it would be helpful if you could post the controller and KSS versions.

    If this is a newer controller, the orientation change might be as simple as changing $robroot to Nullframe.


    As for milling with a used robot, depending on wear, you might need to remove material without hard change in direction (no 180 degrees turnaround on the spot) as gear backlash will momentarily mess up positioning.


    However you are going to generate milling code, make sure it avoids singularities.

    Of course you can change frames that are used later to calculate kinematics- that doesn't change what the robot is currently doing, only what it will.


    If the speed is constant (even if only for one cycle) and you know the coordinates of the target, then instead of base you can just change trajectory. It would mean keeping the trajectory in pos arrays which won't work well if the poses have to be taught manually.

    Apart from advance pointer making any changes irrelevant (at that moment) for the preplanned motions, the controller can't execute any commands that have any influence on robot kinematics by non-robot interpreter. E.g. no lin, ptp motions, active base or tool changes.


    If the conveyor speed is constant or can be measured/calculated, then do you really need a rapid adaptation by the robot?

    I guess none :grinning_squinting_face: You just find that $Workspace is a system variable and from there figure out where it's declared, what type it is and what it's consituent parts mean. If anyone tried to put everything there is to know about programming in KRL, it would be a lot bigger manual :smiling_face:

    Thanks

    I read thru the expert programming manual, but I cannot see any reference on how to set it up programmatically as you suggested. Is the syntax similar to setting up a $BASE ?

    Yeah, just instead of Frame it's of a type Box. All cartesian workspaces are already initialized in STEU/MADA/Custom.dat:


    $WORKSPACE[1]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0,X1 0.0,Y1 0.0,Z1 0.0,X2 0.0,Y2 0.0,Z2 0.0,MODE #OFF}

    If you have something like Workspace.Mode = #inside then in sps or some other non-robot thread you can run a procedure that does


    If Workspace.State and $in[ChDI_IncomingFire] and RunningThisForTheFirstTimeFlag then

    EngageDefProtocols()

    endif


    Just continuously check.

    Well, I direct you to expert programming manual :smiling_face:


    Been a while since I worked on KRC2, so not sure why the option is greyed out if you are logged in as an expert at least. You can just ignore it and set it up programmatically.


    Creating a small workspace and using it's state in a condition is ok if you only want the location of the TCP (XYZ coordinates). If you want certain/similar position (XYZABC) then you will need to also check angles with axis angle or quaternion.


    It's not clear what it is you are trying to do, but if this position is on a path, then maybe just use a trigger?

    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