CR-E116 "0531" alarm

I've noticed plenty of posts regarding battery/encoder alarm issues with the RV-E2 and RV-E3J, but most of the discussions danced around the issue rather than provide much insight. The low current output of the E32BT battery interface board seemed to be what most would reference, but nothing regarding a "post-production" fix. Keeping things short: I have an RV-E2 with new batteries, reset the battery counter, reset the data encoders, currently getting a 0311 error (0200~0266 sometimes on restart), unable to release the brakes to reset the z-phase, and unable to run any commands to reset the battery meter (there is no default option to do so in the maintenance -> init menus. Any ideas?

Is it possible to get the brakes to release with the 0311 alarm active? I'm noticing contradictions in the manual as the servos need to be enabled in order for the brakes to disengage, but the alarms prevent this. The mentioned procedure for handling the specific alarms is setting the Z-phase. This can't be done unless the brakes are released.

I reflowed all of the solder connections for the battery interface board as well as test for continuity and resistance across all connection points back to the control box. The actual resistors on the battery board are still good, but I was surprised just how much they drop the current. Someone in the past mentioned ditching the resistors and bridging the connections, but I would prefer another take on this as I would think some current limiting would be recommended.

I factory reset the unit and followed the setup procedure for resetting the ram, encoder, and battery data. I'm still facing the same 0311 issue. Looking at another thread, according to Werner Hampel, you have to reset the battery counter. The way he mentioned to do so does not exist on the P6TB-TE pendant and the "RS 2" command is being flagged as invalid.

Does anyone know what the output current should be for the battery interface board?

Another question I have regards the eproms as I can't find any information. Do these hold the firmware for the controller or are they for program storage? If it's the former, how would I go about obtaining a copy to test the validity of the contents?

...

On the E31CPU, does anyone have any ideas as to what might cause the (TEST 4) LED to illuminate?

While this may be a longshot, does anyone have any leads for the main CPU board schematics?

The only suggestion has been to recap the board. I was hoping there would have been more literacy with this subject amongst the members here, but one step at a time.

Does anyone have the firmware (eprom contents)?

Any leads regarding anything posted thus far? An additional question: should both LEDs be lit on the E31P4 Power Board? LED 1 is currently unlit, and with the trace running underneath one of the larger caps on the board, I'm unable to find the next node to determine its function.

Here are some pictures:

And another regarding the mentioned LED from earlier:

Is there anything else needed to aid in diagnosing this?

I've not been able to trace the CPU errors back to any of the decoding logic. I can only assume it may be the CPU itself (I noticed it is socketed unlike most pictures of the board I've seen), or that the eprom contents are corrupt. I'll try swapping the processor out for a known working unit, but I'm at a loss of what to do if this fails. What I find odd is that I was initially only getting 0311 and 0200~0266 alarms, but now the unit is failing to pass its self-tests.

Slightly pushing down on the daughter cards cleared all of the CPU errors up and I'm now experiencing the 0311 alarm again. I wasn't expecting these controllers to be this temperamental.

Does anyone have any information on the E33BT battery card?

I'm still in the process of cap replacement. A good number of surface mount electrolytics had leakage only noticeable once removed. So far, all of the through-hole caps have tested good, but these will still be replaced with what I have available. Hand soldering the replacements should also provide a more rigid and reliable connection. I probably should have scoped areas of the board to begin with, but the lack of schematics and pinout definitions resulted in me holding off.