Your edit is correct, the DQC256A is what you need. The DSQC228 was for the S3 M91-92 controller.
I usually can get past these alarms with slight changes in tool z-axis rotations for the start, corner and end positions that decrease the amount of travel for the affected axes, in this case R & T. Slight changes in torch angle and increasing the corner PL may also decrease the amount of joint rotation enough to consistently run without the alarm. I do this before lowering speeds.
Not sure for this bot. A very long time ago, on the TA series, a cover is removed at the back of axis 1 and battery packs with 6 AA lithium batteries plugged in to the resolver cards.
I assume the positioners would have their own card & battery pack for their feedback.
This attachment is from the "European XRC Controller UP130/UP165 CE Manipulator Manual", part # 144965-1
It is the same drawing as in several XRC2001 manuals. Hope this helps.
The +15V & -15V from the power supply go to the drives & DC Link. The 39105 is generated by the DC-Link if the +15V is out of tolerance. When measuring the +15V & -15V, also measure with the AC scale - there should be less than 20mV of AC. This is a typical problem with these power supplies.
With the power on, disconnect one battery at a time and measure its voltage. Both of the lithium 'D' cells need to measure over 3.6VDC. Always check battery voltage on new batteries before installing - they should measure 3.70 to 3.73 volts.
Battery life depends on many things. The amount of time the controller is off is the obvious one but some other possibilities are:
- Improper storage of the battery before it was installed. Battery shelf life decreases with temperature.
- Old battery that was sitting in the back of a inventory bin for the last 12 years before being found and used.
- Damaged from being dropped may diminish a battery's capacity.
- Manufacturing defect. Murphy has laws regarding this.
- Cheap aftermarket battery. Some of them are cheap because they use questionable batteries. The vendor we purchase from uses the same Saft batteries and protection ABB uses.
- Bad component on one of the computer unit circuit boards or backplane causing increased current draw when the controller is off that depletes the batteries sooner.
The IRB6400R robot was used with 3 controller models: S4C (M99), S4C+ (M2000) and IRC5 (M2004).
All 3 have different battery configurations. Which controller is this one?
Could you supply the actual error number?
The 37057 Serial Measurement Bus communication lost error is the axis control board in the Computer Unit not receiving communication from the Serial Measurement Unit in the robot and/or if you have an additional SMU for external axes.
- Serial measurement cable between robot and controller for proper connection and damage.
- Connections on the Serial Measurement Unit in the robot are seated with the thumb screws tight.
- The connectors on the Base Connector Unit and Computer Unit are seated.
Are there any external axes?
Which batteries are "both" batteries?
What is the error code number?
The NiCad battery pack that the 3HAC6550-1 charges allows the Computer Unit to image the controller memory when the controller is turned off.
The lithium battery pack located in the robot and plugs in to the SMB backs up the rev. counters.
Yes the brakes click when trying to jog it. (I lightly touch the joystick so it just releases the brakes and not tries to jog an axis)
Although as soon as I go to move any axis it just cuts out with a quick judder of each axis then comes up with the Joint collision/speed error.
Just another thought - did someone accidently update the commutation offsets?
Make all axes are set to the default 1.5708.
You can reload the MOC.cfg from a backup before this happened.
Can you hear the brakes release (click) when you try to jog?
If no click, does contactor K44 pull in when attempting to jog?
If K44 pulls in, is there +24VDC on K44 terminal 4 when it pulls in?
If no 24Von K44-4 when it pulls in, is there 24V on K44-3 when pressing the deadman?
Try leaving it off for a longer time and see if it dumps the operating system.
Try reseating the 3 computer boards. Reseating them will dump the operating system. Also be careful of the brittle plastic front covers when trying to pull the boards out.
If none of that works, try replacing the Robot CPU first.
Had the 38600 and on rare occasion it would also give the 38644. Traced it down to a breakdown under voltage of the insulation of a motor wire in the controller-to-robot motor power cable. Found it with a megger (insulation tester) set at 500V by disconnecting the motor power cable from both ends and checked each wire to the cable shield wire / connector shell. After finding which wire, took the connector shell off and found that wire was too short and pulled tight on a sharp edge that was cutting in to the wire enough to breakdown under high voltage of motor power but checked fine with the very low voltage of an ohm meter.
Have you swapped the entire controller-to-robot motor cable with the other robot?
Are the brake release buttons on the side of the robot still not working? If they are not working, check for 24V at contactor K3 terminal 22 with motor power OFF.
That is the key disk prompt screen that appears after the controller passes its cold start hardware diagnostics. Part of the diagnostics is to measure the controller batteries and it should report them low if the batteries were a problem.
New question: After reloading the system, power the controller off and when turning it back on, does it reboot back to the warm start screen?
I also can't help wondering if someone is cold starting the controller.
Make sure contactor K3 pulls in when you enable the deadman and slightly move the joystick. Measure for +24VDC at contactor K3 terminal 8 with the K3 contactor pulled in. Also verify that wires 364 & 365 are connected to K3-8 and wires 313 & 314 are connected to K3-7.
I feel the best thing to do is verify the 24V for the brake release is making it thru the contactors. The simplest way I can think of is to verify contactor K3 is pulling completely down and there is +24V at K3-8 when it does.
sometimes the system is gone
Can you provide more detail on what the controller and teach pendant status is when the "system is gone"? Do you find it with the teach pendant locked up, error messages, asking for key disk … ?
S4C. The 2 batteries in the first picture are for the controller memory and are the only ones in the controller.
Under what circumstances does this happen? What is its status when it happens?
Have you moved the robot to zero and verified mastering? If mastering is good, does this affect both linear and joint positions? Is it just the PR's?
Since it's an M-20iA, check the casting around J3 motor and make sure it's not cracked.
It could be there is no longer a problem but there was one when it was first programmed.
From my perspective, the external axis is part of drive system 1 and your error states drive system 3 measurement channel 1. That is saying there is no communication received by the drive system 3 (robot 3) axis computer at connector XP4. You can verify easily by turning off power, removing robot 3 SMU cable and powering on to see if it errors the same with the serial measurement cable unplugged.
If the Axis Computer reports it is not receiving a signal on measurement ch.1, then it is either the Axis Computer, the SMU in the robot or something in between. If you have EPS or SafeMove, the SMU communications passes thru those units to/from the robot SMU. EPS connectors are X5 & X6 and SafeMove is the same.
I guess the very first thing is to do a very detailed inspection of that entire serial measurement cable to make it is not damaged somehow in all the moving since it was running last.
I would then plug the SMU cable from robot 3 in to robot 2 or 4 and see if the problem moves. If it looks like the controller, then try swapping the entire serial measurement cable. Next try swapping the Axis Computer in drive unit 3 with drive unit 2 or 4 and see if the problem moves. Had a few Axis Computers lose their communication with the SMU. Multiple robot systems make troubleshooting easier sometimes.