So configure UI[5: FAULT RESET] and UI[6: START] to the same points as my digital inputs DI[5] & DI[6] and wire my switches to the DIs locations.
Then for example my start button on DI[6] will activate UI[6:START] to move the robot, right?
So configure UI[5: FAULT RESET] and UI[6: START] to the same points as my digital inputs DI[5] & DI[6] and wire my switches to the DIs locations.
Then for example my start button on DI[6] will activate UI[6:START] to move the robot, right?
Hi,
I want to start the robot with an external button (no PLC). I also want to give operator an external reset button.
Always the same program (Program Select = OTHER, $shell_wrk.$cust_name : MAIN)
I'm thinking that I need to monitor the state of the buttons through BGLOGIC.
Can anyone help with BGLOGIC and I/O config setup please?
Thanks,
Tom
So I guess, setting $SHELL_WRK.$cust_start = 1 invokes the UI[6] Start signal?
This will not reset the fault if one is present?
Thanks for quick reply.
I see the robot comes with R-30iB Mate Haptic controller with 2 peripheral I/O ports (28 DI & 24 DO) as well as connection to Model-A, Model-B and FANUC CNC)
Can you provide some detail on the macro program to accomplish this?
Also, what port assignment would I need for accessing my buttons on Model-A?
Hello,
Up until now all our robots have been connected to PLCs (set up by integrators).
We’ve just purchased a collaborative robot that will pick a part from the table and drop it onto a cart.
This time we don’t want to use a PLC but just wire in two buttons for the operator START & RESET.
Program Select = OTHER, $shell_wrk.$cust_name : MAIN
Program will run in a loop waiting for the operator to hit START. The RESET button will reset faults.
How can I wire my buttons and setup I/O so that RESET will invoke UI[5: Fault Reset] and START will invoke UI[6: Start] to make this possible?
Thanks for your help,
Tom
Thank you for your suggestion on increasing the severity of the SRVO-171 fault via the Error table.
How would I do that?
Tom
Hi,
I have a M-20iA robot with a R-30iA controller. It's part of a cell and it's been running for about 8 years without problems.
Recently I started seeing the following warning:
SRVO-171 MotorSpd lim/DVC(G:1 A:2)
SRVO-171 MotorSpd lim/DVC(G:1 A:4)
SRVO-171 MotorSpd lim/DVC(G:1 A:6)
Nothing changed over the last year as far as programming or speeds.
I tried to slow the moves down in the areas that I *think* the errors occur but the problem is I can't be sure where exactly in the program the warnings show up. The lines are scrolling very fast.
Is there a way (instruction?) to get the exact location/line in the program that causes the warning?
Also, does this warning imply that the motor/encoder is going bad?
Thanks,
Tom
Thank you for suggestions, I will try them next week.
Tom
Hi,
I need to be able to send active alarm to the PLC for data collection purposes.
Is this possible?
Thanks,
Tom
Great explanation!
Final question:
The robot is mastered to some position now but I don't know where.
Should I / could I Set Quick Master Ref right now, say at HOME pos so I could later Quick Master from that position if mastering was needed? OR would that required touch-ups?
Thank you for the reply Frank and RacerMike
I too have been taking images and backing up programs regularly.
However I have yet to reload an image.
I'm trying to guard against two possible scenarios WITHOUT RETEACHING POINTS:
1. Controller problem - I need to reload the image.
I have an image taken at the HOME location (can't get to ZERO on some robots).
The Lithium battery dies, wiping programs, data. Need to reload the image.
If I move the robot to the home location where it was imaged (scribed marks) and reload the image? Will I need to re-master?
2. Robot problem - I need to perform mastering.
Mechanic pulls out robot's alcaline batteries by mistake. BZAL alarm on all axis...
I don't know in which location the robot was originally mastered and I can't reach ZERO. What happens if I re-master at HOME but it was originally mastered at some other location, will all my thought points be off?
Thanks,
Tom
Hi,
We have a few fanuc robots here at work that I need to take care of in case things go bad. I have some programming experience but I'm a bit fuzzy on mastering/image restoration.
I may need to be able to restore controller image in needed, master axis when needed, etc.
1. If I'm ever going to have to restore controller image, do I need to bring the robot to the same point where the image was taken? Should I just take each robot to ZERO and image them again?
2. I don't know the location where the robots were mastered. Do I need to know this if I ever have to remaster them? If so, how can I find out the last mastering location?
3. Zero Position Master vs. Quick Master. What's the difference, which one should I use? (remember all my robots are working)
Thanks,
Tom
I should add that when the controller is turned on again those UO signals go down as they should. As soon as controller is up and running again, the UO[1 CMD ENB] & UO[2 SYSRDY] go back to OFF since there's a fault on the control.
Now that I thought about it, I think it makes sense since we have an Ethernet connection to the PLC. So the PLC remembers the last state before power off to the control. Once power is cut, the communication stop and there is no way for PLC to know that the robot outputs went down.
Am I right?
What I do need is a way to let PLC know that controller power went down, but this is probably not possible through the Ethernet.
Tom
Controller: R-J3iB
Handling Tool: v.6.40-1xI
Robot: R-2000iA/165
PLC controlling the robot through the Ethernet.
Seeing an interesting situation upon shutting down power to the controller...
Just testing my recovery routine by killing the power to robot controller.
However, with the controller powered down, I'm still seeing the outputs from the robot turned ON in the PLC.
For example, UO[1 CMD ENABLED] and UO[2 SYSRDY] are both ON in the PLC with the controller shut down.
I'm relying on UO[2 SYSRDY] in the PLC logic so that's a problem if the robot power is down and PLC is thinking the robot is ready to go and enabled.
Any ideas appreciated.
Thanks,
Tom
RESOLVED.
I haven't found any information on the port itself but after ringing the wires I was able to figure our where they went. As for the original problem of laser switch not turning the input on, it was because it was wired incorrectly. The coil of the input module used had 24V going to it instead of ground.
All good, now I can see my DI[1] turning on when the laser 'sees' the part.
Thanks
thanks for the reply. I did, none of them are on either.
Hi,
I'm looking for information regarding an "AS A2" connector on the arm of our R-2000iA/165 robot.
The original installer (that left half way through the job) installed a laser distance switch for detecting part present on the gripper.
That laser switch is connected to "AS A2" connector on the arm, has power and the output light switches ON when object is close to it. However, I don't see any DI[] being turned on when the laser switch is ON. I assume the laser output is connected somewhere, just don't know where...
My first 16 DIs are currently configured to Rack/Slot/Start 1/1/1 (internal i/o in the controller). But I don't think the laser sensor is connected there.
How can I find the proper rack/slot/point where it is connected?
Thanks,
Tom
Hi,
I'm setting up a cell and I need to take care of recovery in case of power failure. The robot will be started by the PLC using:
- Startup Method: OTHER (MAIN)
- UI[6. START] to start or resume
I'm looking at the following config options:
1. HOT START = TRUE
2. I/O power fail recovery = RECOVER ALL
6. Restore selected program = TRUE
I'm testing things in LOCAL mode, but once the system is all hooked up we'll run it in REMOTE with UOP signals.
However, I'm reading that HOT START=TRUE has to be used in LOCAL mode. Is this true?
Also, If I can use HOT START in REMOTE, what's your view on power failure recovery. Use HOT START to go back to where robot was before power failure OR setup your own recovery by recording current step in a register?
Thanks,
Tom
Got it. Thank you Sergei.
oh, so the mapping will allow me to set UO's. But this leads me to another stupid question...
Aren't the UO's signals automatically set by the controller based on the robot status? Aren't they sent automatically to the PLC to communicate the robot status?
UO[1: SYSTEM READY]
UO[2: PROG RUNNING]
...
UO[8: BATT ALARM]
why would I attempt to change those?