Is it possible to program Reference Positions to match PR's?

    I have 27 Reference Positions that trigger Digital Outputs(memory). These same positions are contained in Position Registers as well. We use these to indicate to a PC running Labview of where the robot is. We also need to be able to command the robot to go to these positions via PCDK and through the teach pendant manually - in which case it is easiest to use the position register.

    The problem is when we re-teach a position register, we also need to remember to update the Reference Position to match it. The positions will change often as we have different products to interface with.

    So I just tried playing around with the Reference position system variables and found a working, but extremely cumbersome way you could accomplish this. The system variable for reference positions is $REFPOS1...8[n] (where 'n' is the desired reference positions), in this there are a few parameters you probably wont need to set more than once, along with the $PERCHPOS[n], the actual position you would be looking to reset. I tried to use the syntax $REFPOS1[1].$PERCHPOS=PR[1] and only received "parameter not found" faults, However if you set each individual element at a time it appears to works. However, even more frustratingly the values in the system variable are in Radians, not degrees so you will need to convert.


    EX:


    $REFPOS1[1].$PERCHPOS[1]=R[1]

    $REFPOS1[1].$PERCHPOS[2]=R[2]

    $REFPOS1[1].$PERCHPOS[3]=R[3]

    $REFPOS1[1].$PERCHPOS[4]=R[4]

    $REFPOS1[1].$PERCHPOS[5]=R[5]

    $REFPOS1[1].$PERCHPOS[6]=R[6]


    Also just found this thread from last year that may help: What File Contains Reference Positions

    Particularly Nation's comment on using a .cm file to set ref positions. Good luck.

    I have found the Reference Position Variables, but they are in Radians.....

    $REFPOS1[1].$PERCHPOS (1-9)


    So how to convert from a Position Register to Radians, then write to the proper $REFPOS1 variable?


    Edit: Eric, I think we must have posted at the exact same instant!

    Anyhow, yes you are on the same track I was seeing - very cumbersome, especially for 27 reference positions.

    I don't know how to begin.. Some type of index looping?? I'm assuming this could only be done in KAREL in which I have limited skills


    Appreciate any input/guidance... I need to update the Reference Positions somehow..

    Ok, I've written up a TP program to transfer the PR to REFPOS variables, and tried to convert to Radians.

    Code:

    7: !SafePerch1 = PR1

    8: $REFPOS1[1].$PERCHPOS[1]=(PR[1,1]*0.01745) ;

    9: $REFPOS1[1].$PERCHPOS[2]=(PR[1,2]*0.01745) ;

    10: $REFPOS1[1].$PERCHPOS[3]=(PR[1,3]*0.01745) ;

    11: $REFPOS1[1].$PERCHPOS[4]=(PR[1,4]*0.01745) ;

    12: $REFPOS1[1].$PERCHPOS[5]=(PR[1,5]*0.01745) ;

    13: $REFPOS1[1].$PERCHPOS[6]=(PR[1,6]*0.01745) ;

    14: !SafeToolSelect = PR2

    15: $REFPOS1[2].$PERCHPOS[1]=(PR[2,1]*0.01745) ;

    16: $REFPOS1[2].$PERCHPOS[2]=(PR[2,2]*0.01745) ;

    17: $REFPOS1[2].$PERCHPOS[3]=(PR[2,3]*0.01745) ;

    18: $REFPOS1[2].$PERCHPOS[4]=(PR[2,4]*0.01745) ;

    19: $REFPOS1[2].$PERCHPOS[5]=(PR[2,5]*0.01745) ;

    20: $REFPOS1[2].$PERCHPOS[6]=(PR[2,6]*0.01745) ;


    It does update the REFPOS variables, but not with the correct values. How do I convert to the proper Radians?

    This code above appears to convert to World Coordinates.

    Be careful if you change your representations to joint. If you have any programs that are using a specific element for a calculation (R[x]=PR[i,j]), you will run into lots of trouble and can very easily crash the robot.

    Changing the representation to Joint does indeed work. I can copy the position and translate to radians and it updates the REFPOS variables just fine.

    However, as pdl pointed out, I can no longer use that register in the other programming - which is a big deal.

    I tried copying the Cartesian format of the register to another register in Joint representation and use that to convert - but it auto converts the representation to Cartesian, so that does not work.

    I'm getting close here.

    I need a way to convert the original PR to joint without affecting the original register, then convert to Radians and copy to the REFPOS


    Any help/input is appreciated

    Thanks for the input. I did a bit of searching around the forum and quickly saw that KAREL was about the only choice. Several example codes out there.

    I'll most likely end up writing the whole thing in KAREL then and tailor it specifically for our processes.


    Having to get this complex makes me rethink our whole strategy - maybe you guys have a better solution or a bit of guidance.

    This robot cell is one of about 10 robots we have, along with 300 other types of machines with various servo/electric/pneumatic/hydraulic control systems

    Point is, I can and have programmed robots but not an expert in correct methodology - can definitely use advice on best methods


    Scenario of cell being built:

    Robot will have 2 tools, each tool having servo motor, torque cell, air bearings - one large, and one smaller.

    Each of these tools needs to connect to 6 different test parts inside a thermal box at several temperatures.

    So one part connection sequence:

    Select Tool1; move to tool 1 camera position, visual align coupler system, offset, move to connect, connect, lock, verify

    Pneumatic part1 thermal door open, verify

    Move to part1, visual alignment routine, offset, connect

    Run servo motor/torque routine

    Disconnect, move to safeanypart position, close thermal door for part1

    Part2, open thermal door, move to camera position part2, visual align, offset, connect

    Run servo motor/torque routine

    and so on for all 6 parts


    Then switch to tool2 and repeat

    Then change temperature and do it all again....


    And of course there is variations..

    - only running 1 part

    - 1 part but in a different part location (part1 in part6 location of thermal box)

    - only running 1 tool


    So the overall thought was we can do this with a sequencing engine, each sequence is written specifically for the case being tested.

    Therefore, the sequence engine would need to know where the robot is in order to apply logic to allow movement to a specific location.

    Tools are large and the cell is small - collisions can occur, so we have safe spots that can be moved between safely, then move to the specific part.

    i.e SAFETOOLSELECT can move to TOOLSELECT1 or TOOLSELECT2, or can also move to SAFEANYPART - with these paths being known to avoid collisions.


    So that in a nutshell is driving the need to know where the robot is and have the sequence engine be aware.

    - I made the choice to do this with Reference Positions tied to a digital output that the sequence engine can monitor.


    Better way? Advice?

    I have much code to write and get this thing up and running, just the tip of the iceberg right now.


    Sorry for the long post.

    Hi

    My 2 cents

    Seems to me that you know what you're doing but you're overwhelmed by all this things coming at the same time.


    I don't know how much time you have but I would write a simple program, lets say one tool, one part, engrave that logic in your brain and do the next part.

    I'm suspecting you are going think "oh, i just wrote some similar, can i use what I just did now" I think naturally you are going to develop (slowly) a good process incorporating one thing at a time .


    Have you tried (if you have it, MENU, SETUP, Space fctn) SPACE FUNCTION ? That could be a good help to you to know where the robot is

    Retired but still helping

    Your original question makes it sound like you are primarily trying to reduce the time (and the potential for forgetting) that it takes to teach both reference positions and position registers.


    The only way I know of off hand to convert Cartesian positions to Joint on a robot in TP is to let the robot resolve IK for you. By that I mean just move the robot to the desired Position register and have a macro record both the Joint and Cart. position to two different position registers as well as set the reference position. This obviously wouldn't work if you plan on changing the position register during runtime, but it should be a decent answer to the original problem.

    Thanks for the feedback, yes a bit overwhelmed but also a great challenge and I do love this stuff.

    I don't appear to have SPACE Function available, a bit of searching it looks like it is part of basic interference check package.

    I think I understand it's concept, but I'm not sure I could apply it to this cell. Either way, there is zero $ being spent right now - so no chance of getting it.

    Erik - that sounds like a viable solution. A concern might be running out of position registers though, we have a lot used when we are done with whole cell, then take that X2. I'm definitely looking into this one thought, never even thought about a macro - thanks!


    This sounds like the way Ford does their material handling robots in their transmission plants. The robot reports out where it is, and then accepts commands to move to other known areas. If there isn't a defined move, the move is rejected and a fault is posted. The sequence is typically Move from WorkA to PounceA. Move from PounceA to PounceD. Move from PounceD to WorkD. etc. Robot reported out where it was via a group output once it arrived at that position.


    Path Diagram from that job (R#s were robot routines):


    Another method I have used in the past, if your cell allows it, is to define a safe arc reference position, where the robot is tucked back to the point it can rotate on J1 freely without hitting anything (aka tolerence on the J1 position is +/- 180 degrees). I then check if I am on the arc before moving to a position. If not I retract to the arc, rotate on J1 until I am in front of the fixture, then enter the fixture's path.



    If I wanted to perch in front of a fixture I would call this program, which calls SafeArc if I am not already on the arc.


    Another method may be to use a background program to monitor the current TCP position and set outputs based on that. You can monitor $SV_INFO[1].$CART_POS for the actual position in the World coordinates, or $SV_INFO[1].$CART_POS_UF for the actual position in the active User Frame. These system vars are only present on newer controllers though. If you are running something older than v9.10, you can monitor $SCR_GRP[1].$MCH_POS to get the current position, but only in world. Also this var does not update when jogging or when the robot hasn't moved yet. I am not sure about the $SV vars on whether they update live in all modes or not.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    Nation, great info - thanks.

    Looks like you are quite familiar/comfortable programming in joint move modes. Unfortunately I am not and I don't believe joint moves would work for us but I could be wrong. Depending on the tool, sometimes we need to move in a perfect z-axis movement only by a millimeter or so. Or sometimes I need to offset a move in a particular axis due to camera target offset and aligning shafts perfectly. I'm not sure how to do this in joint mode, or at least wrap my head around it.

    Monitoring the live position through the $SV_INFO[1].$CART_POS_UF does work quite well. We actually stream that data via pipes and sync it with our data collection system on a different stand. But if I use that to detect positions, then I'd need to have a loop spinning on the PC side with a tolerance around each position - it's possible to do, but it looked like Reference Positions were going to save me a lot of code. Not sure what way would be easier / reliable.

Advertising from our partners