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

[MPaulHolmes]

What are the specs of this motor? Like, the full load current, and the voltage it's designed to run at (AC voltage), the number of pole pairs (if the nameplate says around 3500 at 60Hz, it's 1 pole pair, 1800 means 2 pole pairs, etc...). Do you have 3 Lem Hass 300-s current sensors in the controller? You will have to change that to the following:

current-sensor-amps-per-volt 480

(it's set to 80 right now, which is for the LEM Hass 50-s).

The rotor time constant may be way off too. But we can figure that one out after getting the PI to converge.


I still feel concerned that the IGBTs didn't do anything weird with the voltage reversed on the IGBTs. That is a dead short circuit with nothing but 2 diodes to slow it down. I wonder if it's possible that the diodes failed opened inside the IGBTs. Could you test with a diode meter thing from B- to B+? Or B- to the phase, and from phase to B+?

[thingstodo]

Originally Posted by MPaulHolmes

What are the specs of this motor? Like, the full load current, and the voltage it's designed to run at (AC voltage), the number of pole pairs (if the nameplate says around 3500 at 60Hz, it's 1 pole pair, 1800 means 2 pole pairs, etc...).

German motor - ABM

Connected in delta, 215A continous (rated?)

6400 rpm at 219 Hz. That gives me 1753 rpm at 60 hz, so I think it is 4 pole.

It's fed with a 48V pack, which is 52V when fully charged. 36VAC? But the nameplate says 29 VAC. Does not compute.

Power factor 0.88

64 pulses per revolution is the encoder

Do you have 3 Lem Hass 300-s current sensors in the controller? You will have to change that to the following:

current-sensor-amps-per-volt 480

