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.
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.
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.
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...