Oh, I just looked at my circuit, I did tie the other pin to ground. And fed my input to the other pin.

Ah, I think you meant you tied the inverting input to ground, and put your input signal to the noninverting input? Two references to "other pins" is less than a completely clear description

Also noticed I forgot to add my diodes beside the output mosfets. Even forgot to rename the output mosfets to the correct model number.

Well, you're making a list. Check it twice

I'll have to see if eagle does functional block diagrams.

Sure, why not? Just use the wire tool, and draw on a documentation layer in the schematic capture portion. Make it a separate file from the schematic you've done so far.

 

I think its just a fatal flaw with the UC3710.

Tried to do some more improvements to the circuit and it just doesn't like it.

I switched to a single mosfet and used the same drive circuity, tried some of the cap improvements etc. As soon as the duty cycle gets close to 0 the driver chip shuts down. It will not recover from this state. I tried to ground the input pin, even to full 12v. Then back to signal. Once this chip shuts down it will not turn the mosfets on no matter what. The only way to reset the driver is to ground out the power input pin to ground to completely discharge the driver. I even tried limiting my input signal from 0 to 2v and 0 to 3v with no improvement. Once the circuit reaches low duty cycle its done.

I may start looking for a new driver chip soon. Or since I'm only driving a low side mosfet bank, I might just make a push/pull discrete transistor circuit to boost the current from the 555 to the mosfet gates. This is not really what I wanted as I wanted to eventually make this same circuit as a full bridge.
Finding high current drivers is hard and I'm not sure I'm ready to deal with the extra complexity of doing parallel drivers to supply adequate current.

 

OK. Rather than trying to go all the way to zero PW - try cutting the frequency of your 555 by adding capacitance. Increasing your OFF time will have nearly the same effect as decreasing your ON time. You might change your single 555 circuit to a dual 555 or a single 556. Have one of them output a fixed-width monostable pulse, the other varies in frequency. It's still PWM, but you're changing it by the base frequency instead of simply the ratio of ON to OFF time.

 

Neat. I tried something new. I found that 10 mosfets was overloading my UC3710. It runs 5 parallel from 0-100% duty cycle. After I added 4-5 capacitors in parallel right next to the driver. I also had to redo the distribution bar for the mosfets. Found them to go into super high resonance when the driver got to 0% drive. Well into the Mhz range which then the driver didn't have enough power to bring the mosfets out of that stage. I added solid copper wire to connect all the gate resistors after I flattened it with a hammer and anvil. Then annealed it to soften and soldered all the gate resistors to it.

If I had low ESR resistors it might actually work but I don't so..

I might try parallel drivers to see how that does.

 

See? I told you the caps next to the driver would help.

Do you have a board layout done up in Eagle? I do happen to have v4.16r2 installed.

You're going to need some mighty thick traces. More like large copper bus bars salvaged from an industrial electrical service panel.

 

I started to to a board layout a while back for a theoretical build to test my skill. I couldn't get the traces big enough. I was thinking of just doing decently sized traces then baking on a nice thick copper bus bar to the top of that with some solder. The traces would draw the current to the bar only a few millimeters away.
I gotta stop being lazy and put another driver on and test it. Then start adding my protection circuity. I think my version of eagle may not do a layout large enough for what I have. but I could do separate boards and just wire the lower powered control signal with some shielded wire to the driver chips that are right at the mosfet bank.

 

Making traces thicker by soldering will be problematic.

Solder has far more electrical resistance than copper. Tin is about 6.7x, lead about 13x, which are the two main ingredients of Sn63/Pb37 solder. So, the thinner the layer of solder, the better. Copper is also a far better conductor of heat than either of those elements.

OTOH, the main goal is to keep the traces low enough in temperature to keep them from becoming fuses, while passing the current necessary to drive the load and trying to keep the board at a reasonable size.

As far as the drivers, you might use one per 5 MOSFETs, and also use missing pulse detectors as a diagnostic tool. If you get a gate pulse on 1/2 of the MOSFETs and not on the other half, shut the whole thing down before you burn it up.

This kind of thing could be implemented using 555 timers, but it sure would be a lot easier if you used a uC (microcontroller)

 

Ewps I ment to say that I wanted to lay down some nice traces, but then solder a bus bar right on top of the traces. So there would only be a thin layer of solder between the trace and the copper buss.

