Driver design for TPH-050

[Doug Coulter]

A lot of these turbos are showing up surplus for a good price, sans controller, so a good driver for them would be a nice thing to develop. This is one of those "where to put it" topics, as it could just as well fit someplace under electronics till a real driver is fully designed, but then, no one would see it to contribute to the trade-off analysis if they were looking for vacuum pump information.

Sigh, science just doesn't fit into pigeonholes too well. Here is the design posted on fusor.net by Alex, and the reasons I think we should do a better one.

A controller design

TP controller diagram 1.PNG (115.35 KiB) Viewed 7342 times

There are a couple of things not to like here. One is that current limiting R, which doesn't make full current and voltage available when it should, and is used to cover some other issues.
Next, even as a guy who prototyped a ton of complex TTL stuff back in the day, and tends to keep too much stuff, I really had to go on a hunting expedition to find those parts. So, if people are going to have to order stuff to make this work, why not use newer stuff that's going to have a bit longer market lifetime? Further, there is no output on status to show up to speed other than a led. I like the simplicity, but what if I want an output that tells the forepump when to run, or data out to log on a PC? Can't get there easily from there. Al;so, in my version there's a very nasty inductive kickback on the fet outputs that goes way over twice the supply voltage, which can't be so good for reliability. This is over and above the normal 2x the supply you'd expect from driving what is essentially a center tapped transformer.

Here are some things I've looked at, or am looking at as improvements on this.
First thought, was why not use 4000 series cmos? Then it could all run on 12-15v, use cheaper normal-threshold fets and so on. Well, if you are going to stay with about the same feature set, and don't care that that stuff is about to be hard to find, then that is a possible way to go. At these speeds, even cmos will drive a fet quick enough, and it doesn't have to be a large fet either to handle the motor. (current limit spec is about 2.2 amps for the motor). More troublesome is the voltage rating the fets need to handle kickbacks -- no matter what.

One way to get rid of that big series resistor I object to would be to go to some sort of PWM to limit the current at the lower speeds, where the back emf of the motor windings isn't very high. Here on my bench (in air) at about 80 hz, this is about 4 volts, so trying to drive that to 30v is going to create some pretty big peak currents, in fact, my 3 amp current limited bench supply won't do it. I looked at various PWM controller chips, but getting them to stay in sync with the huge rotational range (near zero to 1500 rps) doesn't look like a fun thing to tackle at all.
A possibility would be to sync a PLL to the Hall sensor output at some large multiple of the rotation rate, a 4046 will do this fairly well, but...leads to a lot of complexity.

I recalled that one of the small switcher chip manufacturers took a different approach -- just measuring the current on each pulse and shutting off the drive when it hit some fixed level (if it did). Now, that makes more sense to me, and it's not hard to do with a current sensing resistor (small wattage by comparison) in the fet sources. A little re-jiggering of the circuit allows this, with just about the same net complexity, so that looks very attractive to me. Here's what you get when you do that.

Proposed sub-circuit for new driver

Edit: No EE's have read this one yet, or they'd have mentioned I really need two current sense R's and separate transistor drives to the sets on the flip flops, or this will "chug" and not do as desired -- it will just spin up on one phase (which works, but...). I'm just getting going on building this now and noticed that flaw while modeling in my head...

Here is the core subcircuit I'm proposing, for use either with a uP or some other speed control device. While all this could be bit-banged in the uP (literally all but the fets and current sense R), that gets one into a little bit of timing jitter due to interrupt response times, and makes all the rest of the uP software harder to write -- possible, but harder. I think JohnF would appreciate that this won't fry things almost no matter what the uP would do, even though I'm used to writing uP code for hardware that will fry things if my code has a flaw, with good results. It's just better this way, in my opinion -- use each thing for what it does best. In this case, the uP would provide the reset, speed measuring (by looking at the hall input) and speed control, by forcing the flops to set when over speed was happening. Further it could monitor whether the current limit pulse shortening was occuring, and the average current through the sense resistor as well, to be able to know whether to turn on a forepump for one example. The uP I have in mind here is a PIC 18lf2523. It's way overkill for just a pump controller alone, but has many 12 bit a/d inputs, various timers and other neat hardware, like a UART in it, all interrupt driven, and I have some and the tools for them already for other projects. Depending on the package, they are about $7 in ones quantity. The uP could also eliminate the transistor for current sense (built in comparator and reference) if desired. The chip is dirt-simple to use, needing only 5v and a bypass cap and code to get going -- internal 32 mhz oscillator, reset circuit and so on and is in-circuit programmable (and debuggable). I have already posted my opsys core for this on the software forum -- that part's done. It's easily capable of outputting a lot of stuff via RS-232 by merely adding printf() statements, and is already running the a/d converter for 4 channels of input. Adding some counter inputs for neutron detectors or whatever else is trivial.