(it's set to 80 right now, which is for the LEM Hass 50-s).

OK. I can do that. Tomorrow I should have some time in the evening.

The rotor time constant may be way off too. But we can figure that one out after getting the PI to converge.


I still feel concerned that the IGBTs didn't do anything weird with the voltage reversed on the IGBTs. That is a dead short circuit with nothing but 2 diodes to slow it down. I wonder if it's possible that the diodes failed opened inside the IGBTs. Could you test with a diode meter thing from B- to B+? Or B- to the phase, and from phase to B+?

Diode meter:
B- to B+: The voltage starts at 0.3 and rises. With black on B- and Red on B+. It rises above 0.7 and keeps rising. If I reverse the leads, the voltage drops to 0 and then rises again, like I'm charging a capacitor ... and I am.

B- to U, B- to V, B- to W. Black to U,V,W, Red to B-. All give 0.304

V to B+, U to B+, W to B+. Black to B+, Red to U, V, W. All give 0.304

If I put Red to B+ and Black to U,V,W the capacitor charges.

If I put Black to B- and Red to U,V,W the capacitor charges.

[wootwootman]

Originally Posted by MPaulHolmes

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.

Thanks Paul, I'll go ahead and do that. I've got some battery stuff to take care of before I can power on the motor for testing though.

I'll start with 'run-angle-offset-test' from 0-511 to get the best value, after which I'll try 'run-pi-test2'. Currently my configs are kp=5000 ki=80 and pi-ratio=62. This second pi test doesn't use the pi-ratio variable, so I'll stick to varying kp and ki proportionately. Maye one day I'll plot the output and fine tune them.

I also saw that line 1991 in ACController.c mentions something about 75A for a LEM Hass 300-s (I'm using a 200 equivalent). If I've got my max-battery-amps and max-motor-amps below 75, will this still let the test/motor function properly or should I raise those limits?

[MPaulHolmes]

Actually, do the run-pi-test2 first. That is a locked rotor test (but you don't have to lock the rotor). It doesn't require knowledge of the rotor flux angle, so you don't need the angle offset for it.

Once you get good convergence, then move to finding the angle offset. I would suggest on that one, do the following

angle-offset 0
// then give it a little throttle
angle-offset 16
// then give it a little throttle
angle-offset 32
// then give it a little throttle
...
and when it hits the zone where there is no movement from the throttle, add 128 to that, and that's the ideal angle offset. You can also subtract 128 instead, if you want the default rotation to go the other way.

then, type:

save

and hurray, you are done. drive into the sunset.

The LEM Hass 200-s is fine. It just means you will need to have

current-sensor-amps-per-volt 320
save

You can use any current you want from 0 to about 400 then, because 400 will be where the hardware overcurrent trip point is.

[thingstodo]

I checked the config of the controller config

motor-type=3
kp=03333 ki=00050
current-sensor-amps-per-volt=0080
max-regen-position=0042
min-regen-position=0339
min-throttle-position=0539
max-throttle-position=0837
fault-throttle-position=0005
max-battery-amps=0015 amps
max-battery-amps-regen=0015 amps
max-motor-amps=025 amps
max-motor-amps-regen=025 amps
precharge-time=0050 tenths of a sec
angle-offset=119
saliency=0000
pole-pairs=004
max-rpm=06000 rev/min
throttle-type=0
encoder-ticks=0256 ticks/rev
pi-ratio=062
raw-throttle=0501

Change current-sensor-amps-per-volt to 480

stream log data and check the throttle signal, adjust scaling of throttle signal, motor amps, pack amps

range is 1018 at 1k, 80 at 999k
max-regen-position=0100
min-regen-position=0450
min-throttle-position=0550
max-throttle-position=0900
max-battery-amps=0100 amps
max-battery-amps-regen=0015 amps
max-motor-amps=200 amps
max-motor-amps-regen=050 amps

The settings were saved.

run-pi-test2 was run at the following settings. See attached raw log file. None of the settings appear to change much, whether there is power on the DC bus or not, whether the kp and ki are large or small.

I see no convergence at all. Perhaps the IGBTs were damaged after all. BUT - with the old firmware and the settings from my siemens motor I got the motor to run (poorly) but it rotated!

kp=03333 ki=00050
kp=06666 ki=00100
kp=13333 ki=00200
kp=01666 ki=00025
kp=00888 ki=00012
kp=30000 ki=00600
kp=04000 ki=00064

Then I tried running the controller and there appears to be no AC output phase to phase, phase to B+, Phase to B-. Something like 0 - 0.7V but it is not consistent. It should be consistent. I didn't think to check the phase current to see if there was current flow into the motor.

[MPaulHolmes]

Also, don't forget

pole-pairs 2
motor-type 1

[thingstodo]

Originally Posted by MPaulHolmes

Also, don't forget

pole-pairs 2
motor-type 1

Right - forgot about that.

That will happen tonight.

What about the PI ratio, as @arber333 asked? Do I need to mess with that? Or the rotor constant?

I'm still wondering if I killed or damaged the IGBTs. But I saw the motor turn, under power, after that ...

[MPaulHolmes]

The PI ratio was just a variable that was there for when the "auto" PI test was running. It gave a starting point for how to check a bunch of values. So, if you had the PI ratio be 100, the "run-pi-test" would do:
Kp = 100
Ki =1

Kp = 200
Ki = 2
.....

but it doesn't come into play when you are independently setting Kp and Ki. So, let's say you did this:

pi-ratio 50
kp 1000
ki 10

the variable named "pi-ratio" would still be 50, even though now Kp / Ki = 100.

The rotor time constant can vary a lot from one motor to another. The motor will run horribly if you are way off. It will run OK if you are a little off, and it will run the best if it's perfect. The "run-rotor-test" only works on an unloaded motor. I"ve only ever tested it on a bench with no transmission. If a transmission is hooked up, you man need to change the default commanded Id and Iq in the rotor test function "RunRotorTest" from
IdRefRef = 300
IqRefRef = 300
To something bigger. Those numbers just worked OK for me on a bench with a unloaded motor at maybe 60v or whatever it was I was using for the test.

If you can't get the run-rotor-test to work, you can just try guesses from 5 up to 150 (5mS up to 150mS for the rotor time constant):

rotor-time-constant 5
rotor-time-constant 6
...
rotor-time-constant 150


and see what gives the best acceleration.

Arber, does your ABZ encoder have a single index pulse per mechanical revolution, or is it 4 per mechanical revolution? That's the only difference from motor type 2 to motor type 3. One possibility is your encoder doesn't like one of the settings below:

		case PERMANENT_MAGNET_MOTOR_WITH_ENCODER:
			QEICONbits.QEIM = 0b110; 	// enable QEI x4 mode with position counter reset by INDEX pulse. 
			QEICONbits.PCDOUT = 1; 	 	// Position Counter Direction Status Output Enable (QEI logic controls state of I/O pin)
			QEICONbits.POSRES = 1;		// Position counter is reset by index pulse.	
			QEICONbits.SWPAB = savedValues2.swapAB;		// don't swap QEA and QEB inputs.  
	
			DFLTCONbits.CEID = 1; 		// Interrupts due to position count errors disabled
			DFLTCONbits.QEOUT = 1; 		// Digital filter outputs enabled.  QEA, QEB. 0 means normal pin operation.
			DFLTCONbits.QECK = 0b011; 	// clock prescaler of 16. So, QEA or QEB must be high or low for a time of 16*3 Tcy's. 
										// Fcy = 30MHz.  3*16Tcy is the minimum pulse width required for QEA or QEB to change from high to low or low to high.
										// You can do at most 30,000,000/(3*16) = ??? of those pulses per second.  So, you can have at most
										// ??? * 2 clock counts per second, since resolution has been multiplied by 2 (QEA and QEB up and down transitions all cause a pulse to be seen by the microcontroller..)  
										// 
			DFLTCONbits.IMV = 0b00;  	// INDEX pulse MUST happen when QEA & QEB is low. It didn't work for QEA being low with the Leaf motor.
			MAXCNT = (savedValues2.encoderTicks << 2) - 1; 		// If going backwards, poscnt will go from 0 to maxcnt, ONLY IF it is caused by an index pulse!!!  Multiply by 4 since I"m doing 4* the resolution.
								// Use this for the AC controller.  It's easier to measure speed of rotor with this setting, if there's no INDEX signal on the encoder.
			POSCNT = 15000;  	// It starts in an unknown state before the index pulse happens. Do this so I can know the index pulse hasn't happened yet.  It will vary from 14000 up to 16000 or whatever, and suddenly be forever trapped in [0,MAX_CNT] once the index pulse happens.
			myFirstEncoderIndexPulseTest.startTime = 0;
			myFirstEncoderIndexPulseTest.currentAngleOffset = 0;
			myFirstEncoderIndexPulseTest.testRunning = 1;
//			encoderTicksDivPolePairs = __builtin_divsd((long int)savedValues2.encoderTicks,(int)savedValues2.numberOfPolePairs);
		break;

I would try changing "DFLTCONbits.IMV = 0b00;" to
"DFLTCONbits.IMV = 0b01;", or DFLTCONbits.IMV = 0b10;, or DFLTCONbits.IMV = 0b11;
Those are the possible required states of A and B, when the index pulse happens, and I don't know what state A and B are in when the index pulse happens on your encoder, so you would just have to try them all. This is why companies pick a specific motor and specific position sensor and just make a specific controller for it. Everybody has their own standards.

[thingstodo]

Originally Posted by MPaulHolmes

The PI ratio was just a variable that was there for when the "auto" PI test was running.

OK - I'll skip changing that one

The rotor time constant can vary a lot from one motor to another. The motor will run horribly if you are way off. It will run OK if you are a little off, and it will run the best if it's perfect.

Good - so I don't have to worry about that until I get the motor to turn

If a transmission is hooked up, you man need to change the default commanded Id and Iq in the rotor test function "RunRotorTest" from
IdRefRef = 300
IqRefRef = 300
To something bigger. Those numbers just worked OK for me on a bench with a unloaded motor at maybe 60v or whatever it was I was using for the test.

I may get to that, but likely not until the weekend

If you can't get the run-rotor-test to work, you can just try guesses from 5 up to 150 (5mS up to 150mS for the rotor time constant):

I suspect I'll just guess, starting with what I used for the Siemens motor ... after all, it did turn with those settings ... except for the motor-type and pole-pairs!

Awesome information, as usual, Paul. Thanks

I always take video and record audio of my tests in case something interesting happens. So far, I've only shown examples of what can go wrong. My motivation for editing the video is pretty low.

When I get something to work, I'll take pictures and video. Maybe I can get motivated to edit video for initial laptop connection to the controller on serial, getting the signals for the encoder connected, get a throttle connected, get the pack connected with a pre-charge circuit, etc etc

[thingstodo]

See attached log for the morbid details, but here's the summary

Changed motor type to 1 and pole-pairs to 1

Started with kp = 30000 and ki=600

Run-pi-test2 and then cut kp and ki in about half. Rinse and repeat

At the end, turn off the 48V pack, bleed off the capacitor, then re-run the last run-pi-test2

They are not identical but they are very close. I guess I broke the power stage?

Is there a test I can run to drive the IGBTs without having pack power on? Is it faster or easier to load in the firmware to run it as a house inverter? I am trying to figure out if I somehow damaged the electronics, or the high power section, or perhaps the firmware is assuming a hardware mod I don't have ...