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

[e*clipse]

Paul - I have an old schematic too. I agree it would be possible to just change a few pin names to run the main program.

Here are a few differences I noticed about the new design ( Or maybe a mid-new design LOL! ) The new design I'm referring to has one control board with the drivers on that board. BTW, I think the new new design with seperate driver boards is awesome!

3 current inputs on new design vs 2 on old design
get rid of the "heartbeat" circuitry on new design
Also the new design has 4 open pins: 10, 15, 16, and 24
Moved the LED to pin 17

Anyway, NBD - all this can be adjusted for in code.

Do you have any code that just puts out a sin wave (like volts/hz mode with an adjustable frequency or fixed frequency with an adjustable PWM amount?

That would make debugging easy, rather than trying to track down overcurrent error logic etc.

Regarding the Prius throttle - you're right - it would be hard to test with, but I think it would make an excellent EV throttle. One thing about them (or hall-effect potentiometers) that might help your worn space problem is they seem to have a somewhat limited output between 0.5 (or so) volts and 4.5 (or so volts) If the output is in the 0.5 > 4.5V range, the controller knows things are functioning correctly. Otherwise, it could force a controlled shut-down.

The Prius pedal takes this one step further with parallel outputs that look like a hystresis curve. Here's some info, courtesy of EV West:
http://evwest.com/support/prius_pedal.pdf

If you had two throttle inputs, the controller could work with this.

- E*clipse

[e*clipse]

Originally Posted by MPaulHolmes

The FOC code is running through over 10,000RPM (2 pole pairs) in order to produce 5,000RPM of revolution. That may be too fast for the 10kHz control loop... I wonder if we should bump the A/D readings up to 20kHz, and do the IGBT switching still at 10kHz... That would mean needing to boost the microcontroller frequency from 14.7MHz up to 29MHz. That's no big deal. It's a 30MHz microcontroller. Fortunately you don't need to go over 10,000RPM mechanical! haha.

This is one of the reasons I'm interested in SiC switches. The motors I'm using can run up to about 12,000 or maybe 13,000 rpm. I'd like to make use of their capabilities like this.

It seems one would also want to increase the switching frequency to have good resolution at those speeds. Perhaps a motor speed adjustable switching frequency??

- E*clipse

[MPaulHolmes]

The nice thing about the dspics is you can change the switching freqency every stinking cycle and it doesn't mind one bit. The only concern I would have is the code would have to run a tiny bit slower, since I optimized a few things to 10KHz, so as to avoid doing a couple integer divisions, which take 17 clock cycles. But if I still have a lot of room at 14MHz. And then have tons of room at 28MHz.

[thingstodo]

Update for Sep 14

Took the DC and AC controllers off the mounting plate (separated Cougar controller), remove the mounting plate - was mounted over both motors

Move the AC controller (still connected to the AC motor)

Remove the motor supports (most of them)

Decouple the motors

Pack up for the night

- located some of the parts required to make a small circuit board out of the voltage divider network for the encoder

- it does not appear that the netgain warp 9 can reliably withstand a 10,000 rpm test. So I decoupled the DC motor and now need to get the encoder coupled to the motor directly .. after I figure out where to put the DC motor for a few days.

[thingstodo]

Originally Posted by e*clipse

This is one of the reasons I'm interested in SiC switches. The motors I'm using can run up to about 12,000 or maybe 13,000 rpm. I'd like to make use of their capabilities like this.

It seems one would also want to increase the switching frequency to have good resolution at those speeds. Perhaps a motor speed adjustable switching frequency??

The nice thing about the dspics is you can change the switching freqency every stinking cycle and it doesn't mind one bit. The only concern I would have is the code would have to run a tiny bit slower, since I optimized a few things to 10KHz, so as to avoid doing a couple integer divisions, which take 17 clock cycles. But if I still have a lot of room at 14MHz. And then have tons of room at 28MHz

Switching frequency discussion - just so I can follow along:
- a higher dsPIC frequency means more computation, better control
- higher dsPIC frequency may mean higher A/D frequency to keep the control algorithmn fed with good data

- a higher switching frequency means higher losses, but better control, maybe need SiC transistors?
- lower switching frequency means lower losses, maybe a lower max speed?

10,000 rpm on a 50 Hz, 1500 rpm motor (2 pairs of poles, like the Siemens) would be running at 330 Hz or so. 10 Khz A/D would be 600,000 samples per minute, 60 samples per revolution, right?

Is there an issue with only 60 samples, or perhaps that MAY not be enough samples?

I think that the loop may already be too fast. If the acceleration I saw with the motor 'hunting' during the rotor test is typical - 30+ amps on one meter update (about 1 sec) and -something on the next meter update ... and the meter averages a bunch to get a relatively stable display number, I think that mechanical parts of the car would be very stressed. Acceleration from 0 speed to 2500 rpm can take 1 or 2 seconds if you are not racing. That's comparable to a performance engine, right?

[MPaulHolmes]

Is there an issue with only 60 samples, or perhaps that MAY not be enough samples?

Ya, I think you are right. 60 samples looks awful good on a graph. Even 20 samples for a cycle is a pretty good approximation to the sine wave, and that would be 30,000RPM. I think I spoke too soon before about needing to increase the frequency.

It's possible that bad rotor time constants were creating a terrible model of the motor, and it was totally messing up the spinning. I'm very interested in seeing how it works with the
1<cr>
2<cr>

It should give very fine control and since we will be using a rotor time constant that is accurate for the motor, and good PI values, it should be good to go. I'll be interested in seeing if any problems arise. IT's not a problem to slow the ramp rate down so it's not so crazy. Maybe because your motor is so powerful, I need to do a slower ramp rate than what I'm using. It's sort of hard to explain, but I'm doing IdRef, IqRef, and also IdREfRef and IqRefRef. IdRef and IqRef get clamped whenever the PI loop is overshooting a voltage disk, then they try to ramp back up to the RefRefs.. but I should make sure the ramp back isn't too aggressive.

[MPaulHolmes]

I think I may have found a way around the noise issue TI was talking about with one of the major steps for doing sensorless FOC:

Ea = Va - R * I - L * dI/dt

The trouble is, you have to compute dI/dt, but the current waveform is noisy in general. I found the graphs of some of I(t) by printing out the data while the motor was running, and gosh darn it, even down to zero RPM, they are sine waves, but jaggedy due to the noise! So, just figure out the period and magnitude, which are more noise immune (when does it cross x-axis, when does it reach a peak) and then don't do a numerical derivative (i - iOld) / 0.0001), but instead do cos(theta) = d(sin(theta)/dtheta so then your derivative is not noisy!

[thingstodo]

Originally Posted by MPaulHolmes

I think I may have found a way around the noise issue TI was talking about with one of the major steps for doing sensorless FOC:

Ea = Va - R * I - L * dI/dt

The trouble is, you have to compute dI/dt, but the current waveform is noisy in general. I found the graphs of some of I(t) by printing out the data while the motor was running, and gosh darn it, even down to zero RPM, they are sine waves, but jaggedy due to the noise! So, just figure out the period and magnitude, which are more noise immune (when does it cross x-axis, when does it reach a peak) and then don't do a numerical derivative (i - iOld) / 0.0001), but instead do cos(theta) = d(sin(theta)/dtheta so then your derivative is not noisy!

I have a story about a zero-crossing detector ... we had a line-to-line fault (short circuit) that caused all sorts of bad things with the breakers that were involved. That is expected.

The fault also caused our large AC Controllers (700 HP) in a different part of the mill to detect a change in utility line frequency (which was not correct). No big deal, right? That just causes a number on some display to be wrong. Not quite. The wrong calculated line frequency caused the controllers to change their firing sequence (converting 3 phase AC incoming to DC).

But the line frequency did NOT change, so the firing change turned on the transistors, not at 0V between phases, but at substantial voltage between phases .. and blew up the switching transistors on 4 controllers. This caused 18 hours of downtime while the controllers were fixed.

The company that sells the controllers is STILL (over 6 months later) trying to come up with a fix the does not break the controllers during every other condition.

I guess my point is that the noise can make it look like you have a period that is not correct. Perhaps it could be combined with a maximum rate-of-change, as a sanity check for the calculated period?

Or am I being too paranoid?

[MPaulHolmes]

Wow! Ya, I was thinking about false crossings. I'm trying to build in some special cases to deal with that. Like requiring a minimum period, knowing that the frequency can't go from 0 to 15000 instantly, correcting for frequency change every 1/4 cycle, etc... I think the messy details will be 95% of the work. The nice thing is we'll have the encoder where we can test the real speed and the sensorless speed, and try weird varying loads and stuff to see if we can trick it.

[thingstodo]

Originally Posted by thingstodo

I have a story about a zero-crossing detector

... snip ...

The company that sells the controllers is STILL (over 6 months later) trying to come up with a fix the does not break the controllers during every other condition.

Perhaps that came off a tad too cut-and-dried ..

This description is a theory - the company involved has NOT admitted that this is correct but is still 'investigating'. That may have something to do with admitting liable for lost production and the associated legal stuff?

The statement about the controllers detecting that the line frequency 'changed' is accurate - they admit to that part. And the fact is the controllers each blew up the same phase shortly after the frequency change. The rest is my explanation, fitting the facts into a theory.

But I'd bet a year's pay that our utility did not change their line frequency at the exact same time as we experienced a line-to-line fault at our site!