Follow this link for explanation.
https://forums.robotstudio.com/discussion/109…obotware#latest
Follow this link for explanation.
https://forums.robotstudio.com/discussion/109…obotware#latest
If your zero position looks good and your calibration offsets are correct, you should be good to proceed. If you want to be extra cautious, you can teach a few points in the cell that you will be able to move to after the motor replacement. Is it a large robot? If so, they typically replace the whole wrist. Whatever the case, the replaced motors should be fine calibrated, then recheck your zero position/rev counter check position. Then, if you taught some verification positions, you can go to them to check further the success of the replacement.
Thanks for the heads up! Good call.
Maybe you are thinking of the XRC controller (misread)?
This is the latest and greatest YRC 1000 controller.
It's strange. The names have to be somewhere.I have even named some of my I's, D's, etc.
I don't see the names of those either.
I see, idk why they jump back and forth through the alphabet when then name controllers. MRC, XRC, NX, DX, now YRC, they seem a bit scatter brained. Now that you mention it, yes, we do name some of the bytes and what not, but no, I don't see their names in the VAR.DAT.
Also, you would need to edit your old VAR.DAT to have enough position variables to match the new VAR.DAT after you increase the number of position variables. We have had controllers really take a crap when you try to load in a mismatched size VAR.DAT.
Ours are not that old, so I hope it is the same. Starts with /B =byte, /I =Integer, /D = Double integer and so on. /P = position variables start at 150, if your program that you use to view lists line numbers. We don't name our positions, so I cannot tell you if the names would be stored there.
VAR.DAT Which controller revision, btw?
The brakes are not releasing, they are engaging, but slipping.
I would go with the robot sticker, if that is no good, you have the other numbers to re enter.
Look in the backinfo folder on a backup.
That would be one of the things that I would check if not getting good tcp's. Try jogging in world linear and watch carefully for it to go in a straight line, not veering or arcing. Joystick lock is good to use to make sure you don't have accidental deflection. Also, verify that the installed system matches the actual robot type.
Calibration offsets will be on a sticker on the arm or in the cabinet. They factor in determining the correct positioning of the robot. One of the first things that need to be checked when commissioning an ABB robot.
Do you have a MoveAbsJ with all zeros in the jointtarget? If not, make one and step to that position, then verify alignment marks. Have you verified your calibration offsets?
If you are still looking, look at this:
See technical reference manual - system parameters
It goes a little something like this:
SUB P0026 P0026
SETE P0026 (3) -5000
SFTON P0026 TF
Move
Move
SFTOFF
Subtracting P0026 from it self to make sure that it is null, 0's. Set the third component to negative 5, 50, depends on how many decimal places your variables have. Shift on in tool frame "TF" tag. Make your motions, Shift off.
Position variables are just a globally stored position. You can access them and move to them in any job. They can be stored as pulse, robot, base or user.
You have to change the base frame, which tells it that it is inverted. Also, change the gravity beta which will ensure that the collision detection takes into account the reversed effects of gravity.
The other picture showed "10036 Rev counter not updated". Maybe try to update it first?
You can't. No enable means that you cannot move robot. Caused by system failure state.
This one stands out as a possible cause:
2. 38031 Error: Resolver signal error 0307 17:54.29
Too low resolver voltage detected on
joint irb_4.
I see it repeated quite a bit.