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

[thingstodo]

Originally Posted by e*clipse

You know, the OBDII type data stream would be really nice. Would it be possible to use the OBDII protocol? Maybe even use some of the voltage, temperature, etc sensors - it's all worked out and an industry standard. It seems working with the standard might actually save some effort vs inventing a new protocol.

FWIW - OBDII is a request-response superset of CANbus that uses PIDs to identify which information you would like to receive.

Devices like SCANGAUGE II allow for standard PIDs to be polled as well as a few vendor-specific PIDs.

CANBus is a peer-to-peer protocol that has it's priority based on the address of the sender, 8 bytes max data payload for a standard message, and the receiver must use a mask to filter out what codes it wants to receive and interpret. The receiver must already know the format of the data and do things like scaling, putting 2 8bit bytes together to make a 16 bit word, etc.

AC Controllers from some vendors can be controlled via CANbus messages, or at least partly from those messages.

EVTV has an arduino shield that uses a high-throughput CANbus controller - it's open source. Someone (not likely me .. ) could start with it or use it as-is.

It would be *AWESOME* to do stream data with CANbus. The software to interpret the data and put in on a tablet is not trivial ... but would be a good place for a 'skins' type overlay to make the data look any way you want it to ... IMHO

[e*clipse]

Hmmm; since we were dreaming...

I definitely DON'T want to load Paul up with a whole bunch of extra stuff.

Also, my request would be to KISS as much as possible. Personally, I would only want to view data, not control the motor. I think controlling the motor through a serial bus opens up serious security issues, which the auto industry is just discovering.

