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

[thingstodo]

Originally Posted by e*clipse

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!

I still have a vague, uneasy feeling .

I think it's perhaps a bit paranoid ... since ALL of the controllers that are built or purchased can be modified by their owners. That's one of the main POINTS after all.

I guess any help is a GOOD thing! I think I'll stick to testing .. I have some difficulty following the math ...

Whatever Paul needs to help make progress is fine with me

[thingstodo]

Originally Posted by e*clipse

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.

That sounds pretty great!

[thingstodo]

Originally Posted by e*clipse

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

Organization is my WEAKEST area.

I am happy to follow along and help with anything I can.

[thingstodo]

Originally Posted by danibjor

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

I have found this to be true when supporting multiple copies of identical code in different but similar deployments.

But this is a bit different, I think. Perhaps I was being too closed-minded .. doing things "like I've always done" ... becoming one of THOSE guys

[MPaulHolmes]

As for sensorless, I'm fairly sure, based on what I've tried, that getting it to work is like balancing a ball on the top of a hill. I think that if you don't have the motor's stator resistance and inductance fully characterized over the range of RPM and temperature and load, you will still get a "rotor flux angle", but it will slowly drift away from the true angle, and after a short time you won't be commanding current in the right direction. TI is doing 20kHz 12 bit precision A/D conversions on all of the 3 motor currents AND all 3 motor voltages, AND constantly checking the stator resistance while the motor is running, and knows the stator inductance at every rpm in order for it to be used in a test vehicle (a bus. maybe there are others now).

I think that with the hardware I'm using, I could fully characterize stator resistance and inductance, and then get it to ramp up relatively slowly, and maintain a relatively constant RPM, but I have my doubts about using it in a car. I think you have to be hyper-vigilant, babysitting the motor's constants on a moment by moment basis to get it to work under the conditions of normal daily driving. That's a very different application from a sensorless AC motor in industry. I think that to give this the best chance it could have I would have to change the control board hardware. I still would like to get it to work, but maybe we should stick with encoder/resolver approaches for cars for now.

A guy in india wants to use the controller for some rickshaws, and I have to get a board he ordered shipped out to him in just a few days, so for the next few days I'm going to just try to get it to a place that will autotune and be ready to run as easily as possible. I had been hoping to get the sensorless working before that deadline, but it's not going to happen in 3 days.

thingstodo: How hard will it be to get the 64 ticks/rev encoder working? I think sensored load tests are probably the best way to go for the ACIM for the moment.

I really want to get eclipse's motor/resolver board tested and working too.

If a hall sensor was added to the motor post cheaply, a single pulse per revolution should be enough for sensorless to work. You could do a hybrid of sensorless and sensored FOC. I should try that. I think you just epoxy a small magnet to the shaft, and add a hall sensor or 2 as a cheap "encoder".

[thingstodo]

Originally Posted by MPaulHolmes

As for sensorless, I'm fairly sure, based on what I've tried, that getting it to work is like balancing a ball on the top of a hill. I think that if you don't have the motor's stator resistance and inductance fully characterized over the range of RPM and temperature and load, you will still get a "rotor flux angle", but it will slowly drift away from the true angle, and after a short time you won't be commanding current in the right direction. TI is doing 20kHz 12 bit precision A/D conversions on all of the 3 motor currents AND all 3 motor voltages, AND constantly checking the stator resistance while the motor is running, and knows the stator inductance at every rpm in order for it to be used in a test vehicle (a bus. maybe there are others now).

That sounds like reliability could be an issue. TI still has this in product shakedown, right? The bus is proving that the system works in the 'real' world?

I think that with the hardware I'm using, I could fully characterize stator resistance and inductance, and then get it to ramp up relatively slowly, and maintain a relatively constant RPM, but I have my doubts about using it in a car. I think you have to be hyper-vigilant, babysitting the motor's constants on a moment by moment basis to get it to work under the conditions of normal daily driving. That's a very different application from a sensorless AC motor in industry. I think that to give this the best chance it could have I would have to change the control board hardware. I still would like to get it to work, but maybe we should stick with encoder/resolver approaches for cars for now.