But the subcircuit doesn't handle the speed control at all (yet), without a timer or a uP. What I'd like to see is at least two set speeds - one for max pumping, and one adjustable "standby" speed for running the gas control scheme I've mentioned elsewhere for fusors. At fusor pressures, one has to spin down a goodly bit or the pump is just working too hard and overheating (and wasting power, which is very much against my religion -- I don't have it to waste on cloudy days).

Some adaptation of the 555 part of that circuit could do it, and you'd have a simple all discrete design, to be sure. However, that still doesn't give me all I want, and since a 555 isn't a retriggerable oneshot, it won't do it the best way. I like to get data out of all my sub-systems for logging into my database, and the "vacuum subsystem" is no exception here. This brings in the spectre of using some sort of microprocessor, which I know some people don't like the idea of (unless you can find someone to program them for you, it's an expense for a hobbyist -- I have about $600 in the tools for this, not that you can't do it cheaper, I got the good stuff because I do this a lot). They are, however, not costly as a part, and they can bring a lot to the party, such as being able to accept some other inputs for logging to a PC, some smarts to handle accident situations safely, and possible display driving or control for things like intermittent forepump control, and doing all that without one would take a heck of a lot of parts and be even more complex.

So I guess I'm polling for input on that -- would people like to see a uP in the design if I publish the code and offer to supply them already programmed? The dollar cost would be pretty minimal. I am planning do do a PCB layout at any rate, and make that available as well, either way.

This subcircuit is simple. Basically all you have to do to make this thing spin is to use the hall sensor as drive to one fet, and the inverted version to drive the other one. If you hook up the motor phases right, it spins the right direction, if not, not. My additions to that are the flip flops that allow drives to be individually disabled on overcurrent more or less instantly. The next hall clock edge that comes along (when a particular driver would be turned off anyway) re-enables that driver if it had hit current limit and set the flop connected to that phase.
Some sort of snubbing is going to be needed on the motor outputs, there is enough leakage inductance in the windings to make a fairly fierce kickback there, even with pretty slow gate turn off, as this gives due to the low current output of the HC logic. I suppose if one wanted to avoid that and warm up the fets slightly, one could slow the turn-off further with a resistor and diode in series with each gate, but that does risk issues with EMI getting into the gates from other things around the fusor. The advantage of this circuit is much faster spinup time, and better regulation in high gas loads, as well as much less power wasted in a big series resistor to the bulk motor drive supply. The circuit, including a possible uP would barely draw enough power otherwise to keep a 3 terminal 5v regulator at it's minimum current to give good regulation!

Comments? I am going to do this, being now the proud owner of a couple of these pumps, with hopefully more on the way. Even though I'm "turbo rich" this opens the door to a lot of other things I've not been able to consider -- like for example a differentially pumped ion source (using the same forepump as the main turbo) so I can go to lower main tank pressures, which is the way I'm heading now. My Q and output are going up fast as I hit my current limitations on how low a pressure I can run and still have ions, even from an external source, no peak in sight yet.

The other idea that still has some currency in my mind is due to the nature of the drive required here. One could simply use a half bridge and drive the windings in series as well, at half current but twice voltage -- and that handles the kickback issue at the cost of having to have a half bridge driver. Again, thoughts? If nothing else, this shows well the tradeoffs one considers when doing this sort of design.

