Tie RTU location to Userframe instead of World.

  • Good morning all,


    First post to this forum, although not a stranger to web based discussion forums. Hoping I can gleam some information from some experts here. Maybe at some point I'll garner enough knowledge to give back some as well. I'm currently new enough to industrial robots that I'm not sure anyone would want to listen.


    Company has recently (~6mo ago) installed a welding robot in our facility. Robot is an M710lc, mounted on a 30m long linear rail system (RTU). The linear rail is tied to axis J7. We are doing the lions share of our programming through Octopuz offline, and then loading those programs into the machine via FTP. Our cell has (3) zones. One is an empty area for large weldments, one has a headstock/tailstock (with 22ft between points, and the one has a 2-axis positioner. We're a somewhat custom machine manufacturer, and because of that we might only have a production run of 5-10 pieces at a time on larger items. We have some stock parts as well, and those are getting targeted to this machine. We have had good success with our programmer setting up the code attached to a Uframe, then having our operator teach a new Uframe for each set of parts. These are typically "small" changes in physical Uframe location as compared to programmed (virtual) Uframe location. It's a bit of communication, but it's working well for us.


    We're attempting to use the same premise on a HS/TS setup, and have hit a roadblock. We've created TWO programs in Octopuz that work wonderfully after a few small touchups on the robot. There are many searches, many welds, and we move both the single group2 axis (HS/TS), as well as the RTU during the programs, so a total of 8 axes moving during the program. On this HS/TS we have a long fixture with additional identical parts that we want to weld further down the length.


    The thought process was that we could setup a small program that would call the first two, then move the Uframe by the desired amount, then call the same two programs again. This worked ALMOST exactly as expected. The points, and robot motions were correct, however all of the RTU locations DID NOT move with the Uframe. This means that the robot was attempting to move to a location it couldn't reach. Essentially, the RTU did not move, and the robot was getting "unreachable position" errors. If I could tie the RTU location to the Uframe and have it move along with it, that would solve the problem. I get that it's theoretically possible to "over stroke" the RTU with this method, and I can see why it is setup the way it is, however it's making it difficult to reuse code in this manner.


    I think it would be ideal if I could tie my robots RTU to the Uframe instead of having it tied to world, when points are created? I feel like this should be an easy fix, and I just can't find the button for it.


    I considered using Program Shift to move the program from one location to another, and just shifting it by the appropriate amount in one cartesian direction, however I can't seem to figure out how to call that within a program on the teach pendant. I would be totally OK with shifting the program, calling it, then shifting it back.


    I'm also completely open to another concept or idea to move the program quickly and easily within a TP program. Like I said above, I'm new to this sort of programming, so I'm all ears.


    Here's a picture of the zone for some context. We have now just two locations, however when production numbers reach high enough levels we intend to fill this fixture with parts and just run a single program up/down the machine as needed.


    Thanks in advance for any help!

  • Could you add a PR offset to all of your motion instructions? Then initialize the XYZWPR values of the position register to zero.


    IE:

    L P[1] 2000mm/sec FINE Offset, PR[50: Rail Ofst]


    Then, whenever you change the position of the user frame, change the E1 value of the position register by the same amount.


    IE:


    PR[50,7: Rail Ofst]=R[x:Frame ofst]

  • Erik Olsen


    Thanks for the tip. That's a clever approach I hadn't considered. I'll have to give that a shot.


    Thank you!


    **EDIT**


    Just spoke with my guys on the floor. They've tried the approach of accessing JUST the "7th" portion of a point, and the robot didn't like it. I'm not sure what errors were thrown, but my understanding is that they couldn't access just the rail portion of the point. I'll dig into it further and report back.

    Edited once, last by 2kwik4u ().

  • Wanted to circle back and follow up on this post.


    We ended up using the "Shift program" functionality within the Teach Pendant, then wrote a small program to simply call the new programs we created in succession. Took about 15min more setup on the front end, but worked like a champ.

Advertising from our partners