Are you jogging in joint mode - or Cartesian?
Posts by Iowan
-
-
We had an IRC5 controller that would occasionally throw up the overheat message. The machine vendor installed a (software) patch from ABB that changed how temperature sensors were checked, and problem hasn't returned.
-
Does it keep counting up? Sometimes it's a bad connection between pendant cable and controller. What vintage controller? Here is a procedure for deleting a corrupt image.bin file - IF controller is S4C(+?).
-
You are awesome, that did the trick! Thank you.Hmmm... Then I won't bother suggesting checking under Shift-Disp (wouldn't help anyway...)
-
Could you post a picture of the diagnostic page/window?
-
The Handling Tool eDoc has sections on using offsets (6.4.10.6 Offset) (6.4.10.7 Offset Position Register).
Another article that might be helpful. -
Some systems accept the password - they just don't echo to the screen (not even a *). I haven't seen the edoc, so I had no luck w/ the username/password combination.
-
-
-
KVA is on ID label. Power consumption would depend on load, duty factor, etc. A clamp-on power meter might provide the info you seek.
-
Pardon my anal retentiveness, but isn't housekeeping and return at the end kind of redundant since you'll return at the end of main either way and the first thing on the list of todo's is housekeeping.Yeah, machine came in that way - just never got it cleaned up. Not the best programming example - maybe I'll clip some of the extra stuff...
-
Code: EIO.CFG
# EIO_GROUP_PHS = EIO_SIGNAL: -Name "StyleSelect" -Type "GI" -Unit "BOARD10" -Phsig 56 -Length 4 -Name "StyleSelectAck" -Type "GO" -Unit "BOARD10" -Phsig 56 -Length 4\ -Store
Code
Display More... style_no:=GInput(StyleSelect); SetGO StyleSelectAck,style_no; TEST style_no CASE 1: WaitDI Initiate,1; Set InCycle; rRoutine1; CASE 2: WaitDI Initiate,1; Set InCycle; rRoutine2; ! DEFAULT: ENDTEST ...
Variables need to be defined...
As another example: -
A few years ago, we upgraded a robot from an S4C+ cabinet to an IRC5.
Upgrade was done by machine vendor - working w/ ABB.
Dunno if motor models will cause any problems - seems like every time we need to replace a motor, we get a different replacement number. -
Check position on axis 5.
I'm kinda rusty on Fanuc's - I'll have to go check a machine to see how ref pos'ns are set. Are you using the same userframe and tool?
Another thing to check: if axis 5 is near Zero andlinear interpolationCartesian REPRE(sentation), you may be hitting a singularity. Try changing to "joint" mode. (I need to look up correct terminology, as well). Singularity might be an entirely different problem... -
Quote
SRVO-050 SERVO Collision Detect alarm (G:%d A:%d)
Cause: An excessively large disturbance torque is estimated by the servo software. A collision was detected.
Remedy: 1. Check whether the robot has collided with an object. If so, reset the system, then move the robot away from the location of the collision by jogging. 2. Check that the applied load does not exceed the maximum rating. If the rated load is exceeded, reduce the applied load. If the robot is used with an excessive load applied, the estimated disturbance might become excessively large, resulting in this alarm being output. 3. Check each interphase voltage of the three-phase voltage (200 VAC) applied to the servo amplifier. If the applied voltage is found to be 170 VAC or less, check the input power supply voltage. 4. Replace the servo amplifier.
You've checked voltages?
Realizing that you'll lose mastering, you could pull the motor and try driving it and the other axes.
That'll also let you check for binding in the joint itself. -
Without having specific answers, I suspect the conveyor (encoder) needs a reset of some sort - otherwise, the conveyor will take the part outside the robot's reach.
-
Check for incoming AC at X1 connector (bottom right corner of power supply). If there is no power, check at the disconnect. You will probably have power there - since the fan is spinning. If there IS power at X1, the power supply may have failed. I'll check the schematics - it'd be embarrassing/expensive to replace a power supply for a blown fuse/breaker.
-
Either TPWrite or TPReadFK could be used to display messages - The TPReadFK example has the advantage of requiring an acknowledgement - IF the Op actually reads the screen.
-
I'm a bit confused by the range error - Are you using different user frames for the two plates - or is there an encoder tied to the conveyor?
-
I'd start by verifying the power supply. It should have a status LED - red for AC OK, Green for AC/DC OK.