Here's the start of a pcb layout -- I'd designed a board around the 28 pin pic family for another product, and I just erased the stuff specific to that one (A Thiele-Small parameter woofer tester). The rest of this would fit in the now-blank space, I think (or I can expand it) but note -- only two tracks or jumper on the top side, and this is enough to give you pic, the power supply from an ac adapter, and rs232 to a PC host, as well as in circuit programming. This is the kind of thing one might save as a "component" in the traxedit library for further use, very handy, all the hard work is done already, including a basic opsys/drivers for the chip I want to use. We decoupled the rs232 converter chip to avoid having noise from it getting into the a/d converters.
All through hole, easy, cheap. AC or DC input, up to the level the 5v regulator can stand -- hook to power and it's running.

"Blank" PCB layout for uP projects

The backward DSJ is the sig of the fellow who worked here who did this nice basic layout so it could *almost* be single sided. Dale Jorgensen deserves credit for his fine work. No ground loops or other ways for noise to get into the a/d inputs for example, and that's no small thing with 12 bit resolution. Ground is never just ground...

[Chad Ramey]

Doug,

First off, I think it's great that you've gotten this thread started, because I think we (especially myself) could use a much "engineered" (further improved etc. etc.) way to do this.

Secondly, I got Alexi's controller functioning properly on my pump last week but since, I have noticed a fairly large issue. After running the pump for the first time, I turned everything off in order to prepare for a second test to insure that the circuit was reliable and would work for a second time (Something I had already done in air with the flange off of the pump, but had not yet tried in air). Upon restarting the circuit, the red light turned on but did not begin blinking to indicate rotor spinning and the normal whine of the turbine was not heard. I tried reseting the circuit several more times, checked my connections, and power supply each time I encountered the same results so I decided to disconnect the pump from it's flanges. Once I had the turbine blades exposed, I turned the rotor by hand for a half rotation, turned the circuit on, and the pump finally spun up. I guess there must be some dependency upon the hall sensor to determine the startup position of the rotor, and if the rotor is not correct then the pump wont start. While normally I wouldn't consider it too much of a hassle to simply mess around with the rotor, it's a heck of a lot of trouble to have to take the entire system up to air and disconnect the pump to do so. Is there any way to address this issue?

My third statement is this: I have found that a 28volt powersupply is pretty freaking hard to find. I built a circuit with two 7824's together (as to double the current output) but the 7824's were fairly unreliable do too overheating and quickly became a hassle. I have since switched to using three nine volt batteries; which actually works quite well, but looks kinda ghetto and I'd like to have something that I knew didn't have a quick expiration date. Any ideas on a powersupply that would be suitable?

I've got some money to play around with and abit of time on my hands so with a bit of guidance I'd like to assist with the development of your controller and hopefully purchase one for my own use as it seems like a step up from my current rig.

