> I built a load bank to test my 36Y 10aH GM batteries
totally off-topic: if you have a little time, could you describe it or post a pic?
> Thinking it was either over heating
no temp sensor in this controller. it'll happily fry to death, so it's not that.
> I am assuming it is a three phase controller with three banks of four FET's.
yes, there are two parallel FETs on each half-H leg, totaling 12.
> Is it safe to connect the battery and power it up on the bench without the motor connected?
absolutely.
> I saw a controller tester on one site - would this be worth getting?
IMHO, no.
> so I tested the throttle
seems fine.
> hook up the leads and take it for a ride. Keep the multi-meter in view at failure time.
that's a good suggestion.
> After that you could hook it up to the motor feed from the controller and do the same test.
I doubt that measuring this with a tester would be of any help.
1) are you using the break switches? if so disconnect them from the controller and retest. (don't reconnect them until after the failure is identified and fixed).
2) how do you recover from the cutoff? do you have to cycle the power or just wait? for how long?
I'd check the batt during failure, then...
first thing to diagnose is knowing what's causing the cutoff. either the microcontroller hangs up, or it decides to cut, or some other part of the circuit fails.
the green led is driven by the uC and sort of reports status; I believe it blinks repeatedly a number of times to signal different conditions. maybe you can test with the case open. (or you might want to add an external LED for debugging. if you add it in parallel to the one there, I suggest you use a red led which typically has a lower voltage drop and thus should light up instead of the green one.)
if the led dies on failure, maybe the uC is just locking up. but note the the uC might be using a watchdog, so it might reset milliseconds after the hang-up. so try to see what the led does after power-up (which is a kind of reset) and see if it does the same thing upon failure. this would hint that the controller is being reset.
coming up next...
if the uC is deciding to cut, find out why. there are three possible stimuli: analog battery voltage sense signal (for over/undervoltage detection), digital overcurrent detect signal, and analog current sense signal (that may or may not be used by the software). we could disable each one of them to find the culprit, but keep in mind that an unhandled overcurrent could zap the FETs.
my guess is that (over)current sensing is probably used as negative feedback to limit (regulate) current so it's probably not to blame in your case. we'll see.
EDIT: a hall malfunction will make the uC cut drive to the FETs, but the drive will recover *instantly* after the problem goes away. note that no sequence analysis seems to be done: the current combined state causes the current drive signals. thus, the only malfunction detected on halls is illegal state: all zeros or all ones.
