I see. Yea easy enough to turn it on only for as long as you need it. Thanks for the tip. This forum is actually where I found the variable in the first place. Good info here with people that are more than happy to share and help others.
Posts by K_Glide
-
-
I currently have $PR_CARTREP set to on just for this reason. What is the downside in leaving it on?
-
This is exactly the route I was going to take. I just didn't like how messy it an get but looks like there is no other choice. Thank you for the reassurance!
-
I have an R30iB controller that is currently set up CC-link IE field to a Mitsubishi iQR PLC. It is set up for 16 read and write registers to and from the robot. I’m wanting to get UTOOL values over to the PLC but every time put the value in one of my read data registers in the robot it gives me a PRIO-703 data invalid error. I’m converting the values to interfere before moving but it seems that the registers in the robot will only hold the max value of a single word. All the other data registers that are not PLC linked can hold anything from real numbers to large integers. The data registers they are writing to in the PLC side are double words so they should be able to hold the values. Is there a way to designate these PLC linked registers as something else other than a signed 16 bit word? Or is there a better way to get UTOOL values to the PLC? I can divide the interger by 10 on the robot side and move them in and then multiply by 10 on the PLC side but that seems like a lot of unnecessary math and could result in rounding errors as well.
-
I like the simplification of this. May have to pitch this to some of our engineers. However, we intend on using the Captron laser TCP calibration tool to do this and use skip conditions to capture the LPOS at the moment it would break the laser beam digital in out high). What you are suggesting is a fixed pointed structure on the cell correct?
-
Rough example of my code currently.
29: R[101]=0 ;
30: R[102]=0 ;
31: R[104]=0 ;
32: R[101]=((PR[40,1:TCP 1st X POS]+PR[41,1:TCP 2nd X POS])/2*R[7:PT CONSTANT]) ;
33: R[102]=((PR[42,2:TCP 1st Y POS]+PR[43,2:TCP 2nd Y POS])/2) ;
34: ;
35: ;
36: PR[38:UT OFFSET MANIP]=UTOOL[9] ;
37: PR[38,1:UT OFFSET MANIP]=(PR[38,1:UT OFFSET MANIP]-R[101]) ;
38: PR[38,2:UT OFFSET MANIP]=(PR[38,2:UT OFFSET MANIP]-R[102]) ;
39: R[104]=R[101]/(-1) ;
40: PR[38,3:UT OFFSET MANIP]=PR[38,3:UT OFFSET MANIP]-R[104] ;
41: UTOOL[16]=PR[38:UT OFFSET MANIP] ;
42: ;
43: ;
44: UTOOL_NUM=16 ;
45:L P[5] 100mm/sec FINE ;
46: SKIP CONDITION DI[27:Move to Camera Pos 1]=ON AND DI[28:Move to Camera Pos 2]=ON ;
47: !Do Z search in the shifted TCP. ;
48:L P[6] 2mm/sec FINE Skip,LBL[100],PR[44:TCP 1st Z POS]=LPOS ;
49: PR[44,3:TCP 1st Z POS]=PR[44,3:TCP 1st Z POS]*R[7:PT CONSTANT] ;
50: ;
51: PR[38,3:UT OFFSET MANIP]=(PR[38,3:UT OFFSET MANIP]-PR[44,3:TCP 1st Z POS]) ;
52: R[101]=0 ;
53: R[101]=PR[44,3:TCP 1st Z POS]/(-1) ;
54: PR[38,1:UT OFFSET MANIP]=PR[38,1:UT OFFSET MANIP]+R[101] ;
55: UTOOL[16]=PR[38:UT OFFSET MANIP] ;
56: ;
-
Matrix multiplication is the general solution. It works for any angles, any scenario. That's why I always use it for calculating frames.
Your solution will work fine for this specific case.
I guess I misunderstood the matrix math option you were referring to. What is the exact option that lets you do this? This wasn't too hard to do in the code but took a little digging on my part along with a colleague to figure out the best course of action.
-
Well if you give me a picture we could do it without that Pythagoras guy. Glad you got it
I'm up for any advice. Here is a screen shot of it in the 0,0,0,0,0,0 joint position.
-
K_Glide,
can you give me an image from the side of the tool, robot face pointing in world X, or from the side in the 0, 0, 0, 0, 0, 0 joint position. I think I can get this. I've done this many times, but your 45 degree angle is a bugger.
I was able to achieve my desired result by applying a factor to both the X and the Z world coordinates. Basically teach a user frame with the center of the 2 intersecting lasers being my 0,0,0 point. Then move the robot through the lasers and save the LPOS to a position register so get the delta from my origin point. Lets say my nozzle in 2 mm off in the +X direction. To achieve this offset, I have to move in both the X and Z direction. I achieved this by applying pythagoras theorem of 1/sq root of 2=0.7071. I then took that factor and multiplied it by the X delta I just got. To do the inverse move in the Z direction, I just took the value of X delta and divided by -1 to make it a positive or a negative number and used that to offset my Z. I hope this all makes sense. It works beautifully in robo guide. I'll get the program cleaned up and provided some sample code.
Edit: When I say move it in both the X and Z directions, that is in reference to my faceplate not world. I need to move my tool coordinate in both X and Z to move it just in the X direction in the world coordinate.
-
The only way to do it for a group of positions to it change the frame, or add it to every position.
Thank you for your help. In my case, applying the matrix math is going to be the easiest and quickest solution. It looks promising in roboguide.
-
Might just do the math on the back end. Whatever offset is needed in the X tool direction should be the inverse for the Z since my faceplate is at a 45 degree angle from my TCP. (ex. +10mm on X would be -10mm on the Z to maintain that linear offset.
-
So no way of offsetting the tool for a group of positions other than adding tool_offset at the end of that position?
-
All UTools are defined relative to face plate. To modify them relative to an existing UTool requires matrix math. Or just use the tool_offset and it will do the math for you.
After looking at this I see what you're saying. I do have a question in regards to the tool offset. In my dispensing program, I have around 80 positions that the robot goes through to apply it. Is there a way to set a tool offset using the "Tool_Offset" function for all of these and then turn it off at the end or do I have to use the "Tool_Offset_Condition [PRxx] and then add the "Tool_Offset" at each individual taught point?
-
Here is a screen shot of the EOAT. The nozzle facing down is the dispensing nozzle. I just want to be able to shift where that TCP sits for slight variations using the laser to pick up the deltas from a master UTOOL and apply them to a shifted TCP. Currently, if I need to shift the TCP in the UTOOL X+ direction of the UTOOL orientation, it goes the X+ direction of the faceplate.
-
I have done what NATION did on numerous small tool Robots.
Dispensing is easier. Mount a pointer in your cell facing up. Teach a user frame to the pointer, square with world is the easiest.
Create a program with the robot square or perpendicular to that frame. Make a point above the pointer,
Mine would tell the operator to drive in User X Y and Z to touch the tip to the pointer.
Then populate a PR[actual] in Utool 0 and Uframe [pointer]
Zero out another PR [new tool]
You will have to translate which [actual] X, Y, and Z apply to the Utool X, Y, and Z
Populate PR[new tool] with those numbers, ie PR[new tool,3] = PR[actual,1]
(Kglide with your 45degree tool i would have robot face plate perpendicular to the pointer)
Then manually load your angles if needed, .ie PR[new tool, 5] = 45
Lastly Utool[1] = PR[new tool]
I write a program to do all of the above except the jogging. you can PAUSE after a message telling them what to do. then tell them to restart and the program can do all the calculations and create the new Utool
I'm trying to use the lasers to capture my entrance and exits and apply the deltas to the UTOOL. I'm not sure if=t can be done that way with a tool that isn't aligned with the face plate. My dilemma is not being able to shift the TCP in relation to my tool orientation. It shifts it in relation to my faceplate.
-
Tool offsets are relative to the currently active tool frame and current orientation.
Make sure you have set that as the active tool in your program. Show your code.
I'm not actually using the tool_offset function. What I am wanting to do is set up a program that takes a master UTOOL, moves that into a PR and offsets X, Y, and Z based on deltas calculated by moving the nozzle in and out of the laser in the corresponding UTOOL coordinates and capturing the LPOS at the point of entry and exit (rise and fall) of the laser. Something like this.
PostRE: Laser TCP Update with Fanuc SCARA Robot
I have done what NATION did on numerous small tool Robots.
Dispensing is easier. Mount a pointer in your cell facing up. Teach a user frame to the pointer, square with world is the easiest.
Create a program with the robot square or perpendicular to that frame. Make a point above the pointer,
Mine would tell the operator to drive in User X Y and Z to touch the tip to the pointer.
Then populate a PR[actual] in Utool 0 and Uframe [pointer]
Zero out another PR [new tool]
You will have to translate which…Doctor_CAugust 9, 2023 at 7:15 PM -
Or am I looking at this the wrong way. Should I offset the user frame based off of the offsets generated by the TCP calibration? I know tool frames are always in relation the the faceplate. I just thought once you apply the orientation in that UTOOL (W,P,R) it changes the reference point.
-
Hello,
I'm playing with offsetting a user tool frame and I'm having trouble getting it to work correctly. It is on M-10iA/12 robot with a R30ib controller. It is a sealant dispensing application that has disposable nozzles that vary in straightness. I plan on using a laser sensor to run an automated TCP calibration when this nozzle gets changed out. The EOAT is offset 45 degrees from the faceplate. I'm only wanting to apply the offsets in the X, Y, and Z coordinates of the user tool. The problem I'm running into is when I apply an offset to the user tool "X". It will not take into account my tool orientation in the user tool and only travels in the X coordinate in relation to the face plate that is, as I said, 45 degrees offset from the TCP. I hope that makes sense. The same is true in regards to adjusting my Z. If I apply an offset to Z, it moves my TCP in relation to my faceplate and not the tool orientation. I've attached some screen shots to better illustrate what I'm seeing.
-
Getting ready to do this very thing on a dispensing application that has disposable nozzles that aren't always truly straight. Looks promising and the code is simple enough. ADPS, did you end up going the route that Nation suggested?
-
Figured it out. It is an encryption issue on the USB that our IT department does. I have a request in for encryption bypass but was able to get the FTP working via WinSCP so that actually makes it more convenient anyway. Thanks for any and all input guys.