Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[wootwootman]

Originally Posted by thingstodo

Umm ... .. I seem to have reversed the polarity of the battery pack.

This is one of my biggest fears, that I'll connect something backwards and have a light show. Since you were only using 56V, I think the IGBTs are fine. And as far as your capacitor goes, be sure to discharge it with a resistor before you charge it with the correct polarity. Idk what type you're using, but I have an SBE Power Ring 700D529 and I was told it's non-polarized so there shouldn't be a problem with it.

I think we have different versions of the controller board (21), so I can't speak for yours, but nothing on the schematic jumps out to me as vulnerable to reverse polarity damage.


For my encoder issue, I read through the AD2S1210 datasheet and if I understand correctly, the resolution is currently set to 10-bit but I need it to be 12-bit. This should allow it to emulate a 1024-line encoder instead of a 256-line one (right?). I can achieve this by taking Pin1 from GND and tying it to 5V. I'll try this out and report back, in case anyone runs into a similar issue in the future with the 2013 Leaf Motor EM57 (resolver 34VRX-1004C01S)

[thingstodo]

Originally Posted by wootwootman

This is one of my biggest fears, that I'll connect something backwards and have a light show. Since you were only using 56V, I think the IGBTs are fine. And as far as your capacitor goes, be sure to discharge it with a resistor before you charge it with the correct polarity. Idk what type you're using, but I have an SBE Power Ring 700D529 and I was told it's non-polarized so there shouldn't be a problem with it.

Yup - I have the *MONSTER* ring cap. It was discharged with the 5.6 ohm resistor when I realized my mistake. Thanks for the info that it is not polarized ... that's the big cost. The IGBTs are fine. They are definitely NOT polarized.

I think we have different versions of the controller board (21), so I can't speak for yours, but nothing on the schematic jumps out to me as vulnerable to reverse polarity damage.

I was not worried about the control board. It is alternately connected to the high side and the low side through the driver only .. as fast as I can see anyway. And it is powered from a separate supply ...

It is the power section I am worried about. But I could be wrong.

For my encoder issue, I read through the AD2S1210 datasheet and if I understand correctly, the resolution is currently set to 10-bit but I need it to be 12-bit. This should allow it to emulate a 1024-line encoder instead of a 256-line one (right?). I can achieve this by taking Pin1 from GND and tying it to 5V. I'll try this out and report back, in case anyone runs into a similar issue in the future with the 2013 Leaf Motor EM57 (resolver 34VRX-1004C01S)

10 bit is 0 - 1023 or 1024 pulses per revolution. 12 bit is 0 - 4095 or 4096 pulses per revolution. 256 (or 0 - 255) is 8 bit.

Tieing pins to GND or +5V is how you strap your chips to configure some of the simpler stuff. I use 1K resistors instead of jumpers ... just in case I have issues with current limiting somewhere!

If you add a link to the data sheet I can look at it as well - another set of eyes!

EDIT: Found this link http://www.analog.com/media/en/techn...s/AD2S1210.pdf and I think they messed up with the description of 10 bit. I think you want 10 bit = 1024.

[wootwootman]

Originally Posted by thingstodo

Tieing pins to GND or +5V is how you strap your chips to configure some of the simpler stuff. I use 1K resistors instead of jumpers ... just in case I have issues with current limiting somewhere!

If you add a link to the data sheet I can look at it as well - another set of eyes!

EDIT: Found this link http://www.analog.com/media/en/techn...s/AD2S1210.pdf and I think they messed up with the description of 10 bit. I think you want 10 bit = 1024.

Yup, that's the data sheet I used. Both PIN1 and PIN48 were originally grounded on the encoder board, so I lifted up PIN1 and blue-wired it to +5V. When I hooked it up to the controller board, poscnt started giving me crazy numbers. It sort of does inc/dec, but through weird ranges (pic attached, poscnt on right) in quarter-rotations.

This is obviously a step in the wrong direction, so I decided to revert to a known working setting. I cut the wire, but the encoder is still acting strange. I think it doesn't like a floating pin, so I'll GND it tomorrow. Hopefully that brings it back to where it was before, otherwise I may have made things worse.

[thingstodo]

Originally Posted by thingstodo

Umm ... .. I seem to have reversed the polarity of the battery pack.

Update:
The controller appears to be OK. My power-up sequence is turn on separate 12V to the controller and wait for the clicks, turn on pre-charge, turn the key on for the Polaris Ranger EV, wait for the built-in SEVCON controller to close the internal contactor, then turn on my external contactor.

Bus voltage is 56.1V, with B- at 0 and B+ at 56.1V THIS TIME!

I logged the config and started logging data once per second. I ran the driven tires backward and verified that the mechanical motor speed was registering.

The I did RUN-PI-TEST. And I waited. The motor started making pulsing sounds after maybe 5 minutes. And it went on .. and on .. and on ...

After 2 HOURS it was done. It may have been only an hour and 45 minutes ... I just checked on it once in a while.

Attached picture is hard to read. The error message is:
P I Overflow fault. It's really not tracking IdRef and IqRef well at all.

