I'm not sure about the s4c controllers, but on an IRC5 when that happens it means the teach pendant doesn't see the center position and turns off the joystick. You'll have to replace the joystick or teach pendant.
Posts by bob865
-
-
Hello all. I have a robot that keeps giving me a Servo Lag Limit Exceeded on Axis 5 which also makes it lose safety sync. It always does it in the same position, but it doesn't always throw the fault. Recovery is relatively simple, drive the robot home and re-sync and re-start the robot, but this shouldn't be happening. It is a 7600 robot on and IRC5 controller. We have tried changing the upper belly pack (axis 5 and 6) but that didn't solve the problem. It wasn't long before it faulted again. I see there is an option for changing the servo lag limit for external axis motors in the safe move configuration, but nothing for the robot axis. Has anyone seen this or have an insight as to what may be causing this or a possible solution?
Thanks!
-
Start by pressing and releasing all of the e-stops on your robot, i.e. teach pendant and cabinet. IF that doesn't clear it, press and reset all of the external e-stops.
-
I believe I have seen this before and it usually ended up being cabling(belly pack). It is a problem in the resolver cable making the SMB board see movement that is not actually happening. Though I should mention when I have seen it, it has been on an external axis motor for an electric servo weld gun. I have seen it on robot axis too, but when I've seen it, they have been one time things. But I would start with the belly pack and then go to the motor especially if it has only been one axis and always the same one.
-
There is a software sync option too that doesn't require a hardware switch. That is what we use. When we go to sync a robot we have it move from a home to a sync position (MoveAbsJ) and then verify the position visually and it syncs the robot.
-
You would have to jump out all of the stops (auto, general, e). Then you should be able to just run it in auto.
-
I'm not familiar with the S4 controllers, but on an IRC5 if I had the kinds of symptoms you are describing I would start with the PC. I would make sure it had power. If power was there I would change the PC and if not then I would work backwards through the power system.
-
Are you talking about the belly pack? The power and resolver cable that runs to each motor? If so there isn't a upper and lower cable pack. It's all one pack. You have to replace the whole robot at once on a 6640. Best thing to do is lay the robot out as flat as possible (if possible) and start. Pull the covers off each motor and sstart pullig the cables through the robot.
-
Sounds like one of the motor contactors is either bad or the aux block is not making the proper connections. When you pull in the deadman and the system tries to activate the 2 motor contactors it has a 2 channel check that runs through both to make sure they pulled in and pulled in quickly enough. You'll need the prints but start there. You can start with a basic visual check, pull the deadman while watching the contactors and verify they both activate. If one does not start troubleshooting there. If they both do and then deactivate start checking the signals on the aux blocks.
-
Most are using resolvers instead of encoders. Resolvers are much more accurate and allow for more precise positioning of each axis.
-
Found this to work. I want to test it more to make sure it doesn't have any unforeseen issues though. I'm also going to try to reltool idea. Thanks everyone.
!pose for the calculation
VAR pose pseFrame:=[[0,0,0],[1,0,0,0]];!Translation in Z-Direction
VAR nDZ:=20;!Get the data of the old tool
tNewTool:=tMyTool;!assign translation for z-direction to a pose
pseFrame.trans.z:=nDz;!Calculate translated tool
tNewTool.tframe:=PoseMult(tMyTool.tframe, pseFrame); -
I tried it last night on a test robot and confirmed it does not do what I want. It will move it in Z of the faceplate of Axis 6 or the equivalent of moving in Z of tool0, but not along the Z axis of the tool being modified. The XYZ of the tooldata defines where the TCP is in space in relation to the center of Axis 6, but not its orientation. That comes from the rotation (q1, q2, q3, and, q4). So by changing the Z only in tool data it only brings the TCP closer/further away from the faceplate of axis 6, not moving along the Z axis of the tool. I need the move to account for rotation of the tool also. I investigated the other commands you suggested and they are not going to work for what I need. They are for doing a calibration of a TCP by teaching several robtargets and then running that line with the taught robtargets. It's basically the command behind the TCP teaching methods.
I'm basically looking for the math to say, based on a line defined by Q1, Q2, Q3, and Q4, if I start at XYZ and move along the line Xmm, what is my new XYZ coordinate.
-
My understanding of TCP that would shift the TCP in Z, but not the correct Z if that makes sense. Forgive how crude my drawing is, but I think the instruction you provided will move the direction of the faceplate of Axis 6 (XYZ may not be correct, but they should help clarify what I'm looking for). I'll look up the other commands as well and see what they do and if they may can be used. I'm expecting a change in Z to result in a X and Y assuming the drawing is correct.
-
Hello all,
I'm hoping I can get some help with a project I'm working on. What I need to do is offset the TCP of a tool. I've looked through some old threads and can't find an answer. I have a tool, but the working direction of the tool is not in line with axis six. It is off at roughly 45 degrees. I need to move the tcp along the Z axis (working direction) of the tool, but because it is at an angle to axis 6 of the robot, I can't simply change the Z value in the tooldata. A move in the Z direction of the tool would end up being a slight change in X, Y, and Z of the tool. How can I figure out what the new values would be? I need to know how to calculate this mathematically. Ultimately I will be building a function/routine to do this calculation on the fly so if there is already a function built that does this arithmetic that would be ideal.
The application that I'm working on is a non-robot version of the MeasureWearL command for measuring the tip wear on weld guns. What I need to be able to do is after I determine how much of the tip has been ground off during dress, say 2mm, I need to be able to update the TCP of the weld gun by the same 2mm in the Z (working direction) of the gun.
Any help and or ideas are appreciated.
Thanks.
-
Thanks guys. I felt sure that was the answer, but I thought I would check and make sure there wasn't something out there I wasn't aware of.
-
Hello all,
I am using a Continuous InkJet printer to make some parts. For the printer to work right, the part has to move at a constant speed across the printhead, otherwise the print will stretch or shrink. We are starting the print with a MoveLDO command triggering the printer. But there is some ramp up and down speeds and it takes some trial and error with the teaching to get it right. Does anyone know of a way to execute a move where the robot will run a constant speed with no ramp?
Thanks.
-
Use SearchL. I've included the link below. We typically use an ultrasonic prox switch for a slow down and a second prox(depending on how you're doing it) for stop. I don't think I would use the vacuum as a stop becuase if you had a cracked cup or something, it might overdrive the search and crash your gripper. You could use the vacuum on/off as a part present check instead. I've also copied a sample we use for slow down and stop searches.
SearchL\SStop, DI_SrchSensor_2A_G1, pSrchPos, pSrchEndPH1Lwr, v100, tGrip1\WObj:=wobj_PH1_Lwr;
SearchL\SStop,DI_SrchSensor_1B_G1,pSrchPos,pSrchEndPH1Lwr,v50,tGrip1\WObj:=wobj_PH1_Lwr;http://developercenter.robotstudio.com/BlobProxy/manu…ual/doc151.html
-
If both tools are the same I would update the tooldata first before doing anything else. From there check the tool on the moves and make sure the correct tool is loaded. i.e. if the move doesn't have a tool assigned to it the robot will use the wrong tooldata and in turn wrong loaddata. If all of that is good, you can use the tune motionsup command before the moves that are giving you trouble. Below is the ABB developers reference to the motionsup command.
http://developercenter.robotstudio.com/BlobProxy/manu…nual/doc92.html
-
This answer is based on an IRC5 cabinet, but I would assume it would be similar between older cabinets as well.
Run a backup on both robots. The MOC.cfg and EIO.cfg files will be in the syspar folder. Load them into a compare program or just look at them side by side and look for differences.
-
I had a robot give this error last night. We were able to reboot the robot and clear the fault, but I was trying to find some information on it in case it comes back. All I was able to find is a reference to it in the IRC5 operating manual that refers you to ABB. Has anyone seen this or have any information on what it means?
Thanks.