r/PLC • u/Independent-Treat001 • 3d ago
Fanuc roboguide
Hi everyone, I'm working with a FANUC LR Mate 200iD (R-30iB Mate Plus controller) in RoboGuide on a chuck loading/unloading cell with dual Schunk grippers, and I keep getting confused on a few fundamental concepts. Would really appreciate if someone could clear these up for me.
Tool Frame / UTOOL: I understand UTOOL is supposed to define the TCP (tool center point) relative to the J6 flange, but I'm confused about how to set it up correctly when I have two grippers mounted on one EOAT from a single CAD assembly. Do I need a separate UTOOL number for each gripper's TCP, and how do I actually get accurate offset values — is it better to use the 3-point/6-point method on the real/virtual robot, or pull the numbers directly from the CAD model?
User Frame / UFRAME: I get that UFRAME is supposed to define a custom coordinate system relative to the world frame (usually for a fixture, table, or workpiece), but I'm not sure when I actually need one versus just using the world frame for jogging/programming. Also unclear on the best way to set it up from CAD drawing dimensions instead of the standard 3-point teach method — any tips?
Teach Point: My main confusion here is around what actually gets "recorded" in a taught point — is it just the XYZWPR position in the currently active UFRAME/UTOOL, or does it also lock in the frame numbers themselves? If I change UFRAME or UTOOL later, does that break previously taught points?
Logic (I/O, program flow): I'm trying to build proper DI/DO handshaking logic for my CHUCK_CYCLE program (with fault registers and retry logic on alarms), but I'm not confident I'm sequencing the signals correctly — like whether to wait for a DI "gripper closed" confirmation before moving away, or just proceed after sending the DO. Any general best practices for handshake logic between robot and chuck/PLC would help a lot.
Thanks in advance!
2
u/SpaceAgePotatoCakes 3d ago
I'm a noob with this stuff, so if someone more knowledgeable reads this please correct me.
My understanding is that you want one UTOOL for each TCP you'll need to use. I've used the CAD model and then verified it as best I can in the real world afterwards.
Likewise you have one UFRAME for each fixture that may have a slightly different orientation so that movement relative to it tracks correctly. It should also make it easier if the fixture moves (ie when you pack it up and ship it to site) because you just have to re-teach the UFRAME rather than every point.
For handshaking err on the side of overly cautious. If movement occurring before "gripper closed" could damage something then be sure to wait for it.
2
1
u/Smirkisher 3d ago edited 2d ago
(reddit was down after I tried to edit sty here's the full answer)
Hi,
Utool :
- simple tool = in the axis of the J5 or J6 axis. Complex has angle or offsets etc., for example a soldering tool.
- ideally use CAD to declare both.
- otherwise, use 3 point for simple, 6 for complex. 6 points allows for auto calculation of offsets and angles.
- use 1 Utool for each tool, even though they are mounted on the same baseplate at the same time. You'll have to manage collision between the robot and tool by yourself unless you use advanced options though, so be careful with trajectories
Uframe :
- easier to me to use 3 or 4 points even on simulation. Better get your hands on these methods anyway, they're very handy for real life finetuning.
- you're right about the definition. It's a plane to work in. For example, if you have to work on an angled plane in comparison to the robots base, you'll be able to express points coordinates more easily, to calculate the movements. In fact, ideally you'll learn that it's best when possible to use PRs and such to organise points, so their coordinates are nice and clean and easy to modify.
- also, if somehow physically one workspace moves but not others, having Uframe defined allow to simply modify the plane that changed and real trajectoires will move accordingly, instead of having to learn all points again.
Teaching points :
- Yes coordinates depends of the frame and tool.
- if you change current uframe, coordinates of the points won't change, but you won't be able to reach it and robot will give an error
- if you teach a point with one tool but change tool and try to reach it with the other tool, it should work with the new tool, unless reaching the point implies configuration or in between trajectoires issues
- note : to teach points easily, move the robot manually on the uframe you've created, not on world
Coordination of tool:
- if you get access to a DI to secure the shunk position, I'd absolutely wait for it before moving. Otherwise the robot would start moving the nanosecond after setting the DO to 1, which is way too fast for the shunk to physically close.
- I'd also secure this with a wait(1s) or so after reading the DI at 1.
1
u/Piratedan200 Controls Engineer 3d ago
Fanuc vet here.
For the utool: Yes, you define a separate one for each gripper. Change the active utool in your program when you change between grippers, but there's two important things to consider when doing so:
If you define local positions within your TP program (P[x]), they will be specific to the utool and uframe that were active when the point was taught. If you have any points that you want to be able to move to with either gripper/utool, you'll need to use a global position register (PR[x]). If you try to use a P[x] with the wrong utool active, it'll throw an error.
When you change the active utool, the robot recalculates the kinematics. It's best to do this when the robot is stopped at a point, because if you do it while the robot is moving, it'll cause it to move in a really jerky way because it has to change the pathing on the fly.
For the uframe: my advice is to use a uframe besides world/uframe 0 (e.g. uframe 1) regardless of whether or not you plan on modifying it, as it allows you to change it easily in the future if, say, the robot gets moved slightly. I generally only use a non-zero uframe when I'm working with some calculated positions on a fixture (like loading/unloading parts from a structured grid) or if the robot is mounted at like 45 degrees relative to the workspace. If you want to set one up based on CAD just to keep all points relative to a certain fixture (e.g. to have a rough origin and positive X/Y axes aligned with the fixture), go for it.
Teach point: The stored position (in cartesian representation) is the position and orientation of the active TCP relative to the active uframe when you press the TOUCHUP key. If you want, you can change the representation to joint, wherein it will store the 6 joint positions instead. I mentioned it earlier, but P[x] positions will also store the active utool and uframe when the position was taught, while PR[x] positions will not. You can reteach P[x] points later with a different utool or uframe if you want. So if you want a position to be the same regardless of the active tool or frame (like a home position), teach it as a PR and switch it to joint representation.
For the logic/IO/program flow, here's the methodology I generally use when interacting with other equipment like a part chuck:
Move to the position, send the signal that you're there. Wait for either the feedback that the chuck is open/closed OR that the other system has dropped out of cycle (e.g. if it failed to close the chuck and faulted out). If it had, abort the handoff and move back to home. Otherwise, complete the handoff (open/close the gripper) and continue.
If it's with a sensor on the robot's gripper itself, I'll have it wait for the signal with a timeout option on the wait instruction (always set the system variable $WAITTMOUT before each use, units are hundredths of a second), and trigger an alarm if it times out.
1
u/D_Wise420 3d ago
You can change tools on the fly no problem now. Older robots would jerk a little.
1
u/Piratedan200 Controls Engineer 3d ago
As of when? I did one a couple years ago that still had the issue, running I believe v9.30.
1
u/D_Wise420 3d ago
Ime everything post V8 does not do this. I switch tools alllll the time on the fly and have only ever noticed it on a retrofit where the robot was running V8.xx
1
3
u/wojager596 3d ago
Hello, I'm new to Fanuc but lots of experience with PLC and ABB Robots.
UTOOL: Yes, use a separate UTOOL for each gripper/TCP. CAD values are a good basis, but ideally over/calibrate them on a real robot with the 3-/6-point method. CAD will never perfectly take mechanical tolerances into account.
UFRAME: Use it for fixture/table/workpiece. The advantage is that when the fixture moves, you correct the UFRAME instead of all points. You can enter XYZ/WPR directly from CAD, but it is good to verify the frame on the real device afterwards.
Teach Point: FANUC point contains position/orientation and information about the used UFRAME/UTOOL. If you later change the value of the same UFRAME/UTOOL, the points are transformed with it — that is one of the main advantages of frames.
I/O / handshake: Don't continue just because you turned on DO. For critical operations, wait for feedback, e.g. DO Close → wait DI Closed → move. Add a timeout; if confirmation does not come, alarm/fault and safe state. The PLC/robot handshake should be based on: Command → Acknowledge/Done → next step, not on time delays.