So, would it be possible to make this an add-on shell to the core motor controller? (I'm just thinking aloud here) This shell would know where to look in the core motor controller for parameters and translate them to the protocol needed for the CAN bus.

If these parameters were translated in such a way that OBDII readers like the scanguage or EVTV's device could use them, then making a device to look at this data would be easy - already done!

Perhaps, in the spirit of open source stuff, this function/part could be done by another group? Again, if it just reads data, it won't matter too much if it's done at the same time and there's little danger of the translator messing up the core function.

[thingstodo]

Originally Posted by thingstodo

I don't have the encoder mounted on this setup, just yet.

I guess that's my next task. The plastic mount I had made for the motor shaft to encoder will work ... but I need to fab up a bit of a mount to take the weight of the encoder and some way of shimming things so that they are basically level/aligned.

After the run-rotor-test ... what do I do with the results? I'm sure that there a command to set the rotor constant, but I don't think I have seen it as yet.

BTW - is there a way to list the present settings? If I had done that, I would have caught the typo on k 3884 instead of p 3884.

Sorry I did not respond last night. I was trying to edit video .. load drivers for obsolete phones .. trying to zoom a window of gopro video ... not a successful evening!

A bit of confusion, and some frustration:
- run-pi-test runs for 45 - 50 seconds, then outputs all values from 62 up to 19964

- pi-ratio 62
- run-pi-test - same results

- p 3844
- i 62
- run-rotor-test

no rotation. Nothing appears to happen.

Cycle power, go through a few trials ... and decide to take a video asking you guys to show me the dumb thing I'm doing wrong.

Start the cideo by going through the setup.
- High voltage pack - 125.5V
- Low voltage battery - 13.1V
- Throttle - 4.90V - a bit high perhaps


Adjust throttle to 2.48V
Power up
Record run-through

pi-ration 62
run-pi-test - it works
output is one number - 05704
i divides out to 92

p 5704
i 92
run-rotor-test

it takes a few minutes to rotate, then puts out 0's as the speeds.

So I got back to where I left of yesterday (but I know now that I should check the throttle position before starting any testing!!)

So I need to make a mount for my encoder.

I began the process, but it took longer than the evening that was left.

Video will be posted, if and when I get some time ...

[MPaulHolmes]

I am just now finished with the config (or settings) command to show all the settings, along with raw throttle. And "bad command or file name. PC load letter" for when you make a mistake. sending hex file now!

That's very strange about the throttle. I probably should add a feature where the throttle is disabled and ignored while the pi and rotor tests are happening.

[MPaulHolmes]

I'm making pole-pairs another variable you can set. I forgot about that. So, if the motor nameplate says 3600 rpm (or a little less) from a 60Hz power supply, it would be 1 pole pair.
1800rpm (or a little less) would be 2 pole pairs. That could be affecting your motor's behavior when it tries to spin. I had it set to 2 pole pairs by default.

[thingstodo]

Originally Posted by MPaulHolmes

I am just now finished with the config (or settings) command to show all the settings, along with raw throttle. And "bad command or file name. PC load letter" for when you make a mistake. sending hex file now!

That's very strange about the throttle. I probably should add a feature where the throttle is disabled and ignored while the pi and rotor tests are happening.

'PC Load Letter' ... I *LIKE* it ... the controller should be an appliance like a printer but I *HOPE* the error messages will lead you to the problems directly. I dislike printer messages like 'buffer overflow, Press RESET to continue' and 'scan error'

I got the first version of my encoder mount done last night. When I get home tonight I will download the firmware to the controller, set P and I, then run-rotor-test. How long does that take to run? I need to make room on my phone to take the video ...

I will have my hand on the high-voltage cutoff in case the speed goes too high or my coupler alignment causes issues.

I'm not sure how many pole pairs there are on the motor. It's not on the motor nameplate? Perhaps I will measure the frequency output of the motor and use an rpm counter to check.

This is the link to EVTV where the motor was purchased EVTV Motor Verks Store: 1 Siemens 1PV5135-4WS14 AC Induction Motor, Motors and Controllers, 1PV5135

Looking through the specs - they list a rotor inertia of 0.068 kg/m2 ... if that helps to somehow determine if my rotor test values make sense?

[thingstodo]

Originally Posted by MPaulHolmes

I'm making pole-pairs another variable you can set. I forgot about that. So, if the motor nameplate says 3600 rpm (or a little less) from a 60Hz power supply, it would be 1 pole pair.
1800rpm (or a little less) would be 2 pole pairs. That could be affecting your motor's behavior when it tries to spin. I had it set to 2 pole pairs by default.

It's a german motor so I would expect the numbers to be based on 50 Hz. Motor is rated to 9700 rpm, so would it be 165 Hz for a 2 pole motor, 330 Hz for a 4 pole motor, or just under 500 Hz for a 6 pole motor?

[thingstodo]

Originally Posted by e*clipse

I definitely DON'T want to load Paul up with a whole bunch of extra stuff.

Agreed!

So, would it be possible to make this an add-on shell to the core motor controller? (I'm just thinking aloud here) This shell would know where to look in the core motor controller for parameters and translate them to the protocol needed for the CAN bus.

If these parameters were translated in such a way that OBDII readers like the scanguage or EVTV's device could use them, then making a device to look at this data would be easy - already done!

Perhaps, in the spirit of open source stuff, this function/part could be done by another group? Again, if it just reads data, it won't matter too much if it's done at the same time and there's little danger of the translator messing up the core function.

If the serial stream was done similar to the Cougar controller, it would be quite straight forward to read that serial data with a separate controller and stream it out on CANbus. I have not seen a library for OBDII codes .. but I have not looked for one as yet. Since it would be a separate controller, adding a bluetooth interface would not burden the controller, either.

To disallow CANbus control may limit functionality. There are a *LOT* of CANbus enabled things on a modern car.

It may make sense to keep the AC controller clean and use an add-on controller with a hard-wired interface to the AC controller ... to deal with the dual-element hall effect throttle, inertia switch/collision detection/air bag deployment, driving the reverse lights, interfacing to the brake pressure transducer (for regen braking), interlocks for forward/reverse switching (ie pressing the brake and having the speed drop below 2 mph), and the hundred other things that would be nice but may cause the AC controller to get distracted from running the AC motor?

[MPaulHolmes]

I like the idea of a separate controller for the 100 other things.

Hey! We can just try the FOC code with pole pairs = 1 and pole pairs = 2 and see what works. haha. My guess is it won't work with the wrong number of pole pairs, or it will work horribly worse. That's now a programmable variable. I'll send a new hex file a little later.

By the way: sensorless coming soon... The actual formulas for it are pretty simple. But I don't know how it will behave at low RPM. TI has theirs work down to 1Hz. Maybe a tiny bit of jitter at near zero rpm would be hidden by a 3000 pound car? TI calls their instaspin. I was thinking of "instarotate" or something. haha. Actually, that may be too close to their TM/circleR name, so, how about instagram? Or instant quaker oatmeal? I think both of those names are unused, and don't belong to any company.

[thingstodo]

Originally Posted by MPaulHolmes

Hey! We can just try the FOC code with pole pairs = 1 and pole pairs = 2 and see what works. haha. My guess is it won't work with the wrong number of pole pairs, or it will work horribly worse. That's now a programmable variable. I'll send a new hex file a little later.

If the new hex file gets here, I'll use the new one. If not, I can test out run-rotor-test with the version I have now. I would guess 4 poles (2 pr) to start with anyway.

By the way: sensorless coming soon... The actual formulas for it are pretty simple.

Great news! Sensorless opens up a BUNCH more opportunities. Encoder signals have noise issues. Much MORE issue if the encoder cables and the motor leads run in parallel ... like from the front of the car to the back ... No surprise there! We are really looking for torque control, not fine speed control.

But I don't know how it will behave at low RPM.

The industrial controllers we deal with, even when they *SAY* it's sensorless vector ... still use boost settings and volts/Hz for the first 2 - 6 Hz. It depends on when their algorithmn can measure speed and rotor position from Back EMF.

TI has theirs work down to 1Hz. Maybe a tiny bit of jitter at near zero rpm would be hidden by a 3000 pound car?

1 Hz sounds like a new feature or algorithmn. I agree that the car will 'smooth out' the jitter