Posts by byrol

In my opinion, if the errors in the picture already have the error "SRVO-023", it is normal to have it in other errors. That's the most troublesome fault anyway. A fault path such as the driver, motor cables, cables between the controller and the robot, voltage control and monitoring, and then changing the motor can be monitored Decently.

A robot is probably being used in the automatic working position. If the pendant robot freezes while doing automatic work, there may be many reasons for this.

-The executed program may be too long or there may be too many subprograms or cycles in the program. The buddha will pile up after a while and the controller may freeze.

-The main program running on your motherboard The motherboard may freeze after a while due to rom or ram problems. That's why Fanuc told you to compare the lights of the motherboard when the robot is working normally and the controller is frozen.

-Another reason is a voltage leakage caused by your power line or a similar problem that affects your robot and the control may freeze. In particular, I have seen that the voltage fluctuation makes the controller inoperable and causes problems, and even the software becomes inoperable.

-Testing it by making an exchange with a working version of the pendant and cable may also give you an idea.

-After turning on the robot, waiting for hours without running any programs to see if the controller freezes will also give you an idea.

In the "Customer Registration" section, it is necessary to check whether the "Auth Key" is still valid. A new key may be required. Why was it installed from another backup when it was possible to make corrections on the existing software?.. "Reg.No " the key is that the robot may not be compatible with the main software.

Your Profibus card is installed in the I/O panel, that is, where you see it as an input and output card. The upper part of this card is the robot's manager and the slave is the place where the output is made to a card. The lower part is where the robot is a slave and the cable from the manager needs to be connected. The lighting of the red led does not cause your profibus card to work or your robot to have software delays. This is all about the configuration of the card. If you remove the configuration of the slave side of your card, the red led will turn off. If your Profibus card or servo drive card is defective, this may cause a slowdown in the software. We need to take out their connections and try. In the case of CMOS error cleaning, if the program that your robot is running is doing a lot, a lot of repetitions, and the program repeatedly calls another program in the loop and always stays ready by waiting for an external command, this may lead to RAM stacking after a while. In it, you can use the ram cleanup section in the FILE menu, but the program structure may need to be revised and shortened. If there is no software backup available, it may also be a solution to make a backup of programs and configurations and install a new INIT on the BMON screen. However, this job will restore your robot to the latest new software installation. The first software in FRAM may still be healthy.

Key code "XBCD10612S11" it may be necessary to check the positions of this with a measuring device. I'm talking about the "T1/T2/Auto" switch. It's short-circuiting multiple locations at each location. He doesn't make mistakes when he short-circuits one place and doesn't do the other, but he doesn't work in that position. -Numbers key pins,

T1 = 5+6 jump 7+8 jump 11+12 jump
T2 = 5+6 jump 7+8 jump
Auto = 1+2 jump 3+4 jump 9+10 jump 11+12 jump

Even if the batteries located at the base of the robot are not installed, it does not make the robot slow in software transitions. I don't think it's from the batteries in the base. In the picture, it also appears that the battery that should be installed on the CPU card is not in place, it must necessarily be installed and intact. There must be a software backup before starting the work that you will do with the CPU card. It may be that the software cannot make a healthy boot because it is corrupted, or there may be a problem with the rom memory in which it installs the software. But when you remove the rom memory on the CPU card, the software will be deleted, which is very important. A disconnect or short circuit in the control cable can also give this error, as well as there may be a problem with the control itself. It will be healthier to start with interchangeable hardware instead of trying to enter the CPU card. Even if it disconnects the cables from the servo floor to the CPU and gives an error, it can still be checked whether there is a slowdown in the software.

