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

Register Now
 Remember

 The Following 2 Users Say Thank You to MPaulHolmes For This Useful Post: dave koller (11-01-2015), thingstodo (11-01-2015)
 Today Popular topics Other popular topics in this forum...
 11-01-2015, 05:45 PM #2272 (permalink) Master EcoModder     Join Date: Oct 2012 Location: USA Posts: 1,408 awesomer - '04 Toyota prius Thanks: 102 Thanked 252 Times in 204 Posts 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!
 The Following 2 Users Say Thank You to P-hack For This Useful Post: e*clipse (11-02-2015), MPaulHolmes (11-01-2015)
 11-02-2015, 12:11 AM #2273 (permalink) EcoModding Lurker   Join Date: Nov 2015 Location: India Posts: 3 Thanks: 0 Thanked 0 Times in 0 Posts 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???
11-02-2015, 01:35 AM   #2274 (permalink)
Permanent Apprentice

Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 314 Times in 215 Posts
Quote:
 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

 11-02-2015, 01:47 AM #2275 (permalink) Permanent Apprentice   Join Date: Jul 2010 Location: norcal oosae Posts: 523 Thanks: 351 Thanked 314 Times in 215 Posts 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
11-02-2015, 09:42 PM   #2276 (permalink)
Master EcoModder

Join Date: Sep 2010
Posts: 1,488

Ford Prefect - '18 Ford F150 XLT XTR

Tess - '22 Tesla Y LR
Thanks: 747
Thanked 565 Times in 447 Posts
Quote:
 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
Attached Thumbnails

Attached Files
 Siemens encoder test 3-7.zip (7.8 KB, 28 views)

Last edited by thingstodo; 11-05-2015 at 01:54 PM.. Reason: Add video links

 The Following 2 Users Say Thank You to thingstodo For This Useful Post: MPaulHolmes (11-03-2015), mpgmike (02-26-2022)
11-03-2015, 01:08 PM   #2277 (permalink)
PaulH

Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,202 Times in 765 Posts
Quote:
 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.
Quote:
 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
Code:
```	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??
}```
Quote:
 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.
Quote:
 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.
__________________
kits and boards

11-03-2015, 01:16 PM   #2278 (permalink)
PaulH

Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,202 Times in 765 Posts
Quote:
 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.
__________________
kits and boards

 The Following User Says Thank You to MPaulHolmes For This Useful Post: e*clipse (11-03-2015)
11-03-2015, 03:12 PM   #2279 (permalink)
Permanent Apprentice

Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 314 Times in 215 Posts
Quote:
 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.

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

 The Following User Says Thank You to e*clipse For This Useful Post: MPaulHolmes (11-03-2015)
 11-03-2015, 03:58 PM #2280 (permalink) PaulH     Join Date: Feb 2008 Location: Maricopa, AZ (sort of. Actually outside of town) Posts: 3,832 Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000 Thanks: 1,368 Thanked 1,202 Times in 765 Posts That was an interesting PDF (I've only read the first one so far). How close are your 2 phase sensors? __________________ kits and boards