Your" PRIO "errors probably had a" Fanuc PLC " installed in your control cabinet earlier. This PLC configuration is now unreachable. So a PLC has been introduced, but that Plc is not available now. Complete Disassembled, not working, or may not be connected. But I don't think this mistake will stop the robot from moving. At least you can move the robot by holding down" Shift+Reset " and ignoring the error. The" SYST-037 " error means there are no UOP signals that should be present. Probably your remote switch is malfunctioning. You can open the control and control it by looking at the picture I sent you. You can experiment by temporarily short-circuiting cables for the" ON " position. The robot will not move without removing the" SYST " error.
Posts by byrol
-
-
The" MCTL-003 " error has nothing to do with the safety circuit. He tells you that you have to fix them first and then try robot movement because you already have other mistakes. There are other errors, and these, he says, prevent the robot from moving. RJ2 robots made me tired of being an electronicist. Looking at his name, I think he's in my country. I try to help.
-
I do not understand how a 1.5 V battery can be removed from the new box and installed. One of the new batteries installed on the robot is defective. Sometimes a total of 6V seems to be 5.2 V in the control with the measurement tool. So no matter what we do, we don't have a healthy calibration. Now I have another problem. I calibrated zero position master on my robot. My robot works my way. I get a "MOTN-063 position config change" error when we want to run programs previously. Is there a way to fix this problem without reinstalling programs?
-
Hi SHIFT_Lock,
Before your answer, I sent a message to our friend Racermike123. Because my robot's batteries were completely dead, he described a method like "Pulscoder reset=RES_PCA / CYCLE start / CALIBRATE". So he tells me to make a new calamity. Although our robot probably gave one or two "srvo-062" errors, it continued to work and finally the batteries were completely discharged. My robot has backups of "all of above" files. I turned on my robot in "control Start" mode. Old backup "sysmask.sv" load file. I continued with "FCTN/Cold Start". I did "$Master done=true". When I did "Master/Cal=calibrate" I received the message "Calibrated". I get a "srvo-038" error when I want to move. Now I want to try something like this. After opening "Cold Start" Mode, Click "Master/Cal=RES_PCA then cycle start". When the robot is turned on again, I will do "$Master done=true". Then I'il do "Master/Cal=Calibrate". See how that goes. I continue to work on.
-
My cables are for rj3ic, but I am repairing them according to this scheme when they are broken. Maybe he'il help you.
-
Hi SHIFT_Lock,
I don't have factory calibration values. The calibration values in me are just the values I send pictures on the top. I don't know how to solve this problem without having to rebuild the programs. How about I calibrate according to zero points without taking into account my calibration values? -
"RJ3IC:R-2000ib" is a robot that's very far away from me two days ago, the robot's batteries are exhausted. Before the robot batteries were exhausted, "srvo-065" showed the error occasionally, but of course the operator did not take into account. As a result, all engines have given "srvo-062 BZAL" error as in "Picture 1". Battery change has been made. Then, "RES_PCA" was resetted from the "master/Cal" menu. After turning the robot off/on, he no longer showed the error. But the robot showed the "picture 2" error when we wanted to move in the "word" position. When we checked the settings for "$DMR_GRP" we found that "$MASTER_DONE:false" as shown in Figure 3. I wrote the old "MASTER_COUNT and REF_COUNT" values on paper without changing any settings. These values can be seen in "picture 4/5". I read all the articles on the site on the subject. I tried the "quick master and zero positon Master" methods individually, paying attention to every detail described. I've even tried many ways to calibrate our old values by entering them on the keypad. We calibrate and get the "CALIBRATED" message. However, when we move the position "word" after all, the robot "X Y Z" is doing the movements in a very irrelevant way, as is the case with the video I upload. When we run our old programs after calibration in this way, it seems to be working normally, even though we don't test them in detail. But it's hard to create a new program with these moves. I've been trying for two days, and my head's about to explode. I've already calibrated a lot of robots in this model. I've got the image files before my robot makes a battery error. It takes hours just to describe the calibration work to the operator. The robot's battery was replaced while the robot was operational. What more can I do to get everyone to act in the "word" position as they know it? I'm waiting for your help.
-
I've done a similar work on a robot I've configured before. It's not something I remember a lot. I took advantage of the document I shared your picture with. However, both the robot side and the PLC side of the security card "slot 0" i remember introduced. I remember starting the normal "Di/Do" configuration from "slot 1". I'm sorry I can only help you at this level.
-
-
Maybe he can give you an idea..
-
That's how he described it in the book.
-
Since the program is usually done in the "world" motion mode, I think it is difficult to send the individual speeds of the motors as an analog signal. For this, I think it would be more appropriate to use the " TCP " feature (that is, a center point introduced for the tool used).
-
"Fronius crashbox" last year I had it installed somewhere, but I do not remember the details exactly. This is already a feature of the source machine. If your source head goes from one point to another, and the operator forgets anything on that path, the source head will be hit and out of place. You can get this displacement signal through the welding machine. He needs to explain this in detail in his book. Then you can use this signal as desired via the robot menu. "Tony" is another method my friend says, and it can be run through the "EE" connector. But as I recall, the source head does not have a cable outlet attached to the robot's "EE" connector.
-
I don't think this is due to the system, the software. I have robots that I've made mistakes with on the control panels. Usually the cause of the failure is short circuit or disconnection of the control cable. Another possibility is that the electronic parts on the card inside the control can be a problem.
-
I sent him the documents he was looking for and he was very pleased.
-
After such a high power failure, you've solved quite a few problems. This is the electrical problem when the "DeviceNet board" card in or out of any one of the input and then caught in the open case your card may be damaged. If you are already feeding your card directly from your robot card, you can solve the problem by following the voltage with a simple measurement tool. I don't know what serial card you're using, but ultimately the "DeviceNet" works with an ordinary 5-6-pin control cable. Voltage except for the ends, you can understand the problem by disabling the other three.Also, the alarm you receive means that you can no longer reach an I/O module configured.
-
If the welding machine is operated manually, then there is no malfunction in your power supply. If you get this error when you switch to automatic mode, you probably have a configuration problem in your source control parameters and an overload occurs when the source is called. Check the parameters of your welding machine on robot menus.
-
The two cards you write can work interchangeably. It means that the version upgrade has been made only as a result of the structural changes of the electronic materials used. If your old card is working normally but you want to take action, you can recover the card by changing the group of bobbins on the mosfet group and the mosfer group. However, if your card does not pass the general tests from the first opening, it can be obtained by replacing the electronic materials with both battery and capacitor features on the card. If there is no light on your card and it is not working at all, the watt type in the power input section of the card is probably protected by a high resistance.
-
Considering the error code, you need to change the settings of the Slave Module you added. Many settings you make seem right. The value "Input / Output Bytes" appears to be 10. You have determined this value according to the module you used. Although I have 10 bytes input output, I do not understand how the "Config Data Bytes" value is 3. As stated in the GSD file, you have to enter the value of the module you have used and the byte range that it supports. It would be pointless to use 10 bytes according to your module structure. Either 8 bytes or 12 bytes. According to the file you sent, the input-output is 12 bytes, let's accept the sample. "Config Data Byte: 2 Config data detail must be 9B-AB so 155-171". I also don't need to use "User Prm Data". The initial value may remain. I think there is no other module structure in the connection structure. You can change the "Station Status" 184 (B8h) to 136 because "0" appears in the GSD file. You have found that "Dpram input-offset" values are calculated by calculating the method, so the robot book should be describing how this section is calculated.
-
Suppose your robot is r30ia. Says you should check the other alarms that he gave you in the alarm description.