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

[thingstodo]

Originally Posted by MPaulHolmes

Thingstodo, I think it's an excellent idea to get versions going here. Let's set the version you are using right now as the official "VERSION 0.1".

I've attached the version that I am running, which is listed as 1.0. I can change it to version 0.1 ... but I'm using a different compiler than you are .. since we could not get the old compiler running with my laptop when I was at your place.

Rather than post a hex file that has not been tested .. using a newer compiler ... well - I'm a paranoid , I'm posting this one.

Let's pick thingstodo's testing files as the official starting point, and then branch from there.

I'm posting them as tested.

Should we do a single project that's ONLY for induction, and one that's only for permanent magnet? I'm inclined toward that. At first it seemed no big deal to do all of them in a single file, but right now I'm finding that there are significant differences between induction+encoder, permanent magnet+encoder, permanent magnet + resolver type 1, permanent magnet + resolver type 2, permanent magnet + resolverEncoderHybrid (the Yasa motor uses this strange thing), ... I have 5 test motors, and all 5 of them are fundamentally different in their position sensing and/or motor type.

One version per motor type makes sense to me. If the code can be consistent in naming, include files, libraries, etc it will still be a chore to put them all together in one package later ... but as simple as possible is always good.

Originally Posted by wehzeh

If you want to start separating them, then github would be the bets bet actually. Just start a project for induction and fork for brushless.

Github it is!

[wehzeh]

Another suggestion for organization:

We could keep a single common codebase and use CMake to single out what needs to be compiled form what build.

EDIT:

Is the 1.0 (which I'm committing as 0.1) you posted just for induction or does it have all the other types too?

[thingstodo]

Originally Posted by wehzeh

Another suggestion for organization:

We could keep a single common codebase and use CMake to single out what needs to be compiled form what build.

I don't know what CMake is. Is it a pre-processor?

I'll mention simple again. When you are starting up a project it is important to get *SOMETHING* running quite quickly.

That said, I'm willing to try CMake. I'm looking forward to the Github repo.

EDIT:

Is the 1.0 (which I'm committing as 0.1) you posted just for induction or does it have all the other types too?

The version posted has code for everything, but has only been tested with one induction motor.

[wehzeh]

"CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice."

I used it when building a cross-platform game engine. I had identical source files for like 3 different targets, I just had to mark certain sections as target specific and CMake would skip or include them depending on what I was compiling for.

but GitHub is easier. I'll get on it tonight when I get home from work.

EDIT:
does anybody have a flow chart or something for code execution flow? also schematics etc., I would like to keep those on GitHub as well.

[thingstodo]

Originally Posted by wehzeh

but GitHub is easier. I'll get on it tonight when I get home from work.

Great!

EDIT:
does anybody have a flow chart or something for code execution flow? also schematics etc., I would like to keep those on GitHub as well.

I have not seen a flow chart. I haven't done one myself for years and years. I would offer to create one .. but I won't be very productive for the next month. I have a schematic file somewhere ... I'll look for it tonight

[wehzeh]

thanks in advance for the schematics.

https://github.com/seedrick/Open-ReVolt-AC

files are up, i'll update the repo as I get more info. I'll fill the docs out as I read and understand the code more, or if anybody wants to pull and add some changes, I can commit them to the repo.

EDIT:

are the files linked on the wiki for this project up to date?

https://drive.google.com/folderview?...FE&usp=sharing

if so, I can add those to the repo as well.

[MPaulHolmes]

I have version 1.1 ready now. (or 0.2 haha). I've been testing and editing things the last few days. It has induction, Nissan Leaf permanent magnet using resolver, Toyota MGR permanent magnet using resolver, and "generic permanent magnet" with generic encoder on shaft. I improved the PI loop tuning test so it's successful with a larger range of motors now. The problem was, with some really big motors, in the PI loop test, if you command a current step, properly chosen P and I constants will give convergence in close to 1millisec. So, I had been forcing successful PI loop tuning tests to converge in 2mS for all motors. But yesterday I hooked up a 1.5HP permanent magnet motor, and it required 15ms for convergence. So the test always failed with that motor. Now, I have it run through the possible PI values, allowing 2mS, and if it all fails, then all PI values allowing 4mS, and then 6mS, ... It also halts tests sooner if any oscillation is observed, since oscillation indicates the PI values are too big anyway.

There's also been quite a big of reorganizing by wrapping some things in functions.

I'm very very grateful wehzeh for you getting thingstodo's code up there. His has been tested the most extensively. I've tested the "0.2" code, but not as thoroughly as he has. Maybe I should verify that it all works on the leaf and toyota MGR motor before it gets added to a branch or however the heck that works. The 0.2 code also has some things for debugging built in, which isn't necessarily for public use, but I guess it's not so terrible to have it out there.

[wehzeh]

We can toss the new files up whenever in a new branch. the 0.1 will still be the "official" until we actually commit the new branch and make the new release the "official" version. That's why Git is cool: we can muck around with the branch all we want and put in all the iterative changes as they happen without ruining the solid code base.

Let's make sure not to forget the other documents either! Schematics, BOMs etc. can all be on there too, Git doesn't just handle code! It would also help if we could get some general system architecture explanations in the READMEs.

Lastly, I can also set up a repo for the different DC projects, I'll start hitting up those threads too. Open ReVolt is way too cool for the outdated wiki it has! I had seen the wiki before but t gave me the wrong impression of how mature the project was.

[freebeard]

This is all very cool.

[wehzeh]

I love the concept, once I get these things organized, I'm cranking out an EV a year probably. You guys literally did all the work I was ramping up to do plus some! This is a great platform, I have a few ideas to make it crazy good, but let's work on getting our sh*t together first haha

EDIT:
What micro is the code I put on the repo for? I'm looking at the dsPIC30F2010 datasheet and the I/O makes no sense. PORTB is supposed to have 5 pins but I see 8 assignments in the code?