Agreed. In our industry, it's the initial acceleration that is important ... and all is good if the controller can command enough torque to do what the control system is asking for. Once the load is up to speed and there are minor changes, or even major changes, you are looking for reproducibility. Maximum acceleration or deceleration is hard on the process.

A guy in india wants to use the controller for some rickshaws, and I have to get a board he ordered shipped out to him in just a few days, so for the next few days I'm going to just try to get it to a place that will autotune and be ready to run as easily as possible. I had been hoping to get the sensorless working before that deadline, but it's not going to happen in 3 days.

Cool - a first 'production' sale?

thingstodo: How hard will it be to get the 64 ticks/rev encoder working?

Not hard, I hope. It will likely take more time than I think .. but that's normal.

I think sensored load tests are probably the best way to go for the ACIM for the moment.

OK with me.

If a hall sensor was added to the motor post cheaply, a single pulse per revolution should be enough for sensorless to work. You could do a hybrid of sensorless and sensored FOC. I should try that. I think you just epoxy a small magnet to the shaft, and add a hall sensor or 2 as a cheap "encoder".

I have a tachometer target and sensor for the DC motor. When the AC and DC are coupled, I should have a pulse train .. not sure if it will be 2 pulses per rev, or 4, or some other number. I should be able to get that working (EVTV purchase for my car) but it likely operates at 12V. I'll start with 5V in case the operating range is wide ... and I need to get it operating anyway for my car so I may as well do it now.

[e*clipse]

It sounds to me like one of those perfect is the enemy of the good situations.
I've seen things like this with regard to development and compromise:
The 90% solution costs $X + time
The 95% solution costs 2*$X + 2*time
The 98% solution costs 2*2*$X + 2*2*time
and so on...

Most of the time, motors intended for EV use have some form of position feedback. I think that it would be a good place to start. - Use the one on thingstodo's motor.. In addition, if a single speed gearbox is used, the vehicle speed can be directly derived from the motor's position feedback. That saves a sensor down the line.

The cheapest easiest solution I've always seen in app notes is the one using 3 hall-effect sensors. I think that if 1 sensor could be installed, then it wouldn't be that much more difficult to install 3 and have the option of 3 hall-effect sensor code.

Here is where having the code split up for different types of position feedback would give an excellent opportunity for both the final user and software/hardware development.

The sensorless code Paul is working on could also be very useful for "filling the gaps" of information when less accurate encoders or hall-effect sensors are used.

It seems Paul has a very full plate right now. For my bit, I'm going to attempt splitting up the sensorless.c code into functions. I will use all the original variables, comments, programming style, etc. Paul - if this seems helpful, let me know. Also - if you have suggestions, please let me know.

E*clipse

[thingstodo]

Originally Posted by e*clipse

The cheapest easiest solution I've always seen in app notes is the one using 3 hall-effect sensors. I think that if 1 sensor could be installed, then it wouldn't be that much more difficult to install 3 and have the option of 3 hall-effect sensor code.

For the cheap and easy solution, are the targets glued to the motor shaft? Is there a machined or perhaps an off-the-shelf ring slid over the shaft that has 3 or more targets? It would seem easier to keep a ring balanced than to glue targets perfectly on a round shaft ...

[thingstodo]

I haven't put much time into mounting the motors lately. There is a bunch of stuff to do around home before freeze-up.

I should have some time this weekend - target of having the motors mounted to a larger and heavier base, plus wire the 64 ppr motor encoder to the AC controller.

A bit of progress on getting the DC controller operational posted in the Cougar list.

[e*clipse]

[QUOTE=thingstodo;495883]For the cheap and easy solution, are the targets glued to the motor shaft? Is there a machined or perhaps an off-the-shelf ring slid over the shaft that has 3 or more targets? It would seem easier to keep a ring balanced than to glue targets perfectly on a round shaft ...[/QUOTE

In some ways my perspective may be clouded by my shop. You're right - gluing magnets around a shaft would probably not work.

Do you have any access to a lathe, maybe through work?
If you did have a ring with magnets, do you have access to the shaft?

I'm just thinking aloud; I think it would be a reasonable thing to make. I have made a quadrature encoder wheel for a test. However, it's probably much easier to get the encoder working on your existing motor.

- E*clipse