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

[e*clipse]

Awsum. I've gotta job then.

[e*clipse]

Here's a document from TI about modulation techniques. If this link doesn't work, try post# 69 on DIYEV:
DIY Electric Car Forums

Toyota IPM Motor Controller Design Details - Page 7 - DIY Electric Car Forums

The problem we're going to encounter (especially with internal permanent magnet BLDC motors) is that we may have to change modulation techniques as we approach the top speeds (around 10,500 RPM )

Originally posted by Coulomb at DIYEV:
I think it just means using square voltage waves, or trapezoid voltage waves, to drive the motors.

If you apply say 110% modulation (where 100% modulation uses all your available DC bus voltage, i.e. you are using everything from 0% to 100% PWM ratio), then the peaks of your generated sine waves will be clipped. In other words, your PWM ratio will go to 100% and 0% for a significant part of the sine wave; you'd like to go to 105% and -5%, but of course you can't.

As you increase the modulation past 100%. you "go further into the over modulation region", and the clipping gets worse and worse. Your sine waves go from correctly rounded to a little clipped to trapezoidal to (eventually) practically square waves.

Of course, IPM motors are typically designed to be driven like this. I think I read somewhere that the Prius switches from PWM modulation to actual direct square waves (in the latter, you don't bother chopping up the signal at a PWM frequency, you just switch hard on and hard off at the electrical frequency of the motor). This switch is based on motor speed; PWM below that speed, square waves above that speed.

I don't know what the shape is below that speed (it would presumably be sine waves or trapezoid waves, or maybe something that better matches the back-EMF shape.)

In general, there's the problem of the BEMF approaching the DC Bus voltage. This can be mitigated by advancing the current angle so that the reluctance torque increases as a percentage of the total torque. This is why I was dancing around the room when I saw you were doing a FOC 3-phase controller. It will require pretty good resolution of both physical rotor angle and current angle (probably within 5 or 10 degrees) There's a graph of this effect on page 62 of the ORNL 2010 Prius Evaluation.

Ok, the other problem is the switching speed, combined with the amount of poles and the motor's rotating speed. At some point the controller has a hard time keeping up. At play here is the PWM resolution, microcontroller clock frequency, number of calculations necessary, and even the IGBTs' switching speed.

It seems to me that changing switching methods could result in some problems; at the very least, inefficiencies and power loss at high speeds because it's no longer optimized.

So, I'm wondering how possible it would be to design the switching method to be the same, not go to some big compromise like big on-off blocks above a paticular speed. This may take some compromises in PWM resolution and calculation resolution, and some real cleverness with efficient (mathmatically) calculations.

Thoughts? or am I making a mountain out of a molehill?

[MPaulHolmes]

This is not a mountain out of a molehill. This is the absolute crux of everything. All last night I was looking at the assembly language version of the FOC code, counting cycles. I wrote it all in C, but might have to convert a little of it to assembly language:

Checking the motor position at 10KHz:
rpm..........................degrees/pwmPeriod
4000 ....................... 2.4
6000.........................3.6
8000.........................4.8
10000.......................6
11000.......................6.6

[e*clipse]

First, I'd just like to say how impressed I am that you are that bilingual. I learned assembly a while ago and moved on as fast as I could. I can still sort of understand it, but translating back n forth

Also, I got all my notes and proto boards together from that effort to make a resolver smoother a year ago. It's basically a collection of mostly cmos op-amps for filtering with a power op-amp and an digitally controlled analog switch.

The most expensive components are the power op-amp (which has gone obsolete ) and the analog switche. Right now, the components will be sub $10. in quantities of 1. However, it might be worth it to go for the "automotive grade" (mostly temperature) components - Thoughts?

Also, the circuit needs +/- 15V supply to power the output for the resolver. Are there any built-in power resources like that? Suggestions?

Also, I'm going to be designing a daughter board for it over the weekend.
From an interface perspective, I will make a bottom 5-pin connection that will work with the QEI pinout. The input for the daughter board will be similar to the QEI connector, except it will need power. (see above) I'm trying to make a small board that will sit over the main Ucontroller and plug into the QEI interface.

Ok, sorry to load you up with more questions (work)

Also, while going through my FOC and resolver notes from a year ago, I found something that may be helpful. I noticed in the notes, that really, the absolute angle was not used, only sin(angle) or cos(angle). It further occured to me that the resolver's output IS sin(angle) and cos(angle). Why go through the extra calculations of converting to an absolute angle and then convert back (usually through look-up tables) when the numbers may be useful directly?

Hope some of this helps...
- E*clipse

[MPaulHolmes]

Do you know what power it requires? Here's a 6w dc dc with 9-36v input:

NCS6D1215C Murata Power Solutions | Mouser
I'm on cell phone. Will write more later.

[e*clipse]

I'm sorry, I meant power sources available on the control board.

The control board gets 12V, right? I can just drive the daughter board like you drive the IGBT drivers.

No worries - enjoy your evening. I finally re-learned my circuit. I should make some dinner....

- E*clipse

[MPaulHolmes]

There's an external chassis mount 15w 9-18v input, 24v output dc dc that connects to the control board, giving it 24v. There's also a 7-36v input, 5v output on the control board. No +/-15v though. I guess you could make +/-12v out of the 24v supply? Do you know how stringent they are about the +/- 15v?

There's the ia, ib, and ic axis, all 120 degrees apart from each other. The problem is, usually encoders are not set up so that 0 degrees corresponds to ia (along the x axis). Do you know if the resolver is oriented so that ia is along what the rotor considers 0 degrees?

Your board sounds great. I was very bilingual with x86 assembly and C on my old 386 and 486 computers (and 286!) haha. You could MELT some old monochrome displays with assembly language by turning up the electron beam too high. I'm not very familiar with microchip assembly. But I can figure it out if I have to. My goal is not to use it though, so more people can make sense of what I'm doing.

I had a video game company for a year or 2 where I did lots of assembly language programming. I made a great space game that would have been cutting edge in 1985. Unfortunately, it was 1995. haha. I eventually quit programming PCs when everything left DOS, because Windows took over everything, and efficiency seemed to be flushed down the toilet. It was actually a very depressing time for me! LOL. But all the fast programming tricks I learned from all of Andre Lamothe's books (tricks of the game programming gurus, etc...) to get 30 frames per second out of a 16MHz computer have been extremely applicable for microcontroller programming. That's why I always use 16MHz now. As a shout-out to my old 386. Well, for the FOC code, I'm doing 30MHz. oh well... sorry my beautiful old computer.

I actually used a little part of one of Andre's books just yesterday. Did you know you can get a very good approximation to distance between 2 coordinate points without a square root? There's a part in the code where I need to clamp the MAGNITUDE of the vector <vq,vd> to a maximum radius. Know what Microchip did in their field oriented control code? They just wouldn't let the PWM get higher than 70% duty!!! They wanted to avoid doing a square root.
fast square root (vq < vd, and both positive):

	fastDist = vq + vd - (vq >> 1) - (vq >> 2) + (vq >> 4);

Now, that gets you within a few %. But yesterday, I found that you could just make a lookup table indexed by (vq/vd * 1024), and have the entries in that lookup table contain the error for the distance (in terms of percent). So, you can get the exact distance for any <vq,vd>!! And then you can scale vq and vd down just small enough so that they reside on the circle of maximum radius! Booya microchip! haha. Thank you Andre!

[dave koller]

Assembly language - the DNA of it all!

I still have games running at an exploratory - all in moving register contents in crazy ways !! (Dave is still lurking here )

At over 70 I still throw some in my C programs for AI - so much faster!!

[e*clipse]

Glad to see you're a fan of those old machines. Games are what first got me interested in this stuff too... I LOVED "Astroids" and locked myself in some basement closet of the physics dept (my dad taught physics) and attempted to get those advanced for the time Commodore PETs to move a spaceship around the screen...

Well, I did learn an appreciation for efficient code.

I do think that making sure we're not wasting (computer) time in unrelated places, like figuring out where the rotor is, we can spare a bit more in critical places. BTW, are you using interrupts very much?

I'm forming the carrier signal based on a simple 50% duty cycle 0-5V 20kHz square wave. Nearly any pin on the PIC can make that. If you're doing the "heartbeat" monitor, we could use that signal as a base. Therefore, if we NEED an AtoD pin, we could use the QEI INDEX pin.

Regarding this project, the power requirements are actually pretty loose. I originally thought the resolver "required" a bipolar input signal. However, I've learned - and you've probably delt with some of this 'cause you're using transformers as part of the IGBT driver: you can't pass DC. Thus the "rotating transformer" is going to center the output at 0, no matter what the DC offset of the input signal is.

This is one thing with my original resolver interface design: I put in a +/- 5V (centered at zero) signal and then pulled out a signal with a total amplitude of ~ 5V p-p. The output amplitude decreases and the carrier signal frequency increases. Now what I've realized is that the input signal doesn't HAVE to be bipolar - it could be, for example 0 > 10V and the output (whether I want it to or not) will be centered at 0. Hmmmm, that at least makes the circuit for the resolver driver (carrier signal) easier. With this, I only need a +12V or so power supply for a single sided op-amp!

Ok, what about the output? What I've learned over the last few days is that, while the circuit I designed did work, it's far from optimum because it critically relies on resistor tolerances and stuff like that. A big improvement would be to use a buffer circuit to immediately offset the signal so it's centered at 2.5V (for the AtoD converter), then filter the noise. Now the signal would range from 0>5V, and the analog switch would only have to be single ended (much cheaper, and the power supply is simply +5V) So, by adding some op-amps, I'll make the circuit much more stable, accurate and less expensive.

This will take a few more days than I planned, but I think it's worth it.

- E*clipse

[MPaulHolmes]

There's an interrupt that is run only when there's a catastrophe of desaturation detection or undervoltage, so it won't cause any problems with jitter. However, the FOC code is run at 10KHz, and is run inside an interrupt. A 2nd timer based interrupt could do its thing at 40KHz (toggle at 40KHz for 20KHz frequency), but that's a lot of interruptions. I'm not sure how long interrupts take with their pausing and returning. Maybe you could include a little attiny ($1) on the board that oscillates at any frequency that sounds good to you? I use an attiny putting out a frequency of 50KHz (updated at 100kHz) for feeding the inputs of all 6 isolated supply inputs. Fran told me that he used hundreds of attinys in his EVs that he designed (a mine blowing up machine, etc...), and has never seen one be less than 100% reliable.

On the other hand, if you are happy with 50KHz, you could use the signal from the ATTINY that's on the board! haha. Also, the jitter may not cause a problem for the FOC code if we had the main dspic30f4011 do it.