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

[e*clipse]

Yea!

I got my PICkit3 and it talks to my MPLABv8.92 on my not-so-ancient cumpooter!

Now to see about that blinky light...

- E*clipse

[e*clipse]

Yea!

I have a blinky light!!!

Now we can take over the woRLD! BWAH HAA HAA!!

btw,

I downloaded the MPLAB C30 compiler v3.31 to work with the MPLABv 8.92 I'm running.
Right now it's running the "PRO" version as a demonstration. With the pro version, the code is supposedly a lot more optimized than the free version.

To be honest, I didn't notice any difference with my blinky light... should it be blinking faster??

But seriously, Paul - are you running any better compiler? Have you noticed better - or different - performance with the controller based on the C compiler?

- E*clipse

[MPaulHolmes]

I think I have the free version. I tend to do some of the optimization sort of things anyway though (unrolling loops, multiply shift instead of divide, inline functions instead of calling a function and returning) so I don't know how much it would improve.

[e*clipse]

Ok, now the blinky light is under control of the throttle.

So, I guess I have a good enough handle on things to do some useful work.

What do think about having a stripped-down "base" code that works with the current hardware. This idea came as I thought about stripping "sensorless.c" down to a "senseless.c" This is to assist my little noggin' in seeing the big picture.

This code would put out a sinusoidal PWM signal and measure current and throttle position. Perhaps other features, like contactor control, and other AtoD measurements could be built into this core.

It would be considered a solid foundation on which to build features like FOC and sensorless control. The base sinusoidal output would use a look-up sin table, with the frequency set in a volts/hz mode.

Hopefully I haven't suggested anything new here - it seems to be operating a little bit like this even under the newest sensorless code.

The new features, like sensorless control could be added as either code within the main or maybe sub-programs in a build.

This might facilitate programming different options, like sensorless code, encoder input, resolver input, FOC for asynchronous motors, FOC for synchronous motors, etc etc...

In fact, if things were done well, a "build" would just have the useful parts for that application. This might save computer time/memory.

Thoughts?

- E*clipse

[thingstodo]

Originally Posted by e*clipse

What do think about having a stripped-down "base" code that works with the current hardware. This idea came as I thought about stripping "sensorless.c" down to a "senseless.c" This is to assist my little noggin' in seeing the big picture.

The FOC control takes care of the voltage output given the requested torque. The signal into a V/Hz controller is, in my experience, a speed reference. The voltage is controlled by an output curve - linear with a starting boost, a curve that approximates a squared curve, a curve that approximates a cubic curve.

This might facilitate programming different options, like sensorless code, encoder input, resolver input, FOC for asynchronous motors, FOC for synchronous motors, etc etc...

There are advantages to having 'all' the code the same .. debugging, spare parts ... and there are advantages to 'only loading what you need' ... mostly to do with money and production costs, a simpler setup perhaps ...

The memory and MIPS are cheap. Without further information, I'd stick with 'one program does all'.

[e*clipse]

Originally Posted by thingstodo

The FOC control takes care of the voltage output given the requested torque. The signal into a V/Hz controller is, in my experience, a speed reference. The voltage is controlled by an output curve - linear with a starting boost, a curve that approximates a squared curve, a curve that approximates a cubic curve.



There are advantages to having 'all' the code the same .. debugging, spare parts ... and there are advantages to 'only loading what you need' ... mostly to do with money and production costs, a simpler setup perhaps ...

The memory and MIPS are cheap. Without further information, I'd stick with 'one program does all'.

I talking about a method of doing collaborative programming. Really, the details of the code don't matter from that perspective. Once the code is compiled, it is "all one code." The background of how that code came together is not available or important to the end user. The end user only loads one piece of ready to run software.

As an example, the previous version of "sensorless.c" had 48 pages of code. I printed out pages 16-37 to get an understanding of how this specific core control works. I have a pretty good understanding of how FOC works in general, and V/Hz as well. In that code, there were 11 pages specifically for dealing with asynchronous motor issues. A lot of that was comments (thanks Paul! ) , so it will be much more compact as compiled code.