(I have posted several videos on my youtube channel about the circuit and how it works with the pump if anyone wants to check them out: http://www.youtube.com/user/votedthewave)

-Chad Ramey

[johnf]

Okay
I've been sitting on the sideline, but I think I have a bit to offer

where I went wrong with my turbo controller, I didn't allow for the idiot factor.
I got the following from one of our phd students
I had an arc on the ion source so i killed the power to the system
I then reapplied the power and the turbo controller/ turbo made a funny noise


Breakdown of this is turbo running at 70,000 rpm power killed controller restarted commanding turbo to 3000 rpm.
the controller took the excess energy by shunting the excess bus volts but the turbo had a major de- accelleration NOT GOOD!!!!

Any new controller should put a small DC current into a motor winding so the control program can sense by back emf ie the rotor speed before any power is applied and act accordingly.

OK I'll crawl back under my rock

[chrismb]

Can I please just clarify something, which I expect has been asked before in different places, but to keep it in one place;

Is the TPH-050 a two-phase motor and this circuit is for a two-phase motor?

Whereas most other turbos are three-phase? Are there any other two-phase turbos?

I'm just wondering if two lists, of two and three phase motors, is useful.

[Joe Jarski]

Chris,
The TPH-050 is a single phase motor. I can't speak on if most pumps are 1 or 3 phase, but I'm running a 3 phase (Varian) now and also have some single phase Alcatel/Adixen MDP-5011 Molecular Drag Pumps that I need to make a controller for.

[Doug Coulter]

I need to do more tests to prove this, but.... (and yes, lists would be quite useful)
It appears the TPH-050 would suit my definition of a single phase motor, actually. The drive circuit above, as well as the one I'm working on, if connected to say, a center-tapped transformer winding -- would produce a single phase output on another winding. Either one or the other driver fet is always on - push-pull as defined in other fields.
The hall effect sensor seems to be (and I have to verify this most closely) about 90 degrees leading in phase for the "B" motor input. If you reverse the motor leads, it spins the other way.

I theorize at this point, due to this, that you could actually skip the center tap entirely and drive this via a half-h bridge across the two windings in series, at reduced current and higher efficiency (at higher voltage). This would have several advantages due to the power loss equation being I2R. The transformer power supply guys would call that "better winding utilization". This is because you'd always have the current going through all of the windings, instead of twice as much, for half the time, in each -- that square term kicks in.

To this point, all my tests have been done with a current limiting supply and at pretty low voltage, in air. At 80-90 hz (which is as fast as it will go in this situation) the back emf seems to be 90 degrees out of phase with the hall output. As things speed up from zero, the current waveform changes due to the inductive (and serious leakage inductance) load of the windings. It's not a "good" transformer.

Which leads me to report on tests of the proposed circuit above, made last night (my time). What have we learned, Dorothy? It seemed like a good idea at the time. But in real life, not.

While the circuit worked more or less as expected, system performance was stinky. The reason was the current waveform, which is very high current near the beginning when a fet first turns on (and of course, changed in where the peak was with speed somewhat). This tended to "trip" the pulse shortening too soon, resulting in low average current draw and slow spinup. Had I set the trip point higher, in cases where the waveform smoothed out (at high speed due to leakage L etc, assumed, not tested) I'd wind up with a current limit at too high an amperage, with the possibility of burning the thing up. I have to say, it's never gotten warm in hour of running, no fan on it, at 2.2a average current -- but it's a pretty good fan under the conditions I have right now itself.

Also, at the turnoff (when the current limit tripped, at any voltage over about 4v input) the kickback spike was fierce indeed -- 50v peak with 4 v input DC. A snubber that would take that out (tried that) so you wouldn't need 200v fets wasted plenty of power. It's just not the right approach to this particular load, so I'm ditching it. Slowing down the fet turnoff to eat that spike in the fet made the fet get warm (which they don't, without heatsinks in the 100% duty cycle drive design).

So, that was a fail, if not quite an epic fail, and another plan will have to be adopted (this IS intended to be educational, and things like this happen in any design process). That plan may have worked fine once the rotor was up to more like its normal speed, but I can't test that yet, and I wanted fast spinup with tight regulation, and this isn't getting me that.

So you could call this a 2 phase motor (much as our mains power in US is called 2 phase when using 220v centertapped ) but really it's only one phase, with a leading output from the hall to drive the resulting "oscillator" so it will turn the right way. The driver JohnF shows elsewhere is indisputably 3 phase, 120 degrees offset per, and it makes sense that most motors would be done that way, as this also takes care of getting it to always spin the right way. This motor is permanent magnet by the way, plenty of back emf (which means you can really get braking when you want it) as also stated in the manual for it.

So, now it's on to plan C. Plan C makes the subcircuit super simple - just two nor gates and the hall input inverted to one of them. The other input of both becomes an "enable" for speed control. Due to the body diodes in the fets, it brakes very nicely when drive is removed from the back emf and its own friction -- this may change at speed and in vacuum, depending on if the back emf current can drive the DC supply voltage up or not.

To make plan C work, the bulk DC for the motor is supplied by a current limited switcher instead, and the drives are 50% per "phase" duty, or (gotta try this) driven by a half-bridge, or for that matter a full bridge, but that's getting into more parts than I'm hoping to use (we may make a lot of these after all, and even sell them).

