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

[thingstodo]

Update for Sep 21

Here are the raw files, put in a zip file so I don't have to split them up. There is video as well but it will be a while before I get that done.

Summary:
The encoder is working quite well now. No issues with losing speed sync ... not sure why. It likely has to do with cable routing (noise issues) but could also be the number of pole pairs

Pole pairs is 4. The rpm works out quite well - my lovely wife found my rpm meter so I cross-checked the rpm during the tests

run-rotor-test gave me very low numbers compared to my previous tests with 2 pole pairs. The current to the motor was lower, and the best results were the last set in the set of 50.

I had the motor over 4000 rpm - no issues with the motor. Issues with my encoder coupler, but none with the motor or controller.

The control is much less aggressive with 4 pairs of poles for some reason. Acceleration takes quite a while.

I need a manufacturer and a part number for the round 12 pin connectors in order to get parts - female connector and pins. I am still using the temporary setup.

I got a couple of decent 10 turn 5K pots to use for the throttle before my hall effect throttles arrive. I'm still trying to source them locally - shipping and customs from digikey and mouser kinda suck.

I also got some small pins for the encoder that should work better than what I have right now. I'd like to get the encoder built into the motor working properly.

[MPaulHolmes]

I reduced the Id and Iq down from 300,300 to 200,200, and also made the ramp up more gentle. Just for testing...

I think I may have messed up on the data dump. Notice that the graphs seem to suddenly get bigger in magnitude near the end of each dump. I had been using different parts of a big array for multiple data arrays. I may have made a mistake on something overwriting something else. I'll double-check and send you a correction if necessary. Also, the voltage and current are basically 180 degrees out of phase. That could just be data being written at the wrong offset. AND, voltage and current are the same magnitude. I find that very unlikely... voltage ranges on 0-1500 where 1500 is 124volts. Current ranges so that 4096 means 600amps.

[Piotrsko]

Any vw, ford chevy or dodge newer than 2012 should be drive by wire with a easy to junkyard hall sensor pedal assembly and harness ends. 2000 and up diesel trucks, 2010 up diesel busses. Maybe $30 usd.

[thingstodo]

Originally Posted by Piotrsko

Any vw, ford chevy or dodge newer than 2012 should be drive by wire with a easy to junkyard hall sensor pedal assembly and harness ends. 2000 and up diesel trucks, 2010 up diesel busses. Maybe $30 usd.

I'm looking for a throttle to put on my bench. The springs on vehicle throttles are strong and it's hard to keep the throttle in a consistent position for testing

2012 or newer domestic throttles from a junkyard ... that would be less expensive than the new Mopar hall effect throttles ... for my car installation.

[thingstodo]

Originally Posted by thingstodo

I need a manufacturer and a part number for the round 12 pin connectors in order to get parts - female connector and pins. I am still using the temporary setup.

I got a couple of decent 10 turn 5K pots to use for the throttle before my hall effect throttles arrive. I'm still trying to source them locally - shipping and customs from digikey and mouser kinda suck.

I also got some small pins for the encoder that should work better than what I have right now. I'd like to get the encoder built into the motor working properly.

The EVTV forum has a possible part number for the connector
MA1CAE1200 Amphenol SINE Systems | Mouser

And this manual has a wiring diagram of sorts on page 23 under circuit diagrams
Login - Forum

1 - ua1
2 - ua2
4 - power supply
5 - ground
9 - KTY + blu
10 - KTY - red
11 - KTY + Blk

What is the power supply voltage? I'll have to look through the forums again.

64 pulses per revolution - not exactly great for Paul, but Paul's perfecting the sensorless controller, so the encoder is only for an accurate tachometer!

[e*clipse]

Hey Paul,

How does your FOC part of the code deal with finding the motor position? I think I've figured out a way to (more or less) directly use the sin and cos inputs of the resolver in the SVM part of the code. My motor's resolver goes through two electrical revolutions/mechanical revolution. Being a 4 pole pair motor, there needs to be 4 electrical revolutions of the field per mechanical revolution. Believe it or not, there's a lot of symmetry with this arrangement that might provide some coding opportunities.

I don't know if you're doing the same thing, but in the Microchip "sinusoidal" example code, the SVM part of the code broke the 360* of rotor position into 6 sectors, then used the adjusted angle to calculate the PWM times.

If you do a similar thing, this may work. No lookup tables. No calculating sin, etc. No interrupts.

Is your FOC part of the code in C? Maybe I could see if there's a possibility with it. If it's in assembly, I'm not sure if I want to remind myself...

E*clipse

[MPaulHolmes]

For the permanent magnet motor, with the encoder I twisted the motor post until it just passed "index", meaning it started over. Then, I ran the motor with Id = some nonzero command
Iq = 0.

Then, let the motor turn until it stopped, and noted the angle from the encoder. Then, I saved that offset for all history for that encoder/motor pair, and then just run the FOC code with Id = 0, Iq = torque command.

The code is all in C, but there's quite a bit of optimizations done, which doesn't make it terribly readable.

A single
long int / long int takes like 25uS or something, so I have to do a bunch of sneaky stuff. I'll send it over to you to see though. The sensorless is ALMOST REALLY REALLY REALLY ALMOST ready to test. so I could send you that one. Just ignore the "sensorless" function. It is out of control. haha.

[e*clipse]

Originally Posted by MPaulHolmes

For the permanent magnet motor, with the encoder I twisted the motor post until it just passed "index", meaning it started over. Then, I ran the motor with Id = some nonzero command
Iq = 0.

Then, let the motor turn until it stopped, and noted the angle from the encoder. Then, I saved that offset for all history for that encoder/motor pair, and then just run the FOC code with Id = 0, Iq = torque command.

The code is all in C, but there's quite a bit of optimizations done, which doesn't make it terribly readable.

A single
long int / long int takes like 25uS or something, so I have to do a bunch of sneaky stuff. I'll send it over to you to see though. The sensorless is ALMOST REALLY REALLY REALLY ALMOST ready to test. so I could send you that one. Just ignore the "sensorless" function. It is out of control. haha.

I got it - awesome, Paul!

So far, the math stuff I'm doing is really simple. KISS, then I can understand it. In SVM, he did a few clever things like >>6 to divide by 64. Most of what I've figured out so far is how to calculate the sector based on boolean logic, not math.

The resolver in the MGR is adjustable; I'm assuming it's clocked to match a zero point of the stator. If not, I'll make it so.

Regarding sensorless, I've seen good possibilities with it. It seems the only hangup is getting correct numbers at startup, right?
Also - you're basically getting some sinusoidally varying current data, right? If so, how are you dealing with them for the FOC? Perhaps a similar thing could be done to use the more predicable data ( less noise, amplitude variation) coming from a resolver?

Thanks again for the e-mail; I'll pour over it tonight and see if I can understand it.

- E*clipse

[MPaulHolmes]

I get i_alpha and i_beta (the result of the clarke transform. step 1 in the FOC algorithm), and those are used in the sensorless code for determining the back emf. But you need the derivative of them, which is extremely noisy. well, not anymore it isn't haha. took care of it! boomshakalaka! Also I quieted down (and corrected for filtering) valpha and vbeta (results of inverse park transform) and ialpha and ibeta. I think the process for finding the back emf is almost identical in the permanent magnet case. There will just be a few differences relating to the rotor flux angle to mechanical angle. that step is super easy for the permanent magnet motor. Well, super easier. well, more doable. haha.

[thingstodo]

Update for Sep 23

The rpm indication does not seem to depend on how many poles the motor is set for ... but I need to check this again. It seems strange. Perhaps I can get that done tonight.

I ran the siemens motor with the keyboard (2 to speed, up, 1 to slow down) wih 4 pairs of poles and the control was a bit sluggish. I tried 3 pairs of poles and the control was better. The control was best with 2 pairs of poles. One 2-pair trial worked up to 3000-3200 rpm. The next 2-pair trial worked OK to 4000 rpm.

I put the encoder signal on my scope and the scope leads picked up so much noise I could not trigger properly on the encoder pulses. If this were the signal that the controller saw I would not expect the controller to recognize this signal as an encoder. So I was not able to make the encoder signal worse by running across the motor, then better by using foil. I could not get the signal good enough to recognize it on the scope ... so much for that experiment!

And I ran into the 12V battery problem again. The controller stopped run-rotor-test prematurely ... 3 times ... before I recognized the symptoms as a low 12V battery and put the charger on. I guess some of us need to learn the SAME THINGS OVER AND OVER AND OVER!!

Logs attached as a zip - but I'm not sure how useful they will be. I tried to press a<enter> every 5 seconds to get a feeling for what was going on. Paul - Is it possible that the offsets may not work well for pole-pairs over 2? Just a thought, if the extra data over-writes within your larger array.