Right now, Paul is working hard on getting sensorless algorithm working for an induction motor. That's great, but my interests are quite different - I have an excellent analog sensor on an synchronous motor. So, I was hoping I could contribute by doing a bit more than cheering from the sidelines. I mean, maybe Paul needs some "blinky light" code!

- E*clipse

[danibjor]

As for the microcontroller. The size of the file you upload does not matter (as long as it fits in the space you have).

If you have an IF statement around the asynchronous code - the code does not run on non-asynchronous motors, if you say have config params that define the motor type your are controlling.

Thus, code inside the IF(asynchronous-motor) statements, never run, and thus never use CPU cycles and resources. (other than a single clock-cycle to check motortype in the IF-statement and some minimal amount of ram to store the motor-parameters.

Having an all-in-one solution, like Paul is doing, is the most flexible for the end-user

Edit: got some toys today

[MPaulHolmes]

I have learned 1000 ways how not to make a light bulb. haha. Trying a couple more things out. I think my "filtering" idea and assuming that current and voltages and derivatives are perfect sine waves is sufficiently wrong as to make it not work stably.


With respect to code organization, Maybe we could have it both ways. The code does need to be broken up into separate files that are organized according to what they do, just to make things easier to follow. The "main" file is over 2000 lines long at the moment. Maybe there could be a file designated "encoder induction FOC" that has a bunch of functions. Then, another file that has "sensorless induction", and another file that is "encoder permanent magnet", and one that is "resolver permanent magnet", etc... or something to that affect, and you could link all the files if you want, or leave off a file or 2 if you want and it wouldn't affect compilation?

[danibjor]

Could be a good idea to break things up to make it easier to maintain.

Helper functions and such in apropriate files. Main in one and motor type spesific code in as many as it supports. Just include the correct header file for your motor type, and you are all set to go if you want to compile your own code.

[e*clipse]

Originally Posted by MPaulHolmes

I have learned 1000 ways how not to make a light bulb. haha. Trying a couple more things out. I think my "filtering" idea and assuming that current and voltages and derivatives are perfect sine waves is sufficiently wrong as to make it not work stably.

With respect to code organization, Maybe we could have it both ways. The code does need to be broken up into separate files that are organized according to what they do, just to make things easier to follow. The "main" file is over 2000 lines long at the moment. Maybe there could be a file designated "encoder induction FOC" that has a bunch of functions. Then, another file that has "sensorless induction", and another file that is "encoder permanent magnet", and one that is "resolver permanent magnet", etc... or something to that affect, and you could link all the files if you want, or leave off a file or 2 if you want and it wouldn't affect compilation?

Paul - exactly what I was trying to get at.

danibjor - back when I was first learning to program, (Attempting games like Astroids on a Commodore "CBM") I made code that, um, worked with all sorts of "If" and "goto" type statements that jumped all over the place. Fortunately, it was only me who used that code, and I could barely follow it after a while. Another way to make unreadable code is to rely completely on interrupts. That can even confuse the computer if you're not careful.

Also, we don't have all the MIPs we want. Paul is doing some amazing programming to reduce the amount of CPU cycles used in critical functions. This philosophy of respecting the limited resources is very wise, IMHO. This is where jumping around with multiple "IF" statements can squander criticle CPU cycles that were carefully saved in another part of the program.

The program does not have to be broken into different programs - that's just one way of accomplishing this. Another option would be to break the jobs into separate functions ( Like Paul is saying ). If you don't need to deal with slip because you're running a synchronous motor, the program can simply ignore the rotor flux speed and rotor flux angle functions. If you have an encoder and you need the rotor position, there's a function for that - different, but with similar output from the resolver position function.

If a person wants to add some custom capability to their code, it would be relatively do-able because it could be added as a function.

All that is really required is organizational: How variables are shared; what variables are used, timing priorities, etc.

- E*clipse