This kind of militates using a uP for control, with whatever advantages and disadvantages that brings. I think the advantages wipe the floor with any disadvantages here, so that's what I'm going to do. The PIC has a hardware PWM generator in it (actually, a couple), which can be used to control a switcher for the power supply. Current feedback from a tiny sense resistor goes to an a/d input, and the loop is closed in software -- saves a lm3524 chip you'd need otherwise (and I've done things like this before, they work great). PICs come up with all I/O pins floating, 3 state, so a simple pullup on the "enable" means the thing wont' try to spin until the software is ready for that, and the switcher won't make power either until commanded to -- if the hardware guy has a lick of sense, this is pretty doggone "safe" and the things JohnF complains about don't apply -- nothing int he PIC needs to go particularly fast or respond quickly, though it's plenty fast enough to do that were it needed. The PWM generator, once set up, does not need constant attention from the software -- once a duty cycle is set, it free runs at that duty until you change the number in a register. The "grab a/d samples from multiple channels at 100hz" code is already done and tested in the opsys I show elsewhere on the board, not a big deal at all.

The uP brings RS-232 to the table, which I am very fond of. Even though most computers don't have a lot of serial ports these days, we've had fine luck with USB<>serial converters, we even have some that go two to a USB port. This moves the design questions to another place on the map -- we can have the PIC do push-mode outputs of what's going on, and be automatic otherwise, using something like a simple switch to go from off to enable, to standby, or add the possibility that it would be PC controlled from your computer, or put an LCD display and a rotary encoder/pushbutton interface on the thing for pure standalone operation with a lot of flexibility (we do this on our PIC based geiger/neutron counter box). Adding the LCD/encoder/menu system IS a pain to do (a bunch of state machines in software, and it uses a lot of I/O pins for the LCD), and of course is more parts and cost, however.

So, at this moment, I'm leaning to a little box with a 3 position switch for off/standby/fullspeed, RS-232 output, and RS-232 input so the PC can take over control with suitable commands.
Probably do this pure-ascii, so neither end of the comm chain needs to have a fancy protocol, and all the stuff going by on the wire is "human readable". The PIC would simply use a hardware (built in) counter sampled once a second to see how fast it was spinning, and an A/D reading to see the current, and adjust the PWM duty cycle accordingly to get the speed desired. The result should be that at full speed in good vacuum the power should be minimal which is very much desired here. I use italics there as till I test it -- I don't know, I'm guessing.

If we skip the LCD/UI stuff on the pic, other than the simple switch, then there will be a lot of I/O pins left over, even in the 28 pin version. Some of those are A/D, there's another PWM we could use, and a bunch of plain old CMOS I/O which is beefy on the output side -- PIC pins will make 35 ma drives directly. So some code could sample some extra a/d inputs and counters and so on, to make the thing more useful. For example, our geiger box also looks at the main fusor HV and pressure gage and spits that out second by second, time-aligned with the geiger and neutron detector outputs, making shoving all that into a PC database a snap -- the timing in the uP is far, far more deterministic than in any PC, linux or windows will ever be.

PC's are really where JohnF's objections to computer control are true in spades, as I've done a lot of work trying to do realtime things in them. You just can't control latencies, and it's not always the fault of the opsys (FWIW, win95 has the slickest and smoothest multitasking and threading of any opsys in existance for an Intel CPU). But that doggone CPU exhibits what we started calling the Pentium pause seemingly at random, which makes realtime hard deadline things very hard to do without ancillary hardware to take care of the fast stuff. Evidently this is some sort of thermal issue, they just stop the thing sometimes to keep it from burning up -- inside the chip, it's not under software control that I'm aware of.
At any rate, by having a purpose designed and programmed uP, we skip those issues entirely.

[Joe Jarski]

Doug, you're absolutely right - it is single phase. A rough night and too early morning had my phases, poles, AC & DC all mixed up! I'll go back and edit.

[Doug Coulter]

Joe, sounds like this one I'm doing up would do most single phase things? Any thoughts on what I'd do to make it flexible enough to do your other stuff along with this?
Does your single phase thing have something like that handy Hall signal coming out?

[Joe Jarski]

I would think that what you're doing could be adapted to most single phase units with some tweaks on the voltage and frequency. The pumps I have do have a Hall sensor and permanent magnet rotor, which I would think is typical on the single phase variety. They only run at 37krpm, the Hall sensor is at 90 degrees to the windings and I'm not sure of the voltage.

