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.
"Alihan kardeşim ilgin için teşekkürler.."
I have read many different topics in the Abb documents, but I have not found a feature that exactly corresponds to the "Program Argument" feature in the Fanuc software. I was able to find the solution to the "OffsetCondition" problem that I opened the topic earlier and the problem of running another program Decently between the lines only by the method I shared in the picture. I would like to share it, maybe one day it will be useful for someone. By the way, I love this site, it doesn't end Dec.. Respects.
"Lemster68" Thank you very much for your interest. I started reading the documents you wrote from one side. I think I will find the most appropriate method for my own program logic. I'm looking at examples of the "function Present()" application.. Respects.
Greetings to all my masters, I am working with the IRC5 IRB2600 robot. I'm installing a fiber laser welding machine. From the "Add Instruction" section, I am calling a subroutine that I created earlier with the normal "ProcCall" command. There is no problem so far, but sometimes I want the robot to run between the lines that I Decipher, not all the lines in this subroutine. Fanuc also had Argument options such as "Call 1Prog(1,2)", and I could start the program I called on a single line from the desired line and finish it on the desired line. How is this work being done at Abb, I am waiting for help from my masters, regards..
Lemster68, thank you very much for your answer, but I would be grateful if you could describe in more detail how the topic you are writing is done with an example program or how the program I am writing can be done in the way you describe.
Respects..
I am still very new to Abb robot programming. I am making a welding program similar to the one in the picture on my Fanuc robot. In this way, my program has been working for years, and many of my resource programs are working smoothly.(Program mm or CNT values or program steps were shortened.) Now I want to do the same work with my Abb robot. Cont:IRC5 Robot:IRB2600. How can I write a similar program at Abb, I am waiting for help from my masters.
Elderwild, for explanation thank you...
Yes, I bought a new battery case, I will replace it and try it next week. Thank you for your interest.
The "SRVO–136 DCLVAL" alarm may not usually be written in this way, it should be written together with an alarm such as "SVAL1-IPMAL-DCLVAL-FSVAL". Along with it, it must be giving another "SRVO" malfunction. As an electronist, I can say that this is the type of malfunction that I am most annoyed with in a robot. It's very true that you look at your book and try to make the fault, but I choose to proceed by looking at what the LED indicator of the driver's card says first in all of these faults. I have never found that the transformer or DC voltage is problematic, or that the E-STOP card is the cause of this malfunction. Whenever I see a "DCLVAL" malfunction, the first thing I do first is to change the driver's card, otherwise you do it according to the order it says in your book, but you can't find any kind of malfunction, which makes me very tired. Because even if you do voltage monitoring with a multimeter, the driver's card is definitely tricking me.
kluk-kluk,
Yes, I'm talking about four large batteries on the robot. The battery case had oxidized due to liquid contact last month, and we had opened and cleaned it, and I had thoroughly cleaned the metal bearings where the batteries had settled. In fact, I couldn't repair some metal parts and found other solutions that would do the same job instead. After this procedure, the robot has already started to forget the calibration values every week. As you wrote, let me review and check the repairs I made again, you're right, I may not have been able to make a successful repair.
