Make sure you inspect the battery case for the 4 d-cells. They are notorious for corroding even to the point of the wires breaking off the back, inside the robot arm. You may want to remove the case from the arm and inspect the back.

Are you logging any alarms?

Have you unhooked those wires to the spot welder?

Checked all your grounding?

Are you changing the correct batteries and are you receiving any alarms about the batteries?

I believe this is the method I used to fix that and other issues related to the GM's. Please use at your discretion as I cannot claim to be an expert and if any of the real experts here see an issue please speak up. Hope it helps.

TO CLEAR I/O

The IO declaration is in F2 "config" portion of the I/O screen. Change the columns to all be 0 to disable everything!

An alternative and usually faster way would be to clear assignments. To do that, do the following (This may not be an option, as all versions of software do not have this)

Go into the I/O screen

press F1 "Type"

choose "link device"

press F5 "CLR_assgn"

recycle power and everything should be cleared!

All of the robots I cut my teeth on were old GM robots and they all had the brake release option.

That being said there was a way to by pass that if I remember correctly. I will see if I can find the procedure and let you know.

They are a pain in the butt to work with.

Here is a clip from a post I was on 4-5 years ago. After tightening the mentioned shield clamps it never happened again.

"DTERR alarms can be caused by poor connection of the shield on the RP1 cable to ground at the controller."

"Yes the shield clamps were all loose in the cabinet. Tightened them and problem cleared. You people are life savers. I thank you."

I have had wires corrode off behind the battery, in the arm body. Acted the same way as op's.

CT's = current transformers.

Place current transformers on the axis feed wires and send to an analog card in PLC.

Then set max/min compare statements in program.

Have never tried with robots but I have done this on many other machines.

Are your robots using PLC's?

If so CT's + analog input + compare/compute statement and you could conceivably monitor current.

Not knowing full story behind this need for mastering I would suggest re-making the position and seeing if it holds.

If a robot loses it's master for some reason and the master is not saved correctly, as in recording the actual positions of each joint then remastering will usually require touch ups to positions.

If you care to share your email I may have something that helps.

Have you tested your control power from estop to control boards?

Do you have a back up PSU to try?

You said all the fuses on the PSU.

Did you check for a the small green fuse on the door?

Also make sure the transformer taps are in the correct positions for your incoming power.

Has this ran and quit or is it initial start up.
One thing that gave me fits in the past was baud rates.
They all have to match.
Good Luck

Comm issues with Wago and DNet board, try changing Baud rate on board and wago to 250 if set at 500 and vise versa. 1 st robot cell gave fits until I changed from 500 to 250 on both places.

DUP MAC ACK Fault after setup and ok comms, Check that plug on wago did not get pulled loose.

These are 2 fixes that worked for me at different times on my RJ2's. Good Luck.

Axis Limits: Menu>System>Axis Limits.
Actually in the post right below yours.
The search feature can be a real life saver in here.
Peace.

Was this robot previously running?

If it is a 420-i robot there are 4 D cell batteries in the base of the robot behind a 4 inch~ black plate with 2 silver screws.
The BZAL alarm means those batteries need to be changed and the alarm will not clear until you do change them and then follow the procedures already noted above.

I fixed this alarm, (2 years and counting) by tightening the shield clamps inside the control cabinet, on the advice of RacerMike . Knock on wood