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

[e*clipse]

Originally Posted by danibjor

True



Here in Norway we have 3-phase 400v, so that would make for a supercharger if 3-phase could be used - all built into the inverter without much extra cost.

Charging a 6-800v batterypack with decent range would take some time with a regular charget - not to mention the price tag on a charger of that scale.

If the controller can handle the charging too - that would be a great leap forward in DIY EV.

- Daniel

Boy, that would be awesome! I paid a fair chunk of change to get 3phase 480 in my machine shop years ago. Rectified 3 phase is a LOT smoother than rectified single phase.

My solar system puts out about 360VDC. I'd love to do something simpler like a 2X boost converter as my charger using the DC from my solar system. I think this is completely do-able with the motor controller, but I'm not sure what the advantage would be.

For a charger, to control the voltage, I built a system that uses the BMS's information to control the charger. It tracks the voltage of each cell, turning of/on the charger based on that information. (pulsed charging method) The boost converter's controller controls current, and the current is driven by the difference between the boost converter's voltage and the pack's voltage. So, in a way, the output voltage of the charger is not important.

BTW, I'm also going for the fun side for my EV. As a base, it's starting with an AWD Mitsubishi Eclipse. The final car will be AWD, with much better suspension and power control. The weight will be the same, or lower than the original car with slightly more power. (but a LOT more usable torque. )

[MPaulHolmes]

It's so much fun reading all the new posts when all I did was go to costco and eat some pizza. haha. The controller on instructables doesn't have voltage monitoring, but it can control current precisely into the battery pack or from the battery pack.

Here's the piece of code that controls the current into the battery without knowledge of the pack voltage:

	batteryCurrentLong = __builtin_mulss(Ia,pdc1) + __builtin_mulss(Ib,pdc2) + __builtin_mulss(-Ia-Ib,pdc3);  // batteryCurrent is in [-4096*sqrt(3)/2, 4096*sqrt(3)/2] = [-3547, 3547].


if (batteryCurrentNormalized < -maxBatteryCurrentNormalizedRegen) { // maxRegenCurrent is negative.  Computed in "InitializeThrottleAndCurrentVariables()".
		// averageDuty = (pdc1+pdc2+pdc3)/3.  But division is slow.  So, do this instead:
		// averageDuty = 65536 * ((pdc1+pdc2+pdc3)/3) / 65536
		// averageDuty = 21845 * (pdc1+pdc2+pdc3) / 65536
		// averageDuty = (21845 * (pdc1+pdc2+pdc3)) >> 16
		averageDuty = __builtin_mulss(21845, pdc1+pdc2+pdc3) >> 16;	// avoiding divide by 3.  HAHA.  
		if (averageDuty > 0) {
			temp = -__builtin_divsd(maxBatteryCurrentNormalizedRegen,averageDuty); // This is the first try at IqRefRef.  Later, other values will be calculated based on throttle.  Keep the one closest to zero.
			if (IqRefRef < temp) {
				IqRefRef = temp;  // if it was more negative, then make it smaller in magnitude, 'cuz there's too much friggen current going into the batteries!!!
			}
		}
	}

By the way, I've fixed a few bugs and sensorless is so close to being debugged and working! The code now is much more complete and fancy than the instructables code. well, I think it's gotten better. I'll upload it in just a couple days once it's in a useable place.

