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

[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 ...

[Piotrsko]

Based on what I observe over on some of the other power forums I stalk, you have probably fried the power transistors and probably also the drivers.

Isn't there some snubber diode across the igbt to sink the back emf?

From what I recall igbt failure mode is generally shorted on. Theory says the gate becomes damaged.

My experience is that it doesn't take long to crispy the weakest part reverse biased.

I believe if you powered up the controls with 12v, and spun the encoder/ motor by hand, an ohmmeter could be used accross the phases and battery ground to show a decrease in resistance when the thing switch on. I am guessing you already checked that you were getting switched voltages on any pair of motor leads. This is where a scope would be handy, but I have done it with a analog simpson set to whatever the battery pack max is.

[MPaulHolmes]

These IGBTs have the diodes inside from emitter to collector for each IGBT. There was not a continuous massive amount of current when B+ and B- were reversed, so that makes me think maybe they gracefully failed opened? There are several little thin wires (like 28 awg or something) inside the IGBTs that are floating in a gel, which connect to the collector and to the emitter tabs. I think they are designed to act as fuses. I would be interested in seeing the inside of the IGBTs. They have tiny screws in them, and then the little plastic top can pop right off, or you might need to bend the metal tabs first for the plastic top to be removed. My guess is that some of those little thin wires have failed opened, but I don't know for sure.

[thingstodo]

Originally Posted by MPaulHolmes

These IGBTs have the diodes inside from emitter to collector for each IGBT. There was not a continuous massive amount of current when B+ and B- were reversed, so that makes me think maybe they gracefully failed opened? There are several little thin wires (like 28 awg or something) inside the IGBTs that are floating in a gel, which connect to the collector and to the emitter tabs. I think they are designed to act as fuses. I would be interested in seeing the inside of the IGBTs. They have tiny screws in them, and then the little plastic top can pop right off, or you might need to bend the metal tabs first for the plastic top to be removed. My guess is that some of those little thin wires have failed opened, but I don't know for sure.

The weather is nice, and projects are calling ... this post-mortem may not get done until it's cold outside.

Even though I *REALLY* want to know what failed!

[wootwootman]

I was able to get everything wired and powered up, so I got some testing done yesterday evening for results to analyze this morning. I started with kp=5000 ki=100, then moved on to kp=10,000 ki=200 and went back to kp=3000 ki=50. I collected the data and tried the different K values before plotting it, so at the time I wasn't aware I should try higher values. I'll try kp=15000, 20000, 25000, etc later today

I did notice that 'run-pi-test2' would take a few tries to get usable data; often it would only return slight dips or a near-constant flat line. These plots are made from an average (6-9 runs out of ~20 for each setting) of the usable data for its respectable setting

[MPaulHolmes]

what motor do you have again wootwootman? And what voltage are you running this test at?

[wootwootman]

Originally Posted by MPaulHolmes

what motor do you have again wootwootman? And what voltage are you running this test at?

It's a 2013 Leaf motor with a 13S Lipo (48V nominal, 54.6V peak) pack made from C-Max cells. I'm planning on eventually using the rest of the cells in my pack to bring the total to 38S (140.6V nominal, 159.6V peak)

Along with changing kp, I've also noticed a difference in changing the kp/ki ratio. In the attached pic, four usable results were averaged for ki=400 and six for ki=322. It seems going from the suggested ~60 (ki=322) to 50 (ki=400) works faster. I'll stick with this ratio and keep raising kp

EDIT: Added some kp=30,000 results. Wondering what the deal is with the occasional undershoot, it might've effected my previous average plots. Or are those undershoot-ing results the ones I'm supposed to be looking for?

[MPaulHolmes]

It's OK to err on the side of gentler convergence rather than most harsh convergence. Any undershoot means that it's too aggressive, and the Kp and Ki should be reduced some.