[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)

[DukerX]

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)

Now you put your hand in a wasp nest buddy

Why would anyone go to the hassle of overpowering the motors by as much as 10 to 20 times rated voltage if it had no benefits???

[NC Cams]

key word is "I think". Saw the 25x posted on a prior m/b post.

My understanding is that the higher voltage gets the thing to move before the current gets too high an since the motion took place, the controller folds back current (voltage reduced) to manageable level.

Short duty cycle is the key to judicious use of over voltage... If i'm wrong, i'm hoping that we'll all get straightened out via a reference post to the proper answer...

Maybe one of the following links has the correct answer....

Servo vs Stepper:
http://www.cnczone.com/forums/showthread.php?t=17419

Simply stepper info:
http://www.parkermotion.com/catalog/catalogA/A12.pdf

Stepper reverse engineering:
http://www.doc.ic.ac.uk/~ih/doc/stepper/others/

Stepper sizing:
http://www.cnczone.com/forums/showthread.php?t=17707

[DukerX]

I've been trying to wrap my head around this issue of quick switching times not being obtained...
It has been pointed out that I need super-low gate resistance fets.
fair enough, but I don't think the resistance is the problem, cause the close-to perfect square wave from the PWM pins is deformed when I connect it to the gate.
The AVR simply don't have the juice to charge the gate field fast enough.
Reducing gate resistance, I think, would just lead to a more distorted pulse shape, as the output current from the AVR I/O is not going to increase.
Using logic level hexfets would increase the gate capasitance whit roughly 33% and further deform my gate signal.
I think I'd better throw in a few more small transistors to drive the FETS properly instead of expecting the AVR to do all that work...

All in all, this doesn't seem to turn out as simple and straightforward as I expected...

[Carel]

Ok, you can see the gate of the Mosfet as an capacitator. To set the Mosfet to the "On" state you need to charge it (and fast to avoid dissipation). To switch it off you need to discharge (and fast to avoid dissipation). The AVR port can not Source and Sink these momentary currents fast enough. This is done with a "Totempole driver". I googled for a few moments but could not find a schematic. I have here a book on Power Mosfets where all these issues are described. Maybe your library has a similar book. If you cannot find this information, I will scan the page with the basic driver and put it here. Hope this helps. Master this and you have a versatile switch or PWM for all sorts of applications.

[NC Cams]

Driving gates at ultra fast switching speed is EXACTLY why mosfet drivers were created.

They also have built in protection against simultaneous conduction when fet A is supposed ot be off with respect to fet B.

Please review Post #9 again.

The used of discrete totem poles to drive fets at high speeds just won't cut it.... The capacitance of the traces et al combined with those of the fets just kills high speed switching capabilities.

Although this is a great learning experience into the vagaries of mosfet switching, at some point one needs to stop reinventing the wheel and/or proving that the earth is round....

[Carel]

NcCams

This guy wants to make an unipolar driver (post #1). Dont confuse this with a driver for an H-Bridge. 20Khz is NOT an ultra fast switching speed. Apart from what you want, one can also experience availability and budgetary problems. I was not aware there was an anti-discrete components policy on this forum, so I will not mention them again, but use them for my own pleasure (and business).

Carel

[NC Cams]

I wasn't aware of any anti-discrete policy either - I was only trying to solve the apparent problem he was having due to a percieved/apparent lack of robustness with his fet driving methodology. I simply don't think you'll drive the fets fast and square and hard enough with a pull up resistor and an open collector sinking it to ground - we tried and failed at 60 and 3600 hz.

My point remains that "quick" switching has its issues when you're trying to charge/discharge mosfets. And, fet drivers are proven and affordable interfaces for doing what he's trying to do.

My prior post regarding the R/C control circuit involved trying to drive fets with op amps and/or CMOS circuits and PWM switch mode power supply circuits. At 60hz for the batter charger circuit and 3.6khz for the motor speed control, we came up against the same problem the member outlined in his original post.

Our/my ecperience is all that I"m citing and what we did to solve it. If we had problems at 60 to 3600 hz, I can imagine what he's going thru at 20khz. Yes, it is not "fast" but I seem to recall that the IR handbook does point out that circuit capacitance becomes much more critical at higher and higher speeds.

Die sizes further create challenges as speed and current densities increase. Sadly, fet drivers were JUST coming on line when we were doing our original fet research and BOY were they expensive and hard to find. Now, DigiKey and many others have them readilly available.

A popular totem pole driver or half H bridge is made from 2N4401's/2N4403's. They can source sink about 500ma at best IF (big IF, too) you provide enough base current. We tried and couldn't.

Yet, even a generic fet driver can easily hit the fets with a 1 to 6 am shot at Vgs voltages up to 20 volts for a "standard" fet and 10 volts Vgsfor a logic level fet- at that point, they will SURELY be on and fully conductive.

Thus, depending on the die size, the fets are conducting as much you can hope for and any of your switching issues, at least from a fet standpoint, tend to become inconsequential. You have to look elsewheres to remove bottlenecks to current flow/solve switching speed issues once you drive the fets properly....

Ultimately the conductivity of the fet is a function of gate voltage,how much current you're trying to pass and how fast you're trying to do it. What may work at 1 amp with a low inrush current potential may not work as well with high capacitance circuit with high in rush potential, even if constant STABILIZED current is only 1 amp.

Hence, when you exhaust the potential of the parts you're using, you either have to recognize the limits you face or use different parts or modify the design execution.

Only trying to point on where problems may lie and how solve them. Sadly, nobody took the time to point this out when we went thru our R/C controller fiascos but I'd surely have appreciated if someone had done so.... This is all that I was trying to do....

Besides from the looks of the measurement results that the member posted, it seemed as though he had access to GOOD equipment and probably the parts and funds needed to solve the problem.....

[pminmo]

Couple of points:
1. The speed issue is rise and fall time, not frequency.
2. I don't think there is any policy disciminating against discretes. But it is simplier to use a MOSFET driver, rather than discrete components.

:cheers: