Posts by Nation

    I use a .cm file to setup reference positions for touch up on new installs.

    I got a quote from Fanuc for the DCS manual last year for $110. To give you an idea on price of manuals, per.


    Seeing as how the latest Fanuc manual CD has 68 manuals on it, it would be quite a bit to purchase each one individually.

    Not any known way. There was a guy on the forum a few years ago claiming he made a decompiler, but never provided any proof.

    Keep in mind that the Wjnt motion option only affects the wrist ("wrist joint," axes 4-5-6).


    Linear + Wjnt should work for a config change between NUT/FUT and vice-versa since you are only changing the wrist configuration, but I would expect to see a fault if you change the elbow/arm config.


    Edit: Also keep in mind that the other robot axes will have to compensate for the joint interpolation of the wrist to maintain a linear path when using Wjnt. In general, if you don't need the TCP to move in a straight line, it's probably better to just use a joint move.

    I decided to try a change from NUT to NDT using a linear move and wrist joint, and wow, it behaves oddly.


    The controller (V8.30/23 in my test) does not fault, it actually executes the move, and gets the TCP to the XYZ position of the point, but does not match the WPR of the point. This was done using a fine move.


    Worse yet, is that once you are there, if you attempt to jog away, the controller then decides to execute the rest of the move! :fearful_face:


    Moral of the story, don't use wrist joint for altering configs of the major axes of the arm.

    I see, so basicly I will use one additional register in this case PR[100] which will have all of the offsets kept in it and through the offset option it will move the robot to the correct spot, but not change the original points 30, 31, 32, so I only need to recalculate X,Y,Z for PR[100], do I understand this correctly?

    Yep, you got it.

    I would recommend using an offset position register for this. That way you are not modifying your original pick location, and thus, no need to restore it.

    Code
    : PR[100]=LPOS ; --Cartesion rep.
    : PR[100]=PR[100]-PR[100] ; --Zero the PR.
    : FOR R[7:XCount] = 1 TO 5 ;
    : PR[100,1]=R[7:XCount] * R[1:dX] ; --Set the X distance ;
    : L PR[30:ApproachPoint] 100mm/sec FINE Offset,PR[100:Offset]    ;
    : L PR[31:PickupPoint] 100mm/sec FINE Offset,PR[100:Offset]    ;
    : L PR[32:RetrievePoint] 100mm/sec FINE Offset,PR[100:Offset]    ;
    : ENDFOR ;


    For expanding this to Y and Z, you would just need additional FOR loops.


    Example:

    This should do what you are looking for. I figured out the TP2_Panel command from the documentation FORCE_LINK in the Karel reference manual.

    Nation: I took a look to your app. I understand the math, but can not see how you get the vector position and orientation from the base of the robot (workobj0->ABB, UFRAME[0]->Fanuc, BASE[0]->KUKA) unto the vehicle origin reference.

    Ah, I thought you were asking about specifically changing frames quickly. I missed the initial part. On Fanucs there is no built in way to get a car into body space easily. On jobs I've worked on where this is done, we would laser shoot the robot into the body space frame, typically by running the robot through at least 30 points to up to 100 points in the body space. They are metrology systems, so that many points was required. The metrology software would then fit the robot into body space with the positions provided by the laser tracker, and then generate a userframe you would then type into the robot.


    Before the metrology software did this though, they used an excel spreadsheet that would best fit the points, and then generate a frame.

    If you are using Fanuc Robots, I built a tool specifically for this situation. Check my sig. The gist of the tool is to convert the path to joint, update the frame and convert back.


    Most robots nowadays have built in conversion packages allowing you to convert from one frame to another.

    Did this robot have an insulated flange that someone removed? Those are about 20mm thick, and the robot's J6 origin is set at the flange face.


    Edit: After screwing around in Roboguide, I was only able to get the UT0 point to move by 8mm, by switching from normal flange to ISO flange. There isn't an option to change to an insulated flange in controlled start. I was using handling pro though, maybe it is an option in ArcPro.


    I encountered something like this on an install using old robots where someone had removed the insulated flange, but never 'told' the robot about it.

    How does that work? I'm not sure we're using the same terminology here -- I know that when I'm programming a Fanuc vs a KUKA, and using my hand to work out what angles I need to use, I have to rotate in completely different sequences.

    Its a property of extrinsic (always rotating about world frame) vs intrinsic (rotating about the frame created from the previous rotation (the ' and '' notations)) Euler rotations.


    To quote the wiki article on it:

    Any extrinsic rotation is equivalent to an intrinsic rotation by the same angles but with inverted order of elemental rotations, and vice versa. For instance, the intrinsic rotations x-y’-z″ by angles α, β, γ are equivalent to the extrinsic rotations z-y-x by angles γ, β, α.

    R30iA was the first controller to have DCS, which allows for smaller cells. The RJ3iB was limited to using hardstops to reducing robot work envelope.

    It also allows for longer than 8 character names for programs (only took fanuc until 2007 to do something that had been done 20+ years earlier with computers :face_with_rolling_eyes:).

    Also string registers were added on this controller gen.

    Since most Fanuc arms are spherical wrists, the inverse kinematics become a bit simpler. Look up kinematic decoupling if you would like to read more.


    The thousand foot view of how it works is that you use the wrist center point to solve for the major axes, and then you use the WPR of the point to fine the minor axes.


    How my conversion utility works:

    1. Convert point to matrix representation. Fanucs are world Rz*Ry*Rx, so you can use that to get back to matrix rep.
    2. Take the point and matrix multiply it by the inverse of the TCP to get back to the Faceplate.
    3. Then times that by the inverse of the wrist center point to the faceplate to get back to the wrist center.
    4. Once the wrist center point is found, check for reachability, and if reachable, solve J1, J2, and J3.
    5. Now solve for J4, J5, and J6.

    Yep that is the matrix form of a PR.


    You need to the $PRCARTREP to true to get the controller to not set PRs as matrix rep.


    That particular PR you would have to store to another PR and then back to get it to cart rep.

Advertising from our partners