Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control - Page 269 - Fuel Economy, Hypermiling, EcoModding News and Forum

e*clipse · 03-22-2016, 06:56 PM

Thanks, Paul.

I've caught up to where you and Shaggy are; regarding debugging.

Can the controller work with no position feedback? Can it be forced into a v/hz mode? This would be helpful for debugging in general.

Also, I've read the sections about I/O pins and the QEI interface in both the FRM and the 6010 controller - neither mention the transition voltages for the pins, unless I missed something.

In general (from Wikipedia) the transition voltage for CMOS logic is 1/3Vdd for the low transition and 2/3Vdd for the high transition. In other words, Shaggy should see a transition in the QEI output when the pin voltage exceeds 3.333V ( his 3.8 V should be OK) I think it would be wise to increase that voltage, as Paul suggested. But it should work.

*** edit ***
Thanks for the info on the oscillator! :-)
*******

- E*clipse

MPaulHolmes · 03-22-2016, 07:01 PM

I haven't added the V/Hz code to this. It's all vectory and what not. haha. It actually does turn the motor with no position feedback, but I have no idea why. But it only turns the motor slowly. This has been checked in the case of induction. I'm not sure about permanent magnet. I think it's a good idea to have V/Hz and FOC modes. I just haven't done V/Hz on this one.

e*clipse · 03-22-2016, 07:23 PM

- Got the schematics - thanks!!

Regarding V/hz - we just need a rotating magnetic field. This should work slowly at no load for both synchronous and asynchronous motors. I mean your standard induction motor works with a magnetic field rotating at 60hz....

So, maybe a stupid test would be to let the throttle setting just directly change the speed - from 0 to maybe 60hz at the fastest.

Meanwhile, stuff like "is the position feedback working properly?" " Is the current sensor working properly" could be verified. Heck, it could also be used to figure out if a 4 pole or two pole motor was connected...

Maybe all this could be another "motor" - a separate include file.

If any of that rambling made any sense, let me know.... I'll try to include it w/ the translation.

Take care,

E*clipse

MPaulHolmes · 03-22-2016, 07:40 PM

i LIKE IT! Good idea with the "motor" abstraction.

e*clipse · 03-22-2016, 08:19 PM

Cool! I'll see what I can do. :-)

On the subject of the schematics...

boy, this is going to sound lame....

I just tried looking at the schematic and Design Spark won't let me because I've got an old version...

Their upgrade instructions said it if you are currently working on a design, and I am, it would be best not to upgrade in the middle of things....

Anyway, I'm in the middle of a BMS design that I don't want to loose.

Would it be possible to to zoom in to the pic you posted of the board in Photobucket?

**edit ** sorry I tried the photobucket idea; I can't see from the pcb well enough what's needed for coding...

Thanks...

- E*clipse

MPaulHolmes · 03-22-2016, 09:21 PM

Maybe in a few days I could get the pinouts entered into the software and email it to you. My job is sort of all encompassing right this second though.

e*clipse · 03-22-2016, 09:46 PM

Ok, this old phart will figure something else out... LOL!

The goal was to save you time.

So, unless you have something quick, like a screen grab or something, I'll figure out a way around this.

It sort of looks like Shaggy did a good job if scanning through the code and changing pieces. There still needs to be some debugging - which is normal. I mean he's changed many of the I/O pins; there's bound to be a reversed pin or reversed tris bit, etc. One little "1" instead of a "0" could cause all sorts of interesting stuff..

I'm trying to figure out how the code can be **sort of** processor independant, at least with the ones we're using. ( 4011, 6015, 6010A )

In that light, it seems like some small mods to how things are defined and initialized should do that. It may be possible to do something kind of smart like an "if this processor, call this header"

It also looks like there is some redundant code in the UART.c - I need to look into this closer...

- E*clipse

Thalass · 03-23-2016, 10:53 PM

e*clipse could you not install the newer version alongside the older version? Just make sure you don't get them mixed up when opening projects.

WindyDrew · 03-25-2016, 01:05 AM

ITS ALIVE!!!!!!!!!!! Just worked with Paul to get my controller turning my leaf motor. We're designing a circuit to allow a button to inverse the throttle for reverse on my race car. I need some help, Paul is busy with work so I was hoping someone could help me with the code. I want to signal high on the led pin (change the LED pin to Digital input pin) is forward in normal state and then signal low would invert the throttle. I'm sure there needs to be some safety built into the code as well. The wiring is planned out that we take +5v from supply side of R53 with a 4.7kOhm resistor to the left side of LED. R57 populated with 1kOhm resistor and a 0.1mF from the microprocessor side of R57 to the ground pin at the end of the microprocessor 2 pins to the right. LED left and right to the momentary switch. How does that sound to you guys? Can you give any thoughts to the safety details of this added code? Let me know

Thanks,
AC

thingstodo · 03-25-2016, 02:08 AM

Quote:

Originally Posted by WindyDrew

I want to signal high on the led pin (change the LED pin to Digital input pin) is forward in normal state and then signal low would invert the throttle.

Just to make sure I understand - the pin to be used is pulled high and will be grounded to engage the reverse switch. Right?

Forward is 'normal' so that a faulty switch does not reverse the car while driving down the interstate at 70 mph.

EVTV has described that the Tesla needs the brake engaged and the speed within a few rpm of 0 before you can change from Park to Drive, Drive to Reverse, Reverse to Park, etc.

Maybe 1 extra input for the brake? It would be tied high, Active low, grounded by the switch.

Quote:

I'm sure there needs to be some safety built into the code as well.

Yup - I think so.

Quote:

The wiring is planned out that we take +5v from supply side of R53 with a 4.7kOhm resistor to the left side of LED. R57 populated with 1kOhm resistor and a 0.1mF from the microprocessor side of R57 to the ground pin at the end of the microprocessor 2 pins to the right. LED left and right to the momentary switch. How does that sound to you guys?

One LED lit to show high (normal) and one to show low (reverse)?

Quote:

Can you give any thoughts to the safety details of this added code?

I have no experience with the code - I will need to look through it eventually. But I'm not much help right now.