EDIT: Without voltage monitoring (which is super easy to include, and actually was included on the revision board that got stolen that was on my laptop, but I'm not angry at all. nope), I think the controller could precisely command constant current into the batteries, somehow using the motor windings for an inductor, but it wouldn't know when to stop, unless it was told somehow. I haven't seen the link you guys are talking about, but I know it could be done. I just feel it way down deep.

[thingstodo]

Originally Posted by danibjor

Well, you don't have to make the end goal on day one. But it has to be modular enough to reach the goal without throwing away everything every time you upgrade it.

Motors can be upgraded. Batteries added to the pack without throwing away old stuff. BMS should be somewhat modular so it can be extended.

A 200kw controller would go a long way. And this one is really affordable - and the power stage can be upgraded.

I found a used Nissan Leaf motor (those are rated 80kw/110hp and 280nm) - for just over $2k. Somthing like that would be more than enough to get to work.

I got a good deal on a couple of DC motors so I bought them used, along with the DC controllers, the forced air cooling for the motors, a programmer for the controllers, partial wiring harnesses, and supposedly some support from the vendor. So I bought into older DC technology.

It turns out that the failures that guys have been seeing on DC motors may have to do with heat build-up - the DC motors, even with fan cooling, can't get rid of heat well. After you drive them for an hour or more on the highway (which you can do with a Lithium pack), they kinda start to melt. Not the first time, maybe it cooks some varnish the first time. But a bit more each time, until there is a failure.

The battery pack is from Renault/Better Place - essentially a Leaf pack. 16S3P for 128V at 180A for an hour, or more like 240A for about 40 minutes

I'm converting a 92 Mazda MX-6 with 360,000 km on it. It has a limited lifetime (not the electric drivetrain - the car itself).

If I put too much power into the drivetrain, I'll break something

So I bought electric components that were sized for a fun drive, but put them into a car that is well-worn.

Most of it - motors, controller, batteries, contactors, liquid cooling ... can all be put into the next vehicle. I'm out the parts and effort on the battery box, a transmission adapter, and a lot of labour but not a lot of cash .. unless I overheat the DC motor somehow

[thingstodo]

Originally Posted by MPaulHolmes

It's so much fun reading all the new posts when all I did was go to costco and eat some pizza. haha. The controller on instructables doesn't have voltage monitoring, but it can control current precisely into the battery pack or from the battery pack.

Here's the piece of code that controls the current into the battery without knowledge of the pack voltage:

	batteryCurrentLong = __builtin_mulss(Ia,pdc1) + __builtin_mulss(Ib,pdc2) + __builtin_mulss(-Ia-Ib,pdc3);  // batteryCurrent is in [-4096*sqrt(3)/2, 4096*sqrt(3)/2] = [-3547, 3547].


if (batteryCurrentNormalized < -maxBatteryCurrentNormalizedRegen) { // maxRegenCurrent is negative.  Computed in "InitializeThrottleAndCurrentVariables()".
		// averageDuty = (pdc1+pdc2+pdc3)/3.  But division is slow.  So, do this instead:
		// averageDuty = 65536 * ((pdc1+pdc2+pdc3)/3) / 65536
		// averageDuty = 21845 * (pdc1+pdc2+pdc3) / 65536
		// averageDuty = (21845 * (pdc1+pdc2+pdc3)) >> 16
		averageDuty = __builtin_mulss(21845, pdc1+pdc2+pdc3) >> 16;	// avoiding divide by 3.  HAHA.  
		if (averageDuty > 0) {
			temp = -__builtin_divsd(maxBatteryCurrentNormalizedRegen,averageDuty); // This is the first try at IqRefRef.  Later, other values will be calculated based on throttle.  Keep the one closest to zero.
			if (IqRefRef < temp) {
				IqRefRef = temp;  // if it was more negative, then make it smaller in magnitude, 'cuz there's too much friggen current going into the batteries!!!
			}
		}
	}

By the way, I've fixed a few bugs and sensorless is so close to being debugged and working! The code now is much more complete and fancy than the instructables code. well, I think it's gotten better. I'll upload it in just a couple days once it's in a useable place.

Looking forward to it! Maybe I could get a copy of the code as well this time around?

EDIT: Without voltage monitoring (which is super easy to include, and actually was included on the revision board that got stolen that was on my laptop, but I'm not angry at all. nope), I think the controller could precisely command constant current into the batteries, somehow using the motor windings for an inductor, but it wouldn't know when to stop, unless it was told somehow. I haven't seen the link you guys are talking about, but I know it could be done. I just feel it way down deep.

Link we are discussing Patent US4920475 - Integrated traction inverter and battery charger apparatus - Google Patents

I didn't realize that there was hardware installed to monitor voltage on the pack. More stuff to add sometime in the future, when the control stuff has been worked out

[e*clipse]

Originally Posted by MPaulHolmes

	batteryCurrentLong = __builtin_mulss(Ia,pdc1) + __builtin_mulss(Ib,pdc2) + __builtin_mulss(-Ia-Ib,pdc3);  // batteryCurrent is in [-4096*sqrt(3)/2, 4096*sqrt(3)/2] = [-3547, 3547].


if (batteryCurrentNormalized < -maxBatteryCurrentNormalizedRegen) { // maxRegenCurrent is negative.  Computed in "InitializeThrottleAndCurrentVariables()".
		// averageDuty = (pdc1+pdc2+pdc3)/3.  But division is slow.  So, do this instead:
		// averageDuty = 65536 * ((pdc1+pdc2+pdc3)/3) / 65536
		// averageDuty = 21845 * (pdc1+pdc2+pdc3) / 65536
		// averageDuty = (21845 * (pdc1+pdc2+pdc3)) >> 16
		averageDuty = __builtin_mulss(21845, pdc1+pdc2+pdc3) >> 16;	// avoiding divide by 3.  HAHA.

EDIT: Without voltage monitoring (which is super easy to include, and actually was included on the revision board that got stolen that was on my laptop, but I'm not angry at all. nope), I think the controller could precisely command constant current into the batteries, somehow using the motor windings for an inductor, but it wouldn't know when to stop, unless it was told somehow. I haven't seen the link you guys are talking about, but I know it could be done. I just feel it way down deep.

Just wondering - after looking at the 3rd drawing in that patent again. The positive goes into one phase (lower right in the drawing) and then returns through the other two. Perhaps it would be possible to modulate the other two so that there would be zero torque?? It would require good knowledge of motor position when parked, and the goal would be opposite of FOC's goal. That would make a converter that uses a BLDC motor for the inductor possible. Also - the inductance of my motor is very low - about 1.4mH.

On another note, I've been trying to understand the sensorless code. To start, it looks like a LOT of the code is induction motor specific. It seems just dealing with the slip issue requires about 15pages of code. - PLEASE NOTE - I'm not criticising here - I'm sure you've made it as clean as possible; and I certainly dont have the patience to make a clunky version of it.

Maybe at some point, it would help to make two versions of the code - one for asynchronous motors and one for synchronous motors?

Also, it looks like only one place needs angle information - the Park and inverse Park transforms. Both of those use both sin and cos, which are supplied by the resolver. The problem I'm trying to work around is the resolver's 90* shifted cosine and the fact that there are two motor electrical revolution per resolver revolution. I think some cleverness with trig identities may help.

Also - what does this do? - the "bultin_mulss" part??
(_builtin_mulss(Vd, sin_theta_times32768)

- E*clipse

[danibjor]

Originally Posted by e*clipse

Also - what does this do? - the "bultin_mulss" part??
(_builtin_mulss(Vd, sin_theta_times32768)

- E*clipse

Built-in functions that are specific to 16-bit devices, that give the C programmer access to assembler operators or machine instructions that are currently only accessible using inline assembly, but are sufficiently useful that they are applicable to a broad range of applications. Built-in functions are coded in C source files syntactically like function calls, but they are compiled to assembly code that directly implements the function, and do not involve function calls or library routines.

__builtin_mulss

Description: 
Computes the product p0 x p1. 
Function arguments are signed integers, and the function result is a signed long integer. 
The command-line option -Wconversions can be used to detect unexpected sign conversions.

Prototype: signed long __builtin_mulss(const signed int p0, const signed int p1);

Argument: p0 multiplicand 
          p1 multiplier

Return Value: Returns the signed long integer value of the product p0 x p1.

Assembler Operator / Machine Instruction: mul.s

- Daniel

[MPaulHolmes]

Ya, the mulss takes a couple cycles off the normal multiply. I think because there are 4 variations:
mulss
mulus
mulsu
muluu

(signed signed)
(unsigned signed)
(signed unsigned)
(unsigned unsigned)

And if you know what type you are using, the compiler doesn't have to check and maybe saves a little time somehow?

Now for the sensorless,

Ealpha = Valpha - statorResistance*IAlpha - statorInductance*dIAlpha/dt
Ebeta = Vbeta - statorResistance*Ibeta - statorInductance*dIbeta/dt

(Valpha, Vbeta, Ialpha, and Ibeta are all just stuff that you get during the clarke and park transforms and inverse transforms. The steps are identical for ACIM and permanent magnet AC)

EDIT: OK I had made a mistake, and you can't just get the rotor flux angle that way. There's an offset that depends on the speed of the motor. Oh well. It's sort of working now though.

[e*clipse]

Originally Posted by MPaulHolmes

Ya, the mulss takes a couple cycles off the normal multiply. I think because there are 4 variations:
mulss
mulus
mulsu
muluu

(signed signed)
(unsigned signed)
(signed unsigned)
(unsigned unsigned)

And if you know what type you are using, the compiler doesn't have to check and maybe saves a little time somehow?

Now for the sensorless,

Ealpha = Valpha - statorResistance*IAlpha - statorInductance*dIAlpha/dt
Ebeta = Vbeta - statorResistance*Ibeta - statorInductance*dIbeta/dt

(Valpha, Vbeta, Ialpha, and Ibeta are all just stuff that you get during the clarke and park transforms and inverse transforms. The steps are identical for ACIM and permanent magnet AC)

EDIT: OK I had made a mistake, and you can't just get the rotor flux angle that way. There's an offset that depends on the speed of the motor. Oh well. It's sort of working now though.

Very interesting - ok - that saves some computer time.

I was wondering why they would use the resolver timing they did in conjuction with the motor's electrical timing. How 'bout this one - it seems those 'Yota engineers are pretty clever:

We have to dig into some of that trig stuff we learned many moons ago - my dad reminded me of their existance... trig identities like the double angle identities:

sin2A = 2*sinA*cosA
cos2A = 2*(cosA)^2 -1 = 1 - 2*(sinA)^2

So, if the resolver output is the right side of the equation, the left side always works out to be the rotor's electrical position. ( for Toyota hybrid motors using a 4 pole pair motor and a 2 pole resolver )

How does this tie into the motor controller stuff? For FOC, we need to convert to an orthogonal coordinate system using a Clarke and Park transform then do some control stuff (like the PI loop) then convert it back to reality using inverse Park and Inverse Clarke transforms.
Fortunately, the Clarke and inverse Clarke transforms don't require any angle information. The Park transforms do:
Park transform:
Id = Ialfa * cosA + Ibeta * sinA (I'm using A instead of theta to illustrate )
Iq = -Ialfa * sinA + Ibeta * cosA

The inverse Park transform:
Valpha = Vd * cosA - Vq * sinA
Vbeta = Vd * sinA + Vq * cosA

Now, if the resolver were directly synch'd with the motor this would be easy - just use the resolver output directly. Why the heck would they use the relationship they did? It turns out it's not too much more difficult - just use the double angle identities and go on your merry way!

- E*clipse

[e*clipse]

OK, maybe some progress for the rev0 board:

I made an adapter so the ICD2 could be used. I also wrote a stupid little "hello world" program that would blink the LED @ pin 16. There is also an AtoD converter that will take the input from RB0.

Program compiles, etc.

1) Powered up board - pins 40 and 21 measure 4.96 V referenced to pin 20 (control gnd)

IDC2 ok with Vdd - no error

However, I got these warnings from the ICD2:
ICDwarn0052 "ICD2 cannot validate target device"

Ignored this error and tried to program anyway:

ICD0161 "verify failed Test address 0x800000 expected val 0x40080 val read 0x0

One problem may be the connection to the MCLR pin - when connected to the ICD2, it measures about 2.86V - I don't know if this is a problem or not.
Also, the ICD2 manual says "NO capacitor from MCLR to ground, as this will prevent fast transitions of Vpp. A simple pullup resistor is sufficient."

suggestions? Does the PICKIT3 say anything about MCLR?

Thanks a bunch,
E*clipse

[danibjor]

Did you guy's see the chip from TI that has built in sensorless control? Motor Control Solutions - TI InstaSPIN-MOTION - TI.com