Posts by Nation

    This screams to me "mechanical screw-up, make controls fix it".

    It sounds like you need to master your jigs (make them all the same) and/or the pallets carrying the jigs. Also, as Atticabob stated, how repeatable is the method you use to locate the jigs? In my experience the best method is to set the pallet carrying the jig down on a 2 way and 4 way locator.

    Hi Greg,

    I would set up user frames for each jig... If the number of jigs exceeds 10 I would simply put the frame data into PR's then pull it into the frame as needed... You could use PNS to call a specific program that holds jig number / frame number/ product number... Does the system get a BCD type input to know what fixture is in it?
    With things varying slightly... How well does the conveyor repeat position?

    On the newer controllers (R30iA and up, not sure about older), you can increase the number of user frames by manipulating the $SCR.$maxnumufram system variable. I've taken it as high as 64 frames before.

    Your program gets the old data because you are not waiting for the vision process to complete, thus running old offsets. Its like firing a gun without aiming it. Likely into your own foot.

    You need to interlock the two programs together. This can be done with a flag bit or a register.

    I've modified your programs to include an interlock. Take out all those timers, every time I see this in the field it means that there is spaghetti code ahead.

    Also, your program now has no way of failing gracefully if the vision can't find anything. I'll leave adding that as an exercise to the user.

    1st (main) program.

    Your second program.

    I'm curious as to how this DCS input/output system is considered "dual channel" when all I need is 1 opsfty input to enable or disable a zone, and also can link 1 zone to 1 output? This is not dual channel. Unless I am missing something.

    Sup three year old thread.

    See the image below.

    A1 and B1 are the inputs for a single safety input (OPSFTY1 in this case). Its dual channel since two inputs need to change state within 200ms of each other in order to actuate the input without generating a chain fault. It functions the same way the fence circuit does, or the external estop circuit.

    You can have a safe output on pins A5 and B5. When ESPDO1 is turned on, both A5 and B5 will source 24V. It is up to the user to supply hardware that checks for dual channel functionality (like a safety relay).

    Well I was unable to determine the syntax.

    I ended up doing in Karel, as much as I didn't want to.

    Here's the code (stripped down a bit):

    Pulling from a system parameter isn't even an option if I don't use mixed logic.

    If I point the PR at a number, or a bool, it works fine.


    !No invalid parameter name message. ;
    PR[98,1]=($LNSCH[1].$TRK_GRP_NUM) ;

    However, I can't figure out how to access a sub component of a position. It always says invalid parameter name.

    Stuff I have tried so far (all invalid parameter names.):

    PR[98,1]=($LNSCH[1].$TRK_FRAME.$X) ;
    PR[98,1]=($LNSCH[1].$TRK_FRAME[1].X) ;
    PR[98,1]=($LNSCH[1].$TRK_FRAME[1].$X) ;

    Provided you hook the controller up to the robot before you power the controller up, you might not even need to update rev counters.

    Then you just commission the robot like normal.

      • Load IO parameters.

      • Load/Create program.

      • Get comms up.

      • Teach TCP(s).

      • Run payload ID(s).

      • Teach points/path.

      • Auto degug.

    While you could do it in Karel, it would be much easier to use the menu utility.

    I think this is a free option from fanuc, but the last time I got the pac code for it was several years ago, and they may be charging for it now.

    I would give Fanuc a call and see if it is still a free option, and if so, get a pac code from them.

    I am not sure, but I think the outputs on the RJ2 fanuc EE connector are NPN. As in, when the outputs are on, they supply a ground path. They do not source power.

    To set the J1 axis limits, go to control panel, then go to configuration, then select the "motion" topic, then select the "arm" type, then it will be something like "rob1_1", or "irb6600_1" (there will be 6 of them, one for each axis). Go into that, and you can edit the upper and lower bounds. The bounds are in radians, so you will need to convert from degrees to radians.

    Here is some code I have used in the past, which really only works if you have one TCP. Otherwise I would recommend you use blind3rr's solution.

    I was able to find a solution over on the robotstudio forums. Here is a link to the thread.

    Here is the code, with some slight modifications.

    Edit: Cleaned up the code a bit more.

    Are there any functions to test if a point is reachable? I've looked through the rapid documentation, but I can't find anything that fits the bill.

    The robot I am programming runs vision right on the edge of its work envelope, and I would like to test if the offset vision position is reachable before attempting to move to it.