Discrete transistors and AVR microcontroller

[DukerX]

I'm currently working on a project that uses one AVR Mega48 microcontroller to drive four MOSFET's using hardware PWM and hopefully no current sensing resistors.
This is for unipolar motors.

Basic concept:
I have hooked 4 PWM output lines to the gate pins on 4 IRFP250 transistors (not the best choice, but those are the only ones I have 4 of).
The AVR is running at 20MHz, and the PWMs are 8bits and no prescaler.
PWM frequency is 78.125kHz.
The PWM values are stored in EEPROM, and can be programmed throug a standard PC com-port to match each motor perfectly.
Utilizes the lo/hi current output in MACHn

What I have discovered:
The IRFP250 parts can handle >30 amps continiously, but due to the rather slow switch-on/off times they start to heat up at less then 1A
To solve this, I could get some faster transistors and / or slow down the PWM to maybe 20kHz.
In my silly attempt to do microstepping, I guessed that a SIN/COS function on the duty-cycle would be the right thing to do...
While a SIN/COS function on the current in the A/B coils would definetly be the ideal way to do microstepping, that doesnt mean that setting the PWM duty cycle to a SIN/COS function would be good, unless the motor have zero inductance, and the transistors have zero switching time...
I did some measurements on the PWM duty-cycle to current ratio, and have plotted the results for two of my motors in this grap:

To get the results as accurate as I could, I built a monster filter between the transistors and the power supply, and placed the ampere-meter between the filter and the PSU.
As you can see, the relation between motor current and duty cycle is far from linear... It's really very exponential... To the power of ...alot!
I also plotted this grap. showing the difference between the motors.

If this had been a more or less straight line, I could have done some fancy computations to compensate for the hugely nonlinear nature of the current/duty-cycle ratio, but as you can see, it's not very straight at all...
This makes microstepping really hard!
Still, I managed to do a fairly decent torque-compensated half step by just using two sliders in a windows program, that would set the PWM values "live" by feeding it to the processor throug a COM port.
One slider is for the max value, and the other are for the reduced value.
Extending on this idea, I think it would be possible, by using SIN/COS to calculate the apropriate current value for each microstep, and using more sliders to adjust the PWM values "live" until the desired current for that microstep is showing on the A-meter.
Not a very neat way, but I beleive it could work.
Almost the same as using current sensing, but it's a one-off for each motor, and never have to be done again unless some of the components are changed (Power-supply, motor or transistors).

[davesaudio]

IIRC- I don't believe an AVR can drive those fets hard enough

[DukerX]

The FET's I'm using are far from ideal, but that's not the point...

[Carel]

I have looked at the datasheet of the irfp250 and it has a low "on" resistance. You already encounter dissipation problems at 1 amp. This and the nonlinearity points to slow driving of the gates of the mosfets. For this mosfet you need a gate driver in the range of 12-15 volts, which can charge and discharge the gate fast enough to give a "digital" drive (Instant On, Instant Off, No ramping). Normally the PWM frequency is chosen at just above human hearing frequency (20Khz) to have the lowest dissipation problems. This mosfet should not heat up at 1 Amp.

Carel

[NC Cams]

We learned a LOT about mosfet switching when we were doing R/C car motor controllers. The findings apply here. Oh, and use of the proper fets IS part of the point as is a proper driver....

You MUST overcome the fet gate capacitance in order to turn it on. The FASTER and HARDER you can turn it on, the less internal resistance will exist ahd the less of a problem you'll have with heat generation. If you don't turn it on full (ala "ramping") you'll have heat. PERIOD.

We were initially using IRFZ40's in our speed control. They had low resistance and high current potenial YET we'd see tremendous heat build up. When we looked at the current curve while driving at what should have been a square wave, PWM'd drive, you could literally see that the wave WASN'T square - the fets were turning on slow.

Result was that the turn on wasn't complete and during the inrush phase of current flow, resistance was high which resulted in the over heating effect.

Via experimentation, we found that by building a driver that would provide the gate limit voltage of 20vdc for that particular fet, things got lots better. We still had a bit of an issue as we were trying to switch 80-100 amps with an oscillator derived 20 volts (system was 5vdc battery power). We still had some "non square wave" turn on response. The voltage was there but we still had problems overcoming the gate capacitance....

We then tried a new (at the time) IRLZ44 logic level fet. ALthough designed to drive at 5vdc, they had a gate tolerance of 10vdc. HUGE difference. We could derive a relatively robust 10v bus with a bit more current so as to drive the fet gates.

When we could generate a true square wave turn-on and current flow, wah-lah, the fets ran at room temp even while switching on the desired current.

BTW, we were driving 6 in PARALLEL which was why we had a problem turning them all on with the limited bus driver voltage. The voltage bus was derived via step up of the 5v battery voltage. Circuitry was TINY and current density high. Imagine switching 80-100 amps at 3-4khz with a controller that had the foot print 2/3 the size of business card....