I finally got around to making the powersupply and logic circuit. Later I will make one of the functional diagrams you suggested with some documentation maybe tomorrow. Its pretty late here so this schematic probably has errors on it and will probably need more refining. These circuits are all on different protoboards and will be combined soon. The only circuity I've soldered up so far is the driver + caps. The rest are on solderless breadboards. Want to save etching for the last step.

 

Your schematic is appearing a bit crowded, and you have pins overlapping wires where the error check will complain about it. The error check tries to ensure that there are no ambiguities in the schematic.

Once you create a board from the schematic, make sure that you never update one without the other being open at the same time, or your life will become quite unpleasant until you managed to resolve the differences.

If you zip it up and attach it, I'll clean it up a bit for you.

Download the attached file, unzip it and copy unitrode.lbr into your
\Program Files\(Eagle program directory)\lbr subdirectory. If you already have a unitrode.lbr, rename this new one to unitrode1.lbr or something similar.
Then within Eagle, issue the command:
USE unitrode.lbr
(or if you renamed it, whatever you renamed it to)
I only created the UC3710T TO220-5 package in vertical and horizontal orientations, since that's the package you have.

 

Awhile back, Dave changed the forum settings to allow Eagle SCH and BRD files to be attached directly. That avoids the small risk of a virus from a ZIP file. John

 

Off topic: how can I get a virus from a zip file?

 

Don't know exactly. However, I got a warning the other day from my anti-virus with respect to a zip file that that type of file might contain a virus.

Maybe the compresion routine can mask certain types? In my case, if I get a warning, I don't bother to see if it is valid.

John

 

I think that is just a warning for those peole who mindlessly open anything they get into inbox.
Nothing can happen until you open the files inside.

 

Awhile back, Dave changed the forum settings to allow Eagle SCH and BRD files to be attached directly. That avoids the small risk of a virus from a ZIP file. John

Thanks John, I forgot about that.

Perhaps .lbr files could be added to the list of "permitted" attachments. Guess I'll mention that in the feedback forum, as it seems the most appropriate place.

 

The SCH files are so large, I believe, because they include the .lbr files with which they are created. Of course, that doesn't help when you want to send a .lbr to someone.

You might consider sending a dummy .sch to someone that includes the part whose .lbr you want to send.

John

 

You might consider sending a dummy .sch to someone that includes the part whose .lbr you want to send.

True, but then they'd have to figure out how to get the item copied to a .lbr from a .sch file. Frankly, I don't know how to do that myself at the moment - nor am I certain that I'd want to. Seems like a good way to accidentally contaminate/corrupt .lbr files.

 

We are way OT, but my guess is that in Ver. 4.xx with the "foreign" schematic open, one uses the Library button, then open, and the rest of the complicated method for cutting and pasting library parts while building the new component in your personal library. Can't test that though, because I have no imported schematics with different libraries. Even if you attached a .LBR file, the recipient might have to do most of the whole routine just mentioned, if he is using Ver. 4.xx and doesn't want to just add the whole file as a separate library entry. I would be willing to help work out the details off-line or in another thread, if you want .

Ver 5.0 is supposed to be easier for copying and adding library components, but I haven't tried it.

John

 

Hotmails virus scanner will signal a virus in my .bmp files I packed myself with zip. I know for a fact these files were clean, I created them. I don't use hotmail for this anymore, can't. In my opinion Trend Micro is suspect.

 

Thanks for the component for my library.
Haven't had much time lately.

I did attach the 2 circuits.
I'm not sure where the overlaps are that you describe.

 

Oops - I have 4.16r2, registered version. Don't feel like spending more $$ to upgrade it, it was expensive enough the 1st time around.

I can send you files that you can read, but I can't read those that you create.

So, here's my "gripe list"

Schematic gripes:
1) Overlapping junctions,namely:
A) B1, diode bridge - it's leftmost connection overlaps GND.
B) R8, pot - Pin 3 overlaps the signal out from IC1A.

2) Crowding, namely:
A) Around IC2A, many text items are overwritten by signal lines.
B) C4, C5 - similar.

3) Incorrect usage of symbols, namely:
A) TR1 - the primary side is the lower numbered pins, EG: 1 thru 3.
If someone took you literally, they might wonder why you were feeding 1200v to the input of a 7812 voltage regulator.