I don't want to give bad news like a bad messenger, my friend, but I think you're doing a completely wrong job. I have been working with the DOM disks I mentioned for a long time. KUKA's old robots made me feel very tired about it. In industrial robots and machines, the system will work like a time bomb no matter which disk you insert by converting an apparatus or similar disk instead of an IDE disk. If the previous correct working disk of the system is IDE 20gb, the disk you will replace should also be the same. If the previous IDE is 5.6gb, it should be the same again. In addition, the image retrieval process, which was performed on the computer with the operating system installed, must be rewritten with a computer using the same operating system again. I have used many different operating systems such as QNX, KDE, GNOME, and I have dealt with ver failures. Even the fact that the Bios has seen your disk or that you have correctly inserted your image file into it does not mean that it can work normally. That's why I still use a Pentium 2 with an ISA slot on my desk, and it has WIN95 and OS in it.I always have a card with a 7.0. Especially since WIN98 is one of my saviors. Even the version of the Ghost-like software that is backed up is important in this regard. Also, if the DOM disks recognize the bios as LBA,ATA, it means that they cannot be booted anyway. I wrote too long, I'm sorry, my friend...

In other words, when you press the button on the controller, you need to look at the side of the small electronic card connected to the large relays that you hear in the cabin.

Evinwilson,

Yes, there is no door switch, but there is a door switch connection place in the cabin. The necessary wiring location for this switch is not only on the "EM-Stop Card" on the back of the cover when you open the cover. In the same way, when you open the cabinet for the door switch connection wiring, you will see 1 or 2 small green electronic independently mounted cards that appear on the underside at the back of the switch. A lot of my friends who do robot work, including me, actually don't know that these cards work like a door switch or an external stop, because most of the time they are either not connected or not needed. In my opinion, there is a problem with the jump cords on those cards. The door switch error made me struggle for 2 days, and then I found those cards difficult by tracking the circuit from the diagram.

Skooter,

Since my robot is located in a different country, I have difficulty getting along with the user and operator. The last time we checked, they told me they were using Industrial "D" series batteries. But I'll have it checked out again. Thank you for your concern.

ssaul,

My robot is not mounted on a servo-based location, but on a fixed base.

Mortoch,

Yes, there may be corrosion behing the box, I never thought of this. Thank you, I will check.

Yes, there is a "SRVO-062 SVAL2 BZAL" alarm. But before the working time we are talking about or another year, the batteries run out.

Hello to everyone, "Controller:R-J3IC Robot:R-2000IB 210F" My robot runs out of calibration batteries after three months. Although it is actively used every day, we see that the batteries are exhausted when we turn it on in the morning after a month or two. When we disassemble and look at the batteries, sometimes the battery voltage seems to be over, and sometimes it looks normal. The battery case is clean and there does not seem to be anything like oxidation or non-contact. Jul. Where the fault is likely to be, I am waiting for your help.

Of course, what I wrote does not mean that your "CPU" card is not faulty. Your "CPU" card may not be able to run the main software.

The work done by "SR-3ia" robots is generally continuous, the program is intense and consists of too many repetitions, so the file in which the "DCS" parameters are recorded may be corrupted. Cleaning the "RAM" in the software, reloading the backup file in which "DCS" works without any problems, or making abbreviations to eliminate the clutter in your programs can solve the problem.

When you say that we have done the external Oct configuration, you are doing them in the "CNTR START" position, right? Or in the "COLD START" position. October October otherwise, many axis settings will not register, especially when you make axis limit definitions and restart again. Therefore, when you take a backup of the robot and open it on the computer, it will give an error in the Oct limits you have written. If you do not do the correct steps in October, the axis will be introduced, but many configurations will remain in the "DEFAULT" settings of the software.

I have encountered this fault before and definitely your IPM module is defective. There is no need to look for the fault in a different place. The module also has protection diodes at the power input of the electronic board, which it does because they leak voltage. The IPM module needs to be changed.

It looks like an error that came to the screen before the battery error. You may need to look at the wiring and especially the emergeny stop connection. Also, the error code may be 20527, not 527.

It is not possible to solve this problem without changing the cable. You have already mentioned the subject, but I am definitely against trying these methods of "taking the brake in vain, suspending the robot with the help of a crane" while the cable failure is continuing. It has happened to me many times that when the cable is faulty, moving the robot leads to a much bigger malfunction. I'm writing this as someone who damaged the driver card or CPU card. If there is a break in the cable, it may not be a problem, but if there is a short circuit, your failure may become impossible. I don't think anything mechanical is removable either, and wherever you need to disassemble to replace the cable, whichever closed cabinet you need to disassemble, I think just disassemble it.