Your driver circuit is SUPER critical as is your mosfet selection, especially when you're driving at 20-30Khz frequencies. You MUST turn the fets ON and OFF in a tru square wave fashion at those switching speeds to keep fet resistance low and heat under control....

I'd say the if you used a ROBUST driver and appropriate fets for the application instead of whatever is lying around, the heat problem in your fets will be eliminated...

[DukerX]

Yeap...
I DO have a problem whit non-square gate voltage on my fets.
I know this causes problems.
As this is just an experimental unit, I resorted to using whatever I had on hand.
The whole idea was to see what it would take to make it work.
I'll do a few more experiments whit my highly unsuited fets, just to see if I can make it work the way I originally intended, or if I should shelve the whole idea, and use a more common chopper design.
If I could just speed things up a little, I think this could be a really neat device, whit a very low part count.

I'll get back when I have more test data to show...

[Carel]

DukerX:

Don't give up, for the commanding of the mosfets (and yours are suitable enough) you need a component layer between the controller and the mosfets. This layer makes your driver more flexible. I use a complete discrete component layer for driving the mosfets, and yes it's 3 transistors and 6 resistors but it is working the way it is supposed to be. The main value of your design should be in your program. And you are learning the mainstream controller, the AVR. Side question, already smoked out an STK500 board? The reliability seems to be embarrassing.

Carel

[DukerX]

I replaced the transistor I'm conducting my current/PWM tests whit a 2SK1936 part, wich has slightly lower switching times, and as far as I can tell, the gate/source capacitance is lower too, as the gate voltage now are closer to perfect square wave.
During the test, I observed that this transistor makes alot less heat then the IRFP250 I used before.
I also reduced the mcu clock to 8MHz, giving a PWM frequency of 31,25kHz
The reduced PWM frequency resulted in much less heat forming in the transistor, but also shows the current starting to increase rapidly when the flyback voltage stays at 2*Uinn, and the flyback diode in the transistor unloads the reverse voltage from /A back into the supply voltage.
This can be seen in the following graph:

Look at 50,4%.

Rumors have it that the motor current is going to change when it starts moving... If this is true, my attempt is in vain.
The only thing to do, would be to pop inn some current sensing resistors, and build a proper chopper driver instead.


Regarding the STK500... It's funny you should ask... I have already fried one of those, but that was entirely my own fault. I did something wrong while I had it hooked up to a Sanyo STK6713 integrated chopper driver. I hadn't adjusted the chopper properly...
The STK6713 chopper blew, feeding the back-emf into the AVR on the STK500, and after punching through that, went on to fry much of the STK500 components. Even blew off one of the capasitors.
I'm glad the STK500 took the punch, cause it was hooked directly to my computer on the 12V line, COM port and printer port...

[pminmo]

DukerX,
Without a realtime true current measurement/sense your efforts won't yield a workable solution for microstepping. Many factors involved. Your experiencing MOSFET drive issues on the gate as well, unless you are using a logic level gate with relatively low gate capacitance, the AVR's outputs are going to be over taxed at fequencies necessary to do chopping and microstepping.

That solution is to drive with a MOSFET driver such as a Microchip TC442x or a MC3415x. IRF has a good ap note on your problem: http://www.irf.com/technical-info/appnotes/an-937.pdf

[H500]

Duke, I think the biggest drawback with the open loop PWM approach is that the rise time of the current in the coils is too slow. You won't be able to spin the motors very fast before they stall.

[NC Cams]

Until you drive the fets on HARD and FAST, you can't judge the system performance.

Once you get that accomplished, you then start to use lower on resistance fets so as to drive the resistance point someplace else. Simply use a GOOD driver with lots of oomph and the lowest resistance logic level fets suited for your type of useage potential...

I think that the current rise time issue is addressed by running higher voltage. I think this is why the P/S voltage is so much higher than the rated voltage of the motors (25x or so if memory serves correct).

Once you get your switching circuit to switch the fets on in true square wave fashion at the current level desired, you can then start working on the inductance issues.

Ultimately, however, the motors will run at a max speed for a given applied voltage/current relationship - you can't push a rope so to speak.

You can help out the mosfets by putting diodes around them. Yes they have built in diodes BUT in some instances, you need external diodes (pretty sure schottky or some other ultra high speed items) to deal with back emf being kicked back by the motors.

While your at the IRF website, look around for other app notes relating to PWM motor controls. Chances are, they've already dealt with the problems you're just getting to deal with, especially with regard to high speed printer applications....

[H500]

Even with high voltage and maximally driven mosfets, I expect that the rpm would only match what is possible with a 3 volt supply. (assuming that 3v is the motor's rating)