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

[MPaulHolmes]

Hi Chinuhark! I wrote the FOC code from scratch without using or even looking at any other code. I agree that debugging becomes almost impossible if you are using stuff that you don't completely understand yourself. I actually think that's why just about all modern software has to have a new critical update every single day. People are using classes that are based on classes that are based on classes.... And nobody really understands what the heck they are even using in their code.

OK, you ask great questions! Here's what I did for the rotor time constant PI loop tuning:

First, you do the loop tuning. Tune the motor at ZERO rpm. Lock the rotor, or don't lock it. It doesn't matter. Your tests will inject current for maybe 0.01 seconds at a time. That's not enough time for the rotor to start spinning. Set the rotor flux angle to ZERO. You need to be able to command current for Id AND Iq, but it turns out that the same PI constants work for commanding Id to IdReference and Iq to IqReference.

I used an autotuning process that ran each <P,I> pair through a series of tests. If <P,I> passed those tests, then it was good a good choice for the PI loop. Here's what the test on each <P,I> looked like:

IdRef = 0 amps
IqRef = 10 amps (or whatever is good enough for the current sensor you are using)
Start with P = SOME SMALL START VALUE, I = P / 100.
Then, run your test. You should only need about 50 or 100 iterations at most. Every motor I've tested converges in maybe 10-30 iterations, when each iteration is happening at 10KHz. So, convergence should only take 1-3msec. So, save the 100 values of IqFeedback, and then graph them. You want IqFeedback to converge to IqReference with no overshoot and no oscillation. If it doesn't do that, increase P a little, and then let I = P/100 again (or I = P/80 or whatever) and run the test again. Stop the testing when the convergence is as fast as possible.

Now, for finding the rotor time constant, I make sure my P & I values are all plugged in and ready to go. Now, you need to bring in that horrible algorithm for finding the rotor flux angle. Assuming there are no mistakes in that, you just go through possible rotor time constants, starting at around 0.010 seconds, and go up to maybe 0.150 seconds. That will cover a wide range of AC induction motors. Try each one, seeing which one accelerates the motor to the highest RPM in, say, 1 second. Or, you can just see which rotor time constant gives you the highest steady state RPM. I think I ended up with the same rotor time constant for both of those separate tests.

The sensorless would work barely OK as long as the inductance and resistance was known almost exactly. It's a little like balancing a ball on the head of a pin. As long as the constants are good, the ball will stay up there, but if they are a bit off, the ball will fall in a short time. A nice happy medium would be, say, at least 1 pulse per mechanical revolution used in conjunction with sensorless code. The sensorless could carry you through the revolution, and as soon as the "ball was going to fall off the pin head", you would be brought back to reality with the pulse. That would allow for a crappier estimate of the stator/rotor inductance and stator resistance.

[P-hack]

given the noise issue, you can also consider using the analog output of the MLX91206 to generate a 4-20ma current loop at the sensor. Though it sounds like the sensor itself doesn't like the extra flux.

btw, nice time constant explanation!

[chinuhark]

Thanks for the excellent explanation. I am thinking I should stop worrying about tuning and parameters as it's not as difficult as I'm making it out to be in my head.

Now vector control seems to be quite straight forward and simple to me but it's all a moot point without the rotor field angle isn't it?

The following equations are the most important part of the process and crucial to the working of the whole scheme and are troubling me:

1) im = im + (T/Tr)(id - im)

2) fs = (P/2).n + iq / (Tr.wb.im)

3) Angle = Angle + T.wb.fs

ISSUES:

1)The first issue is the fact that we need angle for id,iq and id,iq for the angle. The classic chicken and egg situation. So does taking initial id,iq as a random value say zero just work. Like do all three converge to the correct value in a few iterations in a closed loop fasion?

2) We have im in the denominator in the second term which will most probably be zero the first time we execute. Won't there be divide by zero problems or does a simple condition like " if im = 0, im = 0.000001" solve this?

BIGGEST ISSUE:

While I understand the above procedure conceptually, i.e. we are simply calculating the rotor field speed and then integrating it over time to get the position, what bothers me is that without knowing the initial position, it doesn't make any sense to me. I mean we will have an angle that will increment every cycle at the right rate but how can it be the actual rotor angle? I mean both equations 1 and 3 use initial values and increment them but we are taking random values/zero the first time this is done?

Do we directly start in vector control mode from zero speed or first give it a little push using a simple V/f rotating field?

This also got me curious as to how it's done in Permanent magnet motors. Do they use a simple incremental encoder, or an absolute encoder and does a magnetic north have to be physically aligned with the encoder???

[e*clipse]

Originally Posted by P-hack

given the noise issue, you can also consider using the analog output of the MLX91206 to generate a 4-20ma current loop at the sensor. Though it sounds like the sensor itself doesn't like the extra flux.

btw, nice time constant explanation!

That sound very helpful. Could you point to where that's explained? I couldn't find it in the data sheet.

Thanks a bunch,

E*clipse

[e*clipse]

On changing over to the 6010A controller and adding capability for a voltage booster:

I've added the extra pwm4L and pwm4H driver circuits.

I've also added an extra current sensor circuit using a LEM sensor; I'll switch these over to the Melexis support circuits next. Of course any of this extra capability could be ignored if the person using this wants a "simple" 3 phase controller.

Also, I added the extra current sensor to the fault logic, along with the hardware PWM output overrides for pwm4L and pwm4H.

BTW, what is the logic for choosing the particular IC pins you used for this? There seems to be no particular order; the best I can guess is you wanted straightforward routing to the drivers. This seems like something that could be changed when routing the board. Is this correct?

- E*clipse

[thingstodo]

Originally Posted by thingstodo

Update for Sep 24

Summary: My encoder no longer works with the AC controller
...

Sep 24 - Oct 28 is quite a while between updates!
Here is the update for Nov 1 - actual testing is done!

Using a breadboard I patched pull-up resistors (10K) plus parallel ribbon cable between the encoder and controller

After power up:
run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00001x
turn shaft
run-encoder-test shows 00001x
hmm ...

Check pin voltages
1 = gnd
3 = 0V
4 = 4.92V
5 = 4.90V

4.92V for the 5V pin is a bit low. 4.90V for a pulled-up pin is too high! That's not enough voltage drop across a 10K resistor.
Check pins - find a short between the resistor leads (resistor twisted on the breadboard)

run-encoder-test shows 00001x
turn shaft
run-encoder-test shows 00061x
turn shaft
run-encoder-test shows 00075x

OK - we have a signal.

Attached picture shows the mess that the cable is.

motor -> rj45 adapter (has the pins) -> cat5 cable -> rj45 adapter (pins to breadboard) -> resistor network -> ribbon cable -> control board

First update: add the EVTV screw-in adapter on the motor side. This holds the female pins and makes the insertion and removal more secure
power off
remove pins from motor
insert pins into adapter
insert adapter into motor
power up and test

1 - white
2 - brown
4 - orange
5 - blue

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00000x
turn shaft

OK - pull apart the new part - the screw-in adapter - and check
power off
pins look right
pins are pushed in far enough
put adapter back on motor
screw in more forcefully. The threads on the connector need to disappear for the connector to be on all of the way. The connector is moisture-tight so you need to twist pretty hard.
push the pins in as far as they will go
power up

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00000x

I made a full turn. It should show about 64

turn shaft
run-encoder-test shows 00000x

still no change. Go back to the female pins on the encoder male pins - no adapter

power off
the pins were bent (!!) I guess my needle-nosed plier work was a bit too agressive and I bent the pins so that they would not fit on the adapter.
Straighten them out a bit and use the female pins directly
1 - white
2 - brown
4 - orange
5 - blue

run-encoder-test shows 65534x
turn shaft
run-encoder-test shows 00034x

Success!

Turn off the power and try the adapter again
still can't get it to work. Move back to the female pins directly and get on with some testing!

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00028x

Success! Sort of, I guess.

How to make the cable with the pull-up resistors?
the connector sets I am using are old - rj45 <-> RS232. The pins for rs232 kinda fit the siemens
motor encoder.

I have a bunch of these. I'll use two cables
motor encoder -> rj45 adapter -> cat5 cable -> rj45 adapter
rs232 pins cut off incoming side and soldered to perfboard with pull-ups
rs232 pins cut off outgoing side and soldered to perfboard
rj45 adapter - cat5 cable -> rj45 adapter -> soldered to 5 pin header for controller