BTW, my 3 phase pump always starts at high frequency and then draws down over a second or two until the drive frequency matches the rotor speed wherever it happens to be, whether it's stopped or restarting at 60krpm. I'm not sure if that's typical, but that's how they deal with the restart issue without accidental high speed braking.

[Doug Coulter]

Right -- the speeds will just be numbers in the software, and those could even be changed by rs232 from the PC (that's how I plan to do it anyway, the chip has eeprom in it too, to hold them).
The big deal I think is the hardware that assumes a hall input and two motor outputs -- with just that, mine spin up to whatever limit (on the bench, me shutting off the power or current limiting when air drag gets big). Then the uP can just turn things on and off in a bang-bang control loop. I just went shopping for power transformers and got a shock -- expensive. For only a little more, MPJA has full switchers that already have about the right current limit built in....might be the way to go if they don't get too unhappy in current limit. Motor volts won't be real important -- just pick the right supply, and if it's high volts, maybe different fets. So instead of over $20 for a transformer (and then diodes, caps, and a switcher setup) I pay maybe $40 for a supply that already current limits where I want, and I'm done. I like simple things, myself. At that point, the uP only does speed control, which I find essential for some of the medium pressure modes I'm running in -- maybe you too if you're going to do sputtering. It just makes all the gas flow-control issues a ton less difficult (note, I didn't say easier, it's still a challenge sometimes).

Not sure what provision I'll put in for braking. My bigger pumps (that also run slower) take for-fragging-ever to slow down if the vacuum is good, but I vent into the foreline to speed that up when I want into the tank anyway, usually with argon if I'm not going to be in there for long-- speeds up the re-pump time no end to keep most of the dirty wet shop air out of there. If I know I'm going to have the door open for an hour or more, no point -- just let in the air. My Pfeiffer controllers don't seem to do any braking at all, so maybe it's not that important. They work nicely, I'm trying to get (at least) that level of performance, but a couple grand cheaper, is all. I very much dislike their non-backlit LCD and UI in general though. Hope I can do better than that sorry mess.

Though you can't really use it on this pump, I will put in some kind of control output to do the forepump in intermittent mode, as that's really nice when you can use it -- less power and everything lives longer too. I'm thinking of adding a couple channels of my pirani controller to this, so you could have two (not calibrated, gas type sensitive) sensors on there on either side of the pump. For most things, once you find the magic number, you really don't care how that works out in torr or millibars anyway. Just hit the good number again, and your process is repeatable. It might even be cool to set an option where the pump tries to hold a pressure number on one of those? I like that my pirani uses $1 grain of wheat bulbs for sensors...It's no ion gage for real low pressures, but fusor/sputtering is well off the bottom of where they'll read.

I found that if timing accuracy isn't paramount (a couple percent) that I can get away with zero crystals on the PIC (no parts but a bypass cap, at all!) -- it's a couple percent on the built in oscillator, which means if I compute runtime seconds it drifts over long term unless I tune it chip by chip. A watch crystal makes that dead on, but heck, that's another buck's worth of parts, and two I/O pins used up. Haven't decided on that yet. I'll probably make provision on the board (and have already in the code) to do that either way. There will be some a/d inputs left over so I'll add code to scale them by a floating point number in the PIC before sending them out the serial port -- so even a dumb terminal (or emulator) will show meaningful stuff. Probably use 57kbaud for that. We found back in the day that even a 500mhz pentium could not keep up with that, unless you limited it to 16 byte bursts that the hardware in the PC uart could hold, with some delay (10's of milliseconds) between the bursts. Our customer at the time specc'd 19.2kbaud because of that. Today, probably not as much a problem, the pic could go to megabits if we wanted, easily. But most PC's won't do 115kb continuous, yet...sorry that a 8-10 mips machine can outdo a ghz one, eh? But then, I get to write GOOD software for the little guy, and it makes all the difference. Of course, the PC guys claim it's the ancient hardware for 232, but that's pure baloney -- they just want to sell USB (or in other domains, SATA, SCSII, and so forth). The thing is, USB is expensive on a PIC (ethernet more so) but 232 is built-in free.