Would like a feature added to the Move tab that acts similar to the Direction node where it will automagically stop when it contacts an object.
Basically it would allow the user to move the TCP using the Arrows in the Move tab and when the TCP touches something it stops movement so you can set the waypoint.
This would be a huge aid for setting up applications that do machine tending or other pick and place operations. Especially for shops like ours where we have a lot of different parts moving through the robotic cells and there each part requires a different setup.
When active it could limit how fast the TCP can move to reduce impact.
I’ve never made a URCap so I don’t know what’s possible or if there are any other workarounds to be able to achieve this result via a script or something else.
There’s been literally hundreds of times I could have used this in the last 6 months. Usually setting corner positions in a grid pattern or setting part pickup and dropoff locations.
Anyone else think this would be useful?
UR has completely ignored this.
This week alone, not having this feature cost us several hundred dollars. Literally.
To recap the problem and desired solution, I do setups on two UR10e’s to tend CNC machining centers. Usually a few hundred parts to a couple thousand at a time, so a lot of turnovers.
I have a 3 x 4 foot table with plastic templates with grid patterns water jetted to hold as many parts as possible. The size and quantity is highly variable. Pict below has 2 different sets of templates.
I change setups at least once a week sometimes 3 or 5 times a week so I’m constantly setting waypoints against the walls of these templates and inside the machine in vises and/or fixtures.
Using Freedrive is not an option. Too much resistance in the arm to feel the walls unless you slam into them, then it bounces and you don’t get a good setting anyway.
Yesterday I made a short program that would simulate my requirements but it’s really cumbersome and the TP gets really hot after about 15 minutes of opening and closing programs every 30 to 60 seconds. The system response time slowed noticeable during that 15 minutes as well (I have not cleaned out the “oldx” files on this robot using @eric.feldmann bitchen script yet).
Anyway, I position the TCP inside the squares then run the program. It asks the user for a direction (1-6 to represent X+, X-, Y+, Y-, Z+ and Z-). Program moves in the selected direction until contact then stops. Once I’ve done both direction and the TCP is physically sitting against 2 walls I open my part program and store those values then go to the next one and repeat.
UR tech group, if you’re listening to your customer’s feedback, I believe this feature would make at least a few people’s lives way less complicated and frustrating.
Everyone else, if you have any suggestions I can use to make this less painful I’d greatly appreciate it.
So the best way is to have UR implement it into the Move Tab (duh).
The next best way is to program all the moves your program is doing into a CAP and stick it into the tool bar so you just press a button, it goes through your edge finding sequence and then stops. This is fairly easy if you have CAP experience, but a massive learning curve if you don’t.
The third best might not be terrible in your case. You have your driver program already written which does your seeking pattern. Add this as a subprogram when you’re programming a new setup. Don’t bother with adding the call, just select the “Robot Program” line at the very top, then hit SubProg to insert it without a call.
I would honestly name it something easy like mySeek, cuz you could end up typing it a few times. Or once and copy paste. Anyway, once you have the subprogram inserted, load your existing program that you’ve been using into it. Now anywhere in polyscope you type mySeek() or whatever you name it as a script command, it will run this subprogram.
Now as you’re programming, you can chug along until you need to seek. Insert (or paste) a Script node, type mySeek(), select that line, and hit “Play from Selection.” Just make sure to include a Halt command at the end of your subprogram so it doesn’t keep going.
If Polyscope tries to force you to Move To a Waypoint before starting, then go back to the top, click Robot Program and select “Add Before Start.” At the very top, insert a Move, switch the Waypoint to “Relative” and then just teach the same point as the To and From. It won’t actually go anywhere, but now it will just autostart from wherever. Useful for using your seek program.
In the meantime, if you want to DM me your exact use case I could try to put it into a CAP (since I can’t modify the Move screen.) For example do you always find the bottom left corner, or does it need to be user selectable to some capacity. I guess I could just make 6 buttons and each one you tap goes Until Contact in that direction… Might be simplest.
Thanks Eric. Let me look through that 3rd suggestion. I was wondering if there was a way to branch out of the part program into the seek program, using a thread, or a sub or whatever else.
I’ve never really looked at how to do caps, but I’m not shy about learning new ways to program. There are so many things I could do if I could make caps. LoL Just never enough time in the day though.
As an aside, using my current method over the last couple of days has sent the lag time for the file dialog through the roof. Started at about 2 seconds on Wed and is up to almost 10 seconds already. Usually it takes a couple weeks to get that bad. Gonna clean it out using your script today or Monday.
Is the robot and table bolted together?
If so you could make an URCap where you define the distance between the parts, maybe a Z plane offset if you got different heights of grid plates. And then also have a height on the parts on the plate.
I made an URCap for a gridboard with round pegs, which we use for lathe tending. I just got the board defined as a plane, and then calculate the positions on that plane.
With this setup, changing between different size parts only takes me seconds to program, because all I need to do is to insert the size of the new part.
Moving the pegs and grippers on the robot takes way longer than the programming does.
Both robots are on their own stand, bolted to the floor. The tables are not connected to the robot stands but they are bolted to the floor. There is a bit of flex in them it seems because I often have to fine-adjust my waypoints when I change jobs.
The parts vary in size from a 1/2 x 1 inches rectangles to 3 x 7 inch rectangle and I have a dozen different templates with varying sized pockets to hold the parts. The quantity, (rows and columns) also varies. Some templates hold 12 parts, others hold hundreds.
In many cases I’m trying to position parts within .002 inches or less on secondary and tertiary operations. Was a real challenge a couple years ago but I’m getting better as I learn more about the robot.
The first couple of years I was climbing all over the table and inside the small machines (along side the robots cuz they gotta be in there, too) trying to position as close to the edges as I could. It was all visual so I had to be able to see the edges I needed to be against and it sucked. And it always required more adjustments after I started running to dial in the position. I’m closer to 60 years old than I am to 50 and all those gymnastics and contortions are taking their toll on my old, already abused body.
THIS IS WHERE THE MOVE TO CONTACT FUNCTION COMES IN.
The (very cumbersome) program I made to allow me to select a direction and have the robot move until it hits an edge then it stops. Then I change programs and store the location for that position then go back to the other program to find the next edge.
It cut down my edge-finding times by half. And now I can do 80% of that work while sitting on my butt without the need for pain management when I get home.
The ability to NOT have to change programs to use and “until contact” function during a setup would cut the remaining setup times by OVER half.
This function would be a game changer for people like me doing multiple setups every week.
Very interesting discussion! I’m not sure if this was picked up on previously, but I will ensure it’s passed on accordingly.
Thanks! I was getting a bit worried about my sanity. Having full-on conversations with yourself is not always a sign of a stable mind. 
Alllllllll righty @fuknrekd. Here it is:
MoveContact-1.0.0.urcap (27.1 KB)
Been running my robot into the table for the last several minutes and everything seems to work correctly. If you hold the button, the robot moves in that direction. If you let go of the button, the robot stops. If it Tool Contacts something while you’re holding the button, it stops. Hopefully it works how you’ve envisioned. If not let me know.
The controls are housed in the Toolbar again just like the TCP one. Looks something like this:
Obviously, I’m not graphic designer. I threw this together in a few hours. Biggest improvement would be to tie the buttons to graphics that mimic the Move Tab, but drawing is hard. So instead you get a line of buttons. It also doesn’t move with respect to a Feature, it just uses Base because working with Features is a nightmare.
The other note here is that I’ve hard-coded the speed to 2 in/s. You can go slower by reducing the speed slider, but anything much faster and the contact isn’t sensitive enough anyway. Hopefully that works for ya.
Final note, it uses socket communication which is slow. You can see this lag if you just tap the button. It’ll sit there for a bit, then move for a bit, then stop. That’s out of my control and is a major thorn in my side for my other developments lol. Hopefully the lag is tolerable.
Lemme know how it works for you. I may end up using it for my own machine tending jobs down the road too. Who knows.
It’s, It’s… it’s beautiful!!! 
Will try in after coffee, but from your description it looks like it is just what I expected.
Will feed back.
And really… this is beautiful.
Thanks!
I’ve added this to both robots and it works great. It’s going to make a huge difference in my setup times.
One thing I’ve noticed (and it’s not the Cap, it happens with ANY “until contact” scenario), if I move Z down until contact and then use X or Y, it will often hang up on whatever it touched on the Z and stop it from moving in X or Y.
I haven’t really noticed this behavior when moving just X or Y, maybe because of gravity.
This also happens when I use that bitchin find midpoint script you gave me. [Move TCP to Midpoint Between Two Contact Points - #2 by eric.feldmann].
My solution was to retract .01" after each contact. This almost always works to remove the drag affect and allow the TCP to move correctly. Not sure if this is a viable solution for your Cap.
Bottom line is that this is going to be a huge time saver. Thanks again.
@ajp I think you guys owe @eric.feldmann a huge THANK YOU and mayhaps a case of his favorite beverage for taking such good care of your customers. 
Haha well I’m glad it works for you. And yeah it stopping like that has to do with dragging. Kinda crazy how sensitive that function is. Really smart programmers at UR for that, honestly. I’ll add a box to let you enter a desired retract amount. Probably shoulda thought of that to begin with. Should be able to make that change this weekend.
I have to send all my raw stock to the tumbler before I run it. If there’s ANY small burrs on the part it stops before it gets to the stop.
Would a text box require it to be updated every time you use it? Or could the value be stored in the Installation or robot program? Ideally it would be nice to have a default value that you don’t need to fiddle with during regular use, but still have the ability to change if needed.
You’re the best, Eric.
Yeah I can figure something out. Probably just store it in the installation so it just saves whenever you type it in. That way you can screw with it as much or as little as you need. Ideally you can get it to where you just type in some number and never touch it again.
That’s perfect. Thanks!
Haha yes @fuknrekd this is a good point. Thank you for your fantastic contribution to the community @eric.feldmann! What is the beverage of choice? I hope I will have an opportunity to make that happen.
@ajp pfffft at this rate my favorite beverage is a gallon of gasoline! Incidentally, my company will have a product in UR’s booth at Automate here in June in Detroit! No idea who on your guy’s end gets selected to go to those trade shows, but I’ll be there.
@fuknrekd
MoveContact-1.1.0.urcap (34.3 KB)
Here’s the updated version which includes a field in the installation for setting a retract amount. It’s nothing pretty, just a box hanging out in empty space, but it gets the job done.
Works as expected. Thanks much Eric. You’re making my setups easier.
3.785 liters of gasoline, got it I don’t think I will be at Automate but will look for another opportunity!