power up

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00047x
make a full turn
run-encoder-test shows 00298x
64 counts per rev, 4 transitions per count = 256. 256 + 47 = 303 so I was out by 5 counts

Pretty good!

Try the motor encoder to adapter again. This time, after power down, put the adapter into
the motor fully first. Then insert the female pins into 1,2,4,5 as white, brown, orange, blue

mark how far the pins and wires go in.
power up and try it.

I can't figure out how to mark how far the wires are inserted. But it failed.
run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00000x
Marking all of the wires at once with a wrap of tape gives about 30 mm from one edge of teh
adapter to the end of the pins. Measuring the adapter by itself 30 mm appears to reach
from the edge of the adapter to the seated face of the pins
The adapter tightens all of the way in, the last 2 turns against gasket #2 for a nice tight
fit.

I can't get it to work.

Alternate - push the female pins through a wooden plug 19 mm in diameter (plug from a 1 inch hole saw looks about right)
about 1/2 inch deep (use 3/4 inch plywood to leave a 1/4 inch lip)

1 inch hole saw plug is 21 mm in diameter. use 7/8 instead
1 inch works better, with a file to trim it down. It needs to be a tight fit to keep
the pins aligned.

Drill through the 4 pins needed. Add female rs232 pins from the non-cable end and solder
the part that sticks out of the cable end to the rj45 connector.

See if it works!
Nope.

power up

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00000x

So the pins must not be aligned. The 1/8 holes in the disk are as tight as I
can make them.

Try the alignment again.
nope

power up

run-encoder-test shows 00000x
turn shaft
run-encoder-test shows 00000x


So I think I need to make thinner disks so I can see the pins
connector with pins showing -> disk1 -> female pins -> disk2

That way I can see the pins engage. Maybe I can use silicon to fill in the gaps?

After several prototypes - none of which works - I've given up.
female rs232 pins are inserted into the connector on the motor, over the male pins,
one at a time. Push some slack into the connector. tape it down well. It runs, for now!

Next up, burn the latest firmware I have and run-rotor-test.

SensorlessFOC 150918 fixed.hex dated Sep 21

power up on 12V only
capture Siemens encoder test 5.txt
turn by hand - looks good!

max-rpm 3000 and encoder-ticks 64
config looks right

Check pack voltage 123.5V
shut off the controller, turn on the pack, turn on the controller

run-rotor-test
... it appears to have failed? output is mostly 0's with a couple of 3's?
Try the control anyway.
Press 2 <ENTER> several times. The motor starts .. ramps slowly up ... more 2 <ENTER> and I get up to 3000 rpm and overspeed fault is triggered? I showed about 2900 rpm on my handheld tach. So the controller knows what speed the motor is turning.

capture Siemens encoder test 6.txt
run-rotor-test with no changes to settings and see what happens - max-rpm still 6000, encoder-ticks 1000 instead of 64.

Same output. All 0's except for a couple of 3's.

Control is OK with 2 <ENTER>

Verify that DC motor turns the same direction as the AC motor turns, when DC motor is connected to 12V battery. Good news - it does!

Check no load rpm on 12V battery.

I think I changed to capture Siemens encoder test 7.txt somewhere here

Check if regen works on the AC controller when the 12V battery is driving the DC motor. Yes.

The AC controller is getting hot. Time to call it a day. I need to figure out an easy and cheap way to make a chill plate.

There is video. The audio is HORRIBLE with the motors running. I'll see if I can salvage something. I want to try something new - leave the audio on the left channel as recorded and do a voice-over on the right channel. That way I can listen to the howl of the motors and make out what I'm saying, but you can turn that down on playback and just get the information that I was saying.

If it works, I'll edit this post when I get the video uploaded.

EDIT
- link to coupler video https://youtu.be/zZl_PciIN0U
- first spin with 64 ppr encoder https://youtu.be/ozhHnqr_Ar4
- second spin with 64 ppr encoder https://youtu.be/B0Dw7DVt02U

[MPaulHolmes]

Originally Posted by chinuhark

1)The first issue is the fact that we need angle for id,iq and id,iq for the angle. The classic chicken and egg situation. So does taking initial id,iq as a random value say zero just work. Like do all three converge to the correct value in a few iterations in a closed loop fasion?

Yes! It just works to set them to zero, and even at zero RPM, it's maybe wrong for an instant, and then converges and everything is fine.

2) We have im in the denominator in the second term which will most probably be zero the first time we execute. Won't there be divide by zero problems or does a simple condition like " if im = 0, im = 0.000001" solve this?

I tried that first, but instead went with

	if (magnetizingCurrent == 0) {
		return;  // there is no rotor flux angle, since there is no field. So, keep the angle the same as it was before??
	}

While I understand the above procedure conceptually, i.e. we are simply calculating the rotor field speed and then integrating it over time to get the position, what bothers me is that without knowing the initial position, it doesn't make any sense to me. I mean we will have an angle that will increment every cycle at the right rate but how can it be the actual rotor angle? I mean both equations 1 and 3 use initial values and increment them but we are taking random values/zero the first time this is done?

Do we directly start in vector control mode from zero speed or first give it a little push using a simple V/f rotating field?

It's wrong for maybe 1/500 sec, and then converges to the true rotor flux angle. It doesn't take long at all. We get a true mechanical speed, and a true magnetizing current, and Id feedback, and Iq feedback that converge in like 1-2msec, and from that you get a true slip speed, etc... and badabing badaboom, we are in business.

This also got me curious as to how it's done in Permanent magnet motors. Do they use a simple incremental encoder, or an absolute encoder and does a magnetic north have to be physically aligned with the encoder???

The absolute encoder position won't likely be aligned with the the rotor flux angle, so you can set IdReference to some nonzero value, and IqReference to zero, and then you keep making different offset guesses. Once the motor stops turning, you found the right offset. Then, for all eternity, you save that offset, so that as soon as your motor spins past that index pulse (on the absolute encoder) for the first time, you know what true rotor flux angle you are at. You just add the offset you found that was saved to the EEProm.

[MPaulHolmes]

Originally Posted by e*clipse

BTW, what is the logic for choosing the particular IC pins you used for this? There seems to be no particular order; the best I can guess is you wanted straightforward routing to the drivers. This seems like something that could be changed when routing the board. Is this correct?

- E*clipse

Do you mean the PWM1H, PWM1L, ..., etc? Or do you mean other pins? All the other pins were semi-random, and mechanically convenient for routing.

[e*clipse]

Originally Posted by MPaulHolmes

Do you mean the PWM1H, PWM1L, ..., etc? Or do you mean other pins? All the other pins were semi-random, and mechanically convenient for routing.

Thanks - I was referring to the pins on the logic gates - for example PWM1L being connected to U11b with the output PWM1L_AFTER_FAULT

I was wondering why it's neighbor on the logic IC, for example is PWM2H. You've cleared that up - thanks!

Regarding the current sensing, I've found some more info that helps with shielding around the Melexis current sensors. The info looks pretty sophisticated, with magnetic FEA programs, etc. However, I think we can use some simple rules of thumb to make a make useful shields for this purpose. A company in Switzerland sells them, but they look pretty easy to make.

http://www.google.com/url?sa=t&rct=j...GTfNDbdnEHSrtQ
http://www.google.com/url?sa=t&rct=j...KPGO3xU1WmRewA
http://www.maglab.ch/uploads/media/UCR3.5-T-2.jpg
http://www.maglab.ch/uploads/media/2..._rev003_01.pdf

The bottom line from the first link is that magnetic cross-talk between the 3 phase output channels can hurt the current sensing accuracy. Completely wrapping the wire in a rectangular shield actually didn't help the sensor. However, a U-shaped sensor - like the ones shown on the Melexis data sheet - both straightened and enhanced the magnetic field for the sensor and shielded the magnetic field from other stuff. So if the simple rule of thumb guidelines on the Melexis sheet are followed making a shield should be NBD.

There seems to be no maximum length. So, for the round inverter design, a shield that extends from the circuit board to the top cover would serve the dual purpose of shielding the controller stuff from the magnetic fields in the output wires and focus the fields for the current sensors.

- E*clipse

[MPaulHolmes]

That was an interesting PDF (I've only read the first one so far). How close are your 2 phase sensors?