So tonight I will spend a few minutes and see if I can get the motor to try turning by faking the throttle signal. I'm gone for the weekend so it will be Monday before I get the firmware upgraded so I can see what is going on with RUN-PI-TEST2

*BUT THE CONTROLLER IS OK*!! Whew!

Maybe I should see the tires rotate before I declare victory?

[wootwootman]

Originally Posted by thingstodo

I logged the config and started logging data once per second. I ran the driven tires backward and verified that the mechanical motor speed was registering.

The I did RUN-PI-TEST. And I waited. The motor started making pulsing sounds after maybe 5 minutes. And it went on .. and on .. and on ...

Hmmm is it possible to stream data while running the test? Might be helpful in diagnosing. Otherwise I'd just hook up all the measurement equipment you've got


I connected Pin1 of the AD2S1210 back to GND and the board is back to acting like it was originally: 4 Index pulses per motor revolution. Thinking about it more, would it be possible to run the ACController code in this configuration? Would it just run at 1/4 speed, or would it require me to change the "encoder-ticks" config setting?

[thingstodo]

Originally Posted by wootwootman

Hmmm is it possible to stream data while running the test? Might be helpful in diagnosing. Otherwise I'd just hook up all the measurement equipment you've got

Run-Pi-Test is a command, that runs until you press Enter.

data-stream-period 100 is a command, that runs until you press Enter.

So no joy there.

The latest rev of Paul's firmware is supposed to show results as it tests - I need to get that loaded. I was late getting back from the lake today and needed to help my wife with preparing the raised garden beds, watering the trees, and other evening chores.

I should get some time late Monday afternoon.

I connected Pin1 of the AD2S1210 back to GND and the board is back to acting like it was originally: 4 Index pulses per motor revolution. Thinking about it more, would it be possible to run the ACController code in this configuration? Would it just run at 1/4 speed, or would it require me to change the "encoder-ticks" config setting?

4 index pulses per rev? My apologies ... I thought the index was 1 per rev. Did I miss something? Or is this your chip that is generating the index at 4x what it should?

My controller is not running with the index pulse. My controller ran with only 1 encoder signal connected. With 2 encoder channels, the controller can tell direction.

So .. if you don't connect the index pulse .. and it gives you 1024 pulses per 1/4 turn, encoder-ticks should be set to 4096.

If you connect the index pulse .. and it gives you 1024 pulses per 1/4 turn, leave encoder-ticks at 1024 and you will show mechanical rpm at 4x real rpm .. I think.

[thingstodo]

2018 May 4

Originally Posted by thingstodo

*BUT THE CONTROLLER IS OK*!! Whew!

Maybe I should see the tires rotate before I declare victory?

This is a log of what I did and what results I saw for May 4. i didn't get the video downloaded or edited. But progress was made. Tire rotation has happened. I have 'driven' my Polaris Ranger EV with Paul's AC Controller.

NOW I can say that THE CONTROLLER IS OK ...
--------------------------------------------------------------------------------------------------------------
Power up the laptop. Connected to the controller with a serial cable on com7, an external USB converter. 115,200 baud, no parity, 8 data bits, 1 stop bit. Start at VT100 terminal

Power up the controller first. 12V battery through a 5 amps resetable breaker to the DC converter. The relays click for precharge and main contactor

AC Controller version 1.0 is displayed

type in config command

this shows the settings in the log file

turn on the mini breaker on the 56V battery bank. The contactor shows 56V.

turn on the key switch. The DC converter on the Polaris Ranger powers up. 12V power for the Ranger comes up slowly.

Wait for the SEVCON controller to stop blinking green and go solid green. The SEVCON terminals show 46.5V so we have 9.5V drop across the 5.6 ohm resistor. about 1.5 amps.

Close the 80 amp breaker on the battery bank

Check the controller voltage. 56V, B- = 0V. B+ = 56V (I checked the polarity this time!)

Start logging with ZAC_Config.txt - turns on all of the datalogging flags

Change the throttle. IT RUNS! But it is very jerky - change the throttle a bit. Video shows slightly faster but jerkier. The motor response is very poor.

But this is the second spin. The first spin was not caught on video since it sort of surprised me that it moved. I had sort of a crash of the controller - I think the current into the motor was ramped up quite quickly and then it sort of stopped. And it did not respond to throttle after that. So I had to cycle power.

* Update * the throttle signal responds poorly to being disconnected and reconnected by vibrating connectors and pins that are too small. My throttle setup is very duct-tape-ish.

[thingstodo]

2018 May 7

Upgrade firmware to 21 ... it still says AC Controller version 1.0
Changed motor to type 1

run-pi-test2 displays several numbers - what do I change or what am I looking for ... I guess it's been long enough that I forgot most of this!

Then I did
stream-poscnt 1
data-stream-period 100

And i saw a lot of numbers, but most of them stayed the same when I turned the wheels. Maybe I disturbed the encoder signals? I'll have to make them a bit more permanent.

If I use the same numbers I had from the old firmware, will it still move? Did you change a bunch of the calculations or is that pretty much the same?

I was hoping the new firmware would give me some progress. And I'm sure that it will .. after you explain stuff to me again sorry.

[MPaulHolmes]

Holy cow I missed a lot! Fortunately, I am now unemployed, and can check here more often. haha.

For thingstodo:
You have to pretend that you are from the matrix... Remember how they see the random numbers and see all sorts of events happening? 200010220 20202020 "oh no! Neo is fighting the bad guys"

When you do run-pi-test2, what you want to see is convergence toward 0. It should start at around 512, and quickly fall to 0. It won't really fall to exactly zero. So, something like this when you type run-pi-test2:
512, 512, 460, 440, 430, ..., 100, 50, -50, 60, 0, -40, .....

The rate of convergence depends on the specific motor. For big motors it usually converges really fast (like in 10 or 20 iterations). For small ones maybe in 40 or 50 or something iterations? I've seen it as slow as 90 before.

If it converges to zero, (but bounces around zero), you are good. If it goes too negative, and then comes back, then you need to reduce your Kp and Ki. It's a little too agressive and wild. Also, make sure Kp is around 60*Ki, whatever you are using for Ki.

Reversing polarity of the B+ and b- could be very bad. That's a dead short across 2 diodes inside the IGBTs. Now, those big diodes can handle 600 amp each, and you have 3, so that's 1800amp that the IGBTs could handle. I bet the 58v battery pack wasn't able to deliver that. Was there a fuse that could have blown so that the precharge can still do its thing, but the main contactor can't?

The software is very similar to what it was before. You sholdn'thave to use different numbers for your motor.

wootwootman: don't bother with run-pi-test. Just do run-pi-test2. Human eyes on the data is better than the sad amount of intelligence I tried to bestow upon the little microcontroller, which is basically a computer from 1975.

[thingstodo]

Originally Posted by MPaulHolmes

Holy cow I missed a lot! Fortunately, I am now unemployed, and can check here more often. haha.

Too bad! Their loss.

For thingstodo:
You have to pretend that you are from the matrix... Remember how they see the random numbers and see all sorts of events happening? 200010220 20202020 "oh no! Neo is fighting the bad guys"

When you do run-pi-test2, what you want to see is convergence toward 0. It should start at around 512, and quickly fall to 0. It won't really fall to exactly zero. So, something like this when you type run-pi-test2:
512, 512, 460, 440, 430, ..., 100, 50, -50, 60, 0, -40, .....

OK. What happens if it does not go below 450 and then goes back up again? Do I need to set something and try again?

The rate of convergence depends on the specific motor. For big motors it usually converges really fast (like in 10 or 20 iterations). For small ones maybe in 40 or 50 or something iterations? I've seen it as slow as 90 before.

With run-pi-test on the older firmware, the motor chirped for an hour and a half or so, then it gave up and told me that it was not converging.

If it converges to zero, (but bounces around zero), you are good. If it goes too negative, and then comes back, then you need to reduce your Kp and Ki. It's a little too agressive and wild. Also, make sure Kp is around 60*Ki, whatever you are using for Ki.

Right now I'm using defaults, whatever they are. So if it does not converge ... which way do I go?

Reversing polarity of the B+ and b- could be very bad. That's a dead short across 2 diodes inside the IGBTs. Now, those big diodes can handle 600 amp each, and you have 3, so that's 1800amp that the IGBTs could handle. I bet the 58v battery pack wasn't able to deliver that. Was there a fuse that could have blown so that the precharge can still do its thing, but the main contactor can't?

The battery pack did not blow it's 80 amp fuse. The power board was charged up to pack voltage, just backward. I didn't notice and did a run-pi-test ... and nothing happened.. at all.

The software is very similar to what it was before. You sholdn'thave to use different numbers for your motor.

OK - so the motor sorta turned - last night, video when I get it edited - with the numbers I had from the siemens AC motor. But I'm at a lower voltage, and the motor is *MUCH* less powerful.

As for being unemployed, a couple of guys on the Polaris forum are drooling over the numbers on your controller. These guys are gear heads and always want more power, more speed...

I know that the ring cap is expensive, and I expect that lower voltage on the IGBTs would be less expensive ... maybe some components could be changed and it could be priced as an upgrade to the Polaris Ranger line of EVs. The SEVCON controller that is used now is MOSFET based and has issues with cooling. 650A max and it has issues going up long inclines even if they are not very steep. It also has some issues with specific frequencies (hesitates and kinda stutters) when loaded and going up hill.

The big pain would be that most of these things are lead acid so there is not a lot of room for the controller .. and there is a 40ish pin connector to interface to. All the signals you need are there .. I've mapped most of them out.

There is a high/medium/low switch on the dash for max speed, max range, and hauling respectively. 4wd 2wd turf mode is handled by the VCIM and involves solenoids on the differentials front and back. There is also a Forward/neutral/Reverse switch, an indicator above the manual steering for F, N, R, Brake, and a wrench problem light.

The throttle is a dual hall effect, one signal 2x the other signal. I have the voltages mapped. There is no signal from the brake - which is silly. There is a pressure switch which runs the brake lights and adding a pressure transducer would be straight forward, with 0 - 5V for braking to give regen.

Just me running off at the mouth! But seriously, I could use some help with this project!