Posts by SkyeFire

    All told, for this first experimental project, it will be a total of ~65,000 segments split into ~1,400 groups. Each group has from ~5 up to ~3,000 points.

    Be aware that the KRC4 has some very silly memory limits -- something like 4MB in the user-program space. This sounds like you could be at risk of hitting that limit. And sadly, the KRC does not warn you about this -- it simply becomes badly unstable and begins crashing randomly.


    To get around this, you will either need to "swap" point lists in and out via krl_fread/VarProxy/etc, as mentioned above, or buy the KUKA DirLoader option.

    I have examined MasRef_Main.SRC, MasRef_User.SRC and can't seem to find an I/O reference for the 'proximity switch status'.

    There isn't one. The MasRef switch isn't mapped to a normal I/O signal, it's wired directly into the safety module (when connected directly on X42). It is, IIRC, possible to see the individual contacts in the SafeOp signal monitor on the pendant, but I'm not aware of any system variable that would allow you to monitor them programatically.


    What are you trying to accomplish?

    As new programmer I try to understand Interrupts completely.


    I'am working on a measuring system where i have to measure multiple points on a part. thes have to be measured quite exactly so I use interrupts. Problem is that i lose a lot of time by the brake -resume commands

    BRAKE should only be used when you want the robot to physically stop at each interrupt. RESUME should only be used if you want to terminate the motion that was active when the Interrupt fired.


    You haven't really described what exactly you're trying to accomplish.


    The second section of the example program might be what you need.

    Possibly helpful: Grid/Palletizing library and example


    the simplest way to do a 3D palletizing pattern (assuming no box rotations) is to create a Base frame with it's origin at one corner of the pallet. Teach your "zero drop" position in that Base frame, usually at that same corner.


    Then, for each box, add an offset to the Base:

    So... reading the manual, and digging up some old forum posts, there's a program included with PickTool calld ADJ_OFS, which can be called to correct for XY errors caused by changes to the R rotation of the part. But I get the impression that this is intended to be used for small errors, not the 100(!)mm errors I'm seeing.


    Still, for lack of any better ideas (and Fanuc not responding to any support queries), I tried ADJ_OFS. And it worked, at least partially -- I was able to get the part to pick successfully at R values near 0, or near 180. I'm still well off location for R values near +/-90, but I may be able to fix that by playing with ADJ_OFS more -- so far, I've only added an X offset to ADJ_OFS, no Y offset.


    So... fixed? Maybe? 100mm still seems huge, but this is the best I've been able to achieve so far.

    Well, I finally got a chance to explicitly test this out. And PickTool appears to save the position for a Fixed Station, despite not having any explicit setting in the PickTool configuration page.


    So, this is what a Conveyor Station looks like in PickTool:


    The Set Ref Pos button opens a page that allows you to set and save the Pick (or Dop, if you're dropping to a Conveyor) explicitly. But for a Fixed Station (the Drop station, in my case), there is no such button. The only way (that I've found so far) to set the FS position is to manually TouchUp the PR in the Drop program (in my case, PR[63] in the program PK_FS_DROP11).


    What I've found is, when I TouchUp the PR with different PickTool Recipes active, and save the Recipe, the PR value gets saved into one of the XML files that defines the Recipe. And Activating a different Recipe loads the value from the XML file into the PR.


    In my case, for a Fixed Station, the Recipe saves the PR value to IRPKFSTN01.XML, like so:

    <ref_pos X="339.35" Y="-553.97" Z="-139.41" W="179.96" P=".02" R="-6.29" cfg="N U T, 0, 0, 0"></ref_pos>


    Running a comparison between this file in different Recipe directories (which you can obtain by using the Export Recipe action in the PickTool setup page) shows a different ref_pos value for each recipe, and on the pendant, I can see the value of PR[63] change when I manually Activate different Recipes from the setup page. And I've done run tests with the different parts to confirm that, yes, PickTool does keep the separate positions on a per-recipe basis.


    So, hopefully this will be useful to anyone who experiences the same confusion I did.

    1. Type: category 0

    So, an E-Stop stop, not a programmed stop.


    No, there's no "generic" formula for this. You essentially need a physics simulation, or a mechanical designer who can determine the stopping distance. For example, a Stop 0 slams the motor brakes shut, but if that destroys the drive shaft between the motor and the shuttle, then the shuttle will just drift to a stop.


    You may have to use SafeOperation to limit the speed of the shuttle to something manageable.


    If the robot's carried payload changes, that will also potentially effect the shuttle stopping distance.

    You don't need to change $EX_KIN. It's the Async configuration mode. Setting that either makes $EX_KIN relevant, or makes ASYPTP possible. Never both at the same time.


    Look up $EX_AX_ASYNC.

    Is it an LR-Mate? I once had this happen when the main power into the controller was missing a phase. IIRC, every time I squeezed the deadman, the fuse for the power to the robot's RO outputs would blow. There weren't any other error indications, which made it a real pain to track down.

    Addendum: I collected some more test data.


    With the part pointing "forwards" -- that is, close to the Reference orientation -- the VR[1] Found Pos has values of X -151, Y 16, and R 0.1. But the VR[1] *Offset* is X -44, Y 23, and R 2.0.


    With the part "backwards" (roughly 180deg in R), VR[1] Found Pos is X -190, Y 20, R -173, with an Offset value of X -295, Y 1, R -171


    So I tried forcing the part into +90 and -90 rotations, which would normally not occur in production.

    For a Found Pos of X -240, Y -3,R -89, the Offset becomes X -231, Y -109(!), R -87.

    For a Found Pos of X -199, Y 10, R 92, the Offset becomes X -211, Y 117, R 94.


    So, the Found Pos values line up well with the physical location of the part -- the R values are right about where I would expect them to be, after manually rotating the part. The Offset R values are also pretty close (there seems to be a consistent 2deg difference), but the X and Y values are way off where they should be.


    This suggests to me that the Found Pos offsets are being applied in/around the wrong Frame, somehow. My best guess, looking at these numbers, is that the R rotation is being applied, not around the centroid/Origin of the part, but around a point roughly X-100 from the part's actual location. The robot picks the part correctly in the "Forward" orientation simply b/c that's the orientation I taught the Pick Ref Pos in.


    I'm still at a loss as to what could cause this, though. I've re-done the TrakFrame and Vision Cal from scratch multiple times, following the steps in the manual.

    Forgot to add this: Digital outputs do not work until this error goes away

    Of course not -- those outputs are linked to DeviceNet, so they won't work when the driver is not operating.


    The DND message should include details as to which device has stopped communicating. Have you checked that device?

    Just when I thought I was getting the hang of PickTool....


    This is what I have happening: I've set up my TrakFrame and Vision such that the robot picks the part without any issue when it's in a rotation similar to the Reference Position. The robot tracks the part on the moving conveyor belt very well.


    However... this part comes down the line rotated around Z, either between -20 and +20, or between +160 and +200 (or, I suppose, between +160 and -160 the way irVision measures rotation). And if the part comes down the line "backwards", the UTool rotates to what looks like the correct orientation (relative to the part), but it's well off location along the X axis of the TrakFrame. The actual "tracking" motion is still correct however, following the motion of the conveyor.


    Looking at the values in VR[1], when the part is pointing "forwards" (that is, the -20 to +20 of the Ref Pos), I'm getting X values in the range of -50. But when the part is "backwards" (between +160 and +200), the X value jumps up to the -300 range. I think this must be the root of the problem, but I've got no idea what's causing it. The R and Y values in VR[1] look to be pretty reasonable, relative to the actual part position.


    I've checked my UTool, and it's correct. And it's not a matter of the robot selecting the wrong UTool -- My Gripper has a large Y+ offset, but all my other UTools are 0'd, and the robot reaches far past where it should if one of the 0-Tools was active.


    The irVision reference frame and the conveyor TrakFrame are aligned with each other to within 1deg, so I don't think that can be the issue.


    My Pick Offset has only a Z value, everything else is 0, and the Approach/Retreat motions are correct relative to the Pick position. I'm not seeing any signs that any of the Frames are being flipped or inverted -- even when the robot goes much too far in X, its motions in Y, Z, and R appear correct.


    My "Origin" in the irVision GPM tool is on the center of the part, so that should not throw the Pick position off in X the way I'm seeing.


    So far, I've tried re-creating the entire PickTool recipe and irVision task completely from scratch 3 times, and I keep ending up with this same issue. I'm obviously missing something small but critical, but I cannot figure out what.

    Can you VM clone one of your working junkers to an external HD, then try running that from your colleague's machine - would possibly prove/disprove the physical hardware aspect.

    Trying a VM is on the to-do list, but we're getting bulldozed by schedule pressure here.

    Is there any trusted computing settings turned on in his bios that is not turned on in yours?

    Hard to say. There's been no time to try going through the BIOS settings line-by-line, and the two computers are such different make&models that I'm not sure an apples-to-apples comparison is possible.

    Well, turns out I was suffering from a temporary brain failure. Once I dialed the Score threshold down far enough, I started getting Almost and Actual finds. D'oh!

    Do you need the GPM tool? When ever I have used circle finder it is by itself, not as a child to the GPM. If you need the GPM maybe just temporarily move Circle finder up a level so it isn't a "child", do the trouble shooting, make adjustments, then make it the "child" again.

    So, that seems to be unavailable. Under "regular" irVision, I've been able to use the CF as a "top" tool. But under the 2D Line-Tracking type task, the only "top" level tools available are Blob and GPM. Most of the other tools are greyed out except as "child "tools to the Blob or GPM.