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

[thingstodo]

Originally Posted by e*clipse

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.

If you were to modulate the two phases that are not connected to the bridge, I think that you would generate torque (with a Delta motor). Would it make sense to determine the position of the motor and modulate to avoid rotation of the motor (even the little bit of 'slop' in the mechanical linkage, before the car moves)? I think I would rather have the transmission disengaged for this one! Maybe you could alternate between positive and negative rotation and have the motor 'wiggle' a bit ... not perfect!

With a Y connected motor I think it would be harder to prevent rotation. You'd have to turn on both phases, time proportional to the existing motor position, to create torque in both directions .. to cancel each other out .. .. I don't even like it while I'm typing!

[thingstodo]

Originally Posted by e*clipse

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.

Cool.

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

I get a warning when I program with the PICkit 3 - the hex file loads with no errors, but when I verify there is a mismatch at some address. I'll check when I get home.

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?

2.86V on a board that uses 5V sounds like a problem - it's too close to 2.5V and not close enough to 3.3V.

I did not go through the PICkit 3 documentation. When I plugged it in, it worked, so the manual sits unread.

Here's the manual http://ww1.microchip.com/downloads/e...Doc/51795B.pdf

Page 20 shows a typical connection. It looks like a 4K7 to 10K0 resistor is typical - no capacitor.

[e*clipse]

Originally Posted by thingstodo

Cool.



I get a warning when I program with the PICkit 3 - the hex file loads with no errors, but when I verify there is a mismatch at some address. I'll check when I get home.

Thanks a bunch - I remember you were having connectivity problems; hopefully we can all learn from this.

2.86V on a board that uses 5V sounds like a problem - it's too close to 2.5V and not close enough to 3.3V.

Yes, that does seem weird, like it's pulled down or something. The supply pins (21, 40) measure about 5V. I think the MCLR pin was 5V when not plugged into the debugger. I'll double check that.

I did not go through the PICkit 3 documentation. When I plugged it in, it worked, so the manual sits unread.

Here's the manual http://ww1.microchip.com/downloads/e...Doc/51795B.pdf

Page 20 shows a typical connection. It looks like a 4K7 to 10K0 resistor is typical - no capacitor.

Yes - and on page 21 they explicitly say NOT to have a capacitor from MCLR to ground. Does your board have one? I guess it would be pretty easy to remove it.

Thanks again for your help and suggestions!
- E*clipse

[e*clipse]

Originally Posted by thingstodo

If you were to modulate the two phases that are not connected to the bridge, I think that you would generate torque (with a Delta motor). Would it make sense to determine the position of the motor and modulate to avoid rotation of the motor (even the little bit of 'slop' in the mechanical linkage, before the car moves)? I think I would rather have the transmission disengaged for this one! Maybe you could alternate between positive and negative rotation and have the motor 'wiggle' a bit ... not perfect!

With a Y connected motor I think it would be harder to prevent rotation. You'd have to turn on both phases, time proportional to the existing motor position, to create torque in both directions .. to cancel each other out .. .. I don't even like it while I'm typing!

Yes, the Y connected motor is what I'm talking about. I see little point to rewinding a motor so you could save the cost/weight of a charger inductor. And yes, it would be a high tech balancing act. There would have to be all sorts of safeties built in so the car wouldn't jump around while charging... However, with FOC, we are talking about very precise magnetic field orientation, so it may be possible.

[MPaulHolmes]

Wow! I think they changed their documentation, because they used to say to include a cap on mclr. I'll remove it. Or at least they say to on some of the datasheets for the specific dspic microcontrollers.

edit: it's not the dspic30f4011 datasheet. Maybe I need to lay off the crack.

danibjor: Yes! It's a 90MHz microcontroller with the sensorless code in ROM since they use some sort of new method that they don't want anyone knowing about. They don't use the back emf.

[MPaulHolmes]

Originally Posted by e*clipse

However, with FOC, we are talking about very precise magnetic field orientation, so it may be possible.

Yes, with both an induction motor and permanent magnet motor, as long as you are commanding Id to be something nonzero and commanding Iq to be zero, the motor will never turn. It would just be energizing the field with no torque component.

[MPaulHolmes]

The sensorless is working, but now I'm fine tuning it so it works as good as possible. Also it was getting really oscillatory after a certain RPM, and I forgot that I was doing the field weakening, which clamps Vd and Vq (field voltage and torque voltage). I think those sudden discontinuous updates of Valpha and Vbeta's magnitude mess with the sensorless algorithm. It still works, but does a crappier job. It's like if the real speed is 1000, before field weakening, it might be 1000 +/- 25, and after field weakening it is 1000 +/-200. But it is consistently above AND below. So the average speed is right.

[e*clipse]

Originally Posted by MPaulHolmes

Wow! I think they changed their documentation, because they used to say to include a cap on mclr. I'll remove it. Or at least they say to on some of the datasheets for the specific dspic microcontrollers.

edit: it's not the dspic30f4011 datasheet. Maybe I need to lay off the crack.

danibjor: Yes! It's a 90MHz microcontroller with the sensorless code in ROM since they use some sort of new method that they don't want anyone knowing about. They don't use the back emf.

Thanks for tracking that down - I'll remove it and see how things work out. Maybe the PICKIT3's are more robust than the older ICD 2's. Or maybe they're slower and they work with the capacitor there anyway...

Regarding the TI controller vs this project in general - one of the things I LOVE about open source is that everything is open. I really prefer the ability to fix something vs dealing w/ built-in features that may or may not work. So, there may be some rough edges here and there, but generally things have ( I think ) a better possibility of working well. If not, it's fixable.

- E*clipse

[e*clipse]

I'll start with an Edison quote: (sort of)

"Progress?? We're making tons of progress - we've found lots of stuff that doesn't work!"

Anyway, I removed the capacitor.
I measured the voltage of the 4011's supply pins: 4.96V
I measured the voltage of the MCLR pin without the debugger: 4.96V
I then connected the debugger, which was plugged into a powered up ICD2: 2.81V hmmm.

When I connected MPLAB to the debugger, I got the error message:
ICDWarn0020: "invalid target device (expected 0x101 read 0x0)

I also tried to program it anyway; no love. Same errors as last night.
Right now I'm double checking that I didn't do something like wire the adapter backwards or plug it in backwards...
I really hope it won't break something if the debugger's plugged in backwards..
- E*clipse

[danibjor]

I totally agree on the open source part. I'm all pro OS and have both used and contributed on OS projects.

Anyhow, TI have a video where they talk about the implementation, and for me whos new to flux, back emf and such - by watching this, i got a good understanding in how they think and how their algorithms work, without knowing about the code.

https://www.youtube.com/watch?v=szgVUfyX8JM

Could be I'm way of, but they got some clever thinking going on there..