Posts by flatcurve

  • User Frame Teach Probe

    I've got a KAREL program I wrote a while ago to use a touch probe to find the center of the top surface of a small locating block on a large work piece. The block is machined tool steel with a poke-yoke dowel pin pattern on the bottom. Three of them get placed on the work piece to teach a user frame. The reason they're removable is because they'd be in the way otherwise, and there's no room to machine any other type of locating feature. There are a few dozen different work pieces that get put into this system which range in size from 400mm x 400mm up to 2100mm x 1525mm and are only located in the center, which means the yaw/pitch/roll values are different each time. To run the routine all you do is give the robot the approximate position of the block, and it runs through a 9 point routine to determine the precise location of it. Once you've found three blocks, you've got your frame. We tried vision and lasers to do the locating, but at the end of the day the most repeatable process was the touch probe. I'd like to develop a standard probe and routine for all of the jobs requiring user frames but I just haven't had time to design it.

  • How to easily become a Tool Offset master to save time and impress co-workers

    I'm normally much more verbose in my offset comments for that specific reason. The reason I simply numbered these offsets in this particular program is because of how complicated the motions are. They're not simple linear offsets. Usually I'll use something like PR[20:Z -100 Tfst] to indicate a distance and that it's intended to be a tool offset.

  • How to easily become a Tool Offset master to save time and impress co-workers

    It's been a while since I've been active on this forum, but I thought I'd come back with a useful tip I've learned about using position registers as tool offsets. In the course of programming these robots, I'm sure many of you have noticed a pattern in the motion when it comes to interacting with fixtures and parts. You may have different terminology for it, but I'm sure it looks the same:
    [list type=decimal]

    • Large move to locate the end effector in the vicinity of the work

    • Moderate move to locate end effector to a "perch" position closer to the work (and sometimes wait)

    • Low speed move to actually do the work (pick, place, whatever)

    [/list]
    And then the reverse when the work is done.

    Now if you're not using offsets at all, that's at least three separate points to be taught right there. Stop doing it this way. If you use nothing else from this post, at the very least start using the Offset,PR[] motion modifier to simplify your life. But, Offset, PR[] is not what this tip is about. Today I'm talking about the Tool_Offset,PR[] motion modifier. In my experience, I have not seen this modifier used nearly as often as the regular user frame offset. This may be due to the slightly confusing requirement to re-orient yourself to the tool's frame instead of the workpiece. It may be a lack of explanation on how to use it in training and documentation. But in my experience, Tool_Offset will be a better choice to use in most situations where an average programmer would deploy just a standard Offset.

    Why? Well because of four major reasons:
    [list type=decimal]

    • Motion will always be in line with the TCP. This may seem trivial, but honestly ask yourself when the last time you had a TCP and a user frame line up perfectly when picking from a fixture. If you're pulling something out of a pocket, chances are your tool is lined up better with that pocket than the three point frame you taught. This means no dragging.

    • It works great with tracking and vision, which can't always be said of the regular offset option.

    • Similarly, tool offsets work on top of regular offsets. So for example, you could be picking from an array with known geometry. Your taught point would be the first position. The offset could be calculated for all of the other positions. You tool offsets will handle your approach, perch and work moves.

    • Lastly, there's an incredibly easy hack to set up perfect tool offsets every single time that doesn't require you to type in any numbers or make a guess at how far to move. And that's what this tip is about.

    [/list]

    Okay enough blathering. Here's the tip. Making sure that you're in the correct tool frame, teach the final point for your work piece. When I say final point, I mean teach the point where the part is fully inserted into the fixture or similar. In other words, the point where the robot will stop going forwards and begin working backwards. This is your reference point and this is the only point you'll ever have to teach or modify again after doing this. With the robot in this position do the following:
    [list type=decimal]

    • Go to your user frame settings. Find an unused user frame. (If they're all being used, temporarily store one in a position register)

    • Switch the method for teaching the frame to direct entry and then record the point as the user frame. (SHIFT + F5)

    • Switch over to that user frame and then check your position in USER. If you did it right, it should all be 0.

    • Staying in those User & Tool frames, go to your position registers.

    • Start jogging the robot out of the workspace/fixture/whatever and record each position as a new PR.

    [/list]

    And that's it. You can now switch back to your regularly scheduled user frame. Each of those recorded PRs will now work as a Tool_Offset,PR[...] to get your robot safely in and out of that fixture without a lot of touchup. You can delete the temporary user frame we created as it won't be needed in the program. (If you ever need it back, just move back to that position and repeat the above process.) Why is this a big deal? Well... an example for you: I just completed work on a job that required assembly to be done while the parts were being tracked on a moving conveyor using PickTool. Each of those assembly steps were programmed as tool offsets. This allowed me to teach the actual assembly motion while the conveyor was standing still in a completely arbitrary location. Then when it came time to run the thing I just had to touch-up PR[59] (you poor bastards who use PickTool will immediately recognize that infamous PR) and the rest of my moves came along with it. Here's how that code looks:

    Nine distinct moves and only one taught point.

    Another good example is if you have a commonly used component that requires the same motions every time you use it. My shop uses ATI tool changers with tool stands. The same tool stands every time. I know that when I lock onto the tool, I have to tilt it in the tool's Y axis slightly, and move a couple mm in the X axis to clear the stand. But I don't have to waste time thinking about it because that's a tool offset that I taught manually using my above method just once, and I've used it on every job thereafter successfully. And If your mechanical engineers like to use aluminum extrusion for tool stands instead of weldments, well I'm sorry. But hey, if you follow my advice then you'll save yourself a ton of work re-teaching them when they inevitably move around on you.

    Hope at least one person out there finds this useful. Cheers!

  • Variable used by other program

    Figured it out. You need to clear the program from memory before you try to delete the variable and re-create it. Then you can copy the file back to mdb: from another device after creating the variable:

    Code
    KCL> CLEAR PROG program Y
KCL> DELETE VAR [program]str_array Y
KCL> CREATE VAR [program]str_array: ARRAY[3] OF STRING[32]
KCL> COPY FILE MC:\program.pc TO MDB:

    You can automate this from within Karel using the KCL() built-in.

    Fun!

  • Variable used by other program

    I'm trying to delete and then create variables using KCL as follows:

    Code
    KCL> DELETE VAR [program]str_array Y
KCL> CREATE VAR [program]str_array: ARRAY[3] OF STRING[32]

    This worked the first few times I tried it. Now, no matter what I do, I get the following error when trying to delete:

    'Variable used by other program'

    To make it even worse, it doesn't matter which KAREL variable I try to delete. This is the result I get on any variable from any program. Any ideas?

  • Training

    http://robot.fanucamerica.com/support-servic…e/schedule.aspx

    They have classes in mississauga, but the schedule isn't open until May. You might be better off crossing the border and going to Detroit. Last I knew, the class prices were $1800-$2500 USD. I don't know if they offer the classes to individuals or if you have to work for a company with a robot to attend. You said you have six months experience as a programmer. Do you currently work for a company that uses FANUC robots? If so, you should know that FANUC offers free training to their integrator partners.

  • Batteries Expired - Help


    1. Put fresh batteries in with the power on.
    2. MENU -> 0 NEXT -> 6 SYSTEM -> 2 VARIABLES
    3. Find $DMR_GRP in the list. Highlight and press ENTER
    4. Highlight the motion group number that you lost batteries on. Press ENTER
    5. Look for $MASTER_COUN. Highlight it and press ENTER
    6. Write down the values. Press PREV to back out.
    7. Look for $REF_COUNT. Highlight and press ENTER
    8. Type in the values that you wrote down from the master count if they're not already in there.
    9. Press PREV to back out.
    10. Highlight $REF_DONE and press F4 to set to TRUE if not already true.
    11. Press F1 to bring up the TYPE menu. Highlight Master/Cal and press ENTER
    11b. If Master/Cal is not visible, pres PREV to close type menu, and then PREV twice again to back out to the top-level of system variables. Find and highlight $MASTER_ENB. Type 1 and press ENTER. Repeat step 11.
    12. Jog the robot to the zero-degree witness marks.
    13. Move the cursor to '3' for Quick Master. Press ENTER
    14. When prompted, press F4 for 'YES'
    15. If successful, move the cursor to '6' for Calibrate. Press ENTER
    16. When prompted, press F4 for 'YES'

    If you were within one motor rotation if zero on all axes, you'll get your master position back, and it should be pretty close. After calibration, you should see six numbers like this:

    <0.015> <-0.034> <-0.050>
    <0.009> <0.015> <-0.002>

    Those are your actual joint angles after restoring mastering data.

    In case you can't tell, I've had to walk a customer or two through this over the phone. It's our #1 service call, regardless of how much we stress the importance of regularly checking the batteries.

  • more Reference Positions

    Quote from andreic


    Strange, because I've checked in Roboguide for 7.70 software and the variable is there.

    The variable is there, and you can even edit it in roboguide using the Variable Editor. However you can't change $REFPOSMASK[...].$MAXREFPOSEN from the teach pendant on the system variables screen.

    I actually had to do this today, so I can confirm that using the TP command works though.

Advertising from our partners