Transistor to drive solenoid & trigger voltage

Depends. I've gotten rods to do peg-to-peg travel in hundreds of usec and we could have done the high tens. But not single digit usec or stuff would have arced over. It's all a matter of voltage, both during pull-in and release. Lots and lots of volts. The electronics gets to be quite a bit more complicated than a simple driver and a FET.

One thing I learned early on: When you let metal fly that fast it's LOUD when it hits the peg :-)

A number of dot matrix printer manufacturers make serial matrix printers capable of running at up to around 1000cps, and there are shuttle matrix line printers made that run upwards of 1500 lpm, so they are getting some really fast solenoid action. I won't know how long the pulse needs to be until I experiment. The datasheet for the ULN2003 says max. turn-on/turn-off time is 1us, typ. 0.25us. Is that too slow?

That's the prop delay. The ULN2003 needs a pull-up resistor at the output and that combined with Cgs (and Cgd via Miller) of the FET determines how fast the current engages. You need a "real" FET driver, like in the example I suggested.

Are you suggesting using the FET driver instead of the darlington array and FET combination and drive the solenoids with it or substitute the FET driver for the darlington array and drive the FETs with it? I based the idea of using the darlington array on the circuit diagrams available on the net showing using it to drive stepper motors from the parallel port (but they drive the small motor directly). Are there examples of using a FET driver in a similar situation somewhere? I'm not sure how to use this device properly.

"bit-banging out of parallel ports pretty much went out with DOS."

I didn't know that, what about if you run a DOS shell? (The only interface I ever made was between a Nicolet transient recorder and original PC through the parallel port, back when the PC was hot stuff and cost $3k+ or something like that.)

Sigh, I really miss DOS, I felt I understood what was going on, and was in control.

George H.

Bit banging of the parallel port could be done in any version of Windows up to XP. You will need to install a driver like DLLPORTIO, and then access any port directly. Unfortunately this simple approach won't work for Vista or W7.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

x put

ould

too

How 'bout the LM395, spendy, but for the money you get a 'bullet proof' power Darlington.

George H. '

d text -

Download this utility, it opens access to the printer port(and others) under xp(test, not sure for vista/win7).

Use the FET drivers to drive the FETs. There are some drivers that can swing an amp directly but if the solenoid is driven at higher duty cycle they'll become hot. Because their internal Rdson is still a few Ohms. A FET would be tens of milli-Ohms.

Not aware of examples but there's really only two parts involved: The driver, and then the FET with its gate connected to one output of the driver. That's pretty much it. Well, plus the usual bypass caps and the flyback diodes for the solenoid side which you'll need in either case.

I'd use a avalanche rated or clamped fet and no flyback diode, a simple diode for flyback will make the solenoid release slow.

and since it'll be driving a solenoid that'll limit how fast the current will rise anyway I doubt there's any need for super fast multi ampere gate drive.

-Lasse

Depends on what those cost. I usually try to stay with cheap catalog FETs. Especially these days when even Havarti cheese can go on allocation :-)

How would avalanche or clamp limit that during turn-on?

If Eric wants clean rapid-fire pulse in the usec range without anything becoming hot there is a need for a nice gate driver. 1-2A is ok though.

Come to think of it, if Eric wants clean and accurately timed rapid-fire pulses in the usec range _from a PC_, just running DOS may not be enough

-- I'd at least investigate driving each FET through a one-shot multivibrator, so that all the software needs to do is pull a line high, then low again when it gets around to it.

Even on a dedicated, stripped-down, bare-metal embedded processor, when you start talking about pulses that need to be accurate to tens of microseconds, I'll start talking about doing the timing in hardware.

Agree. I was wondering about how he gets a PC to do usecs via LPT. However, DOS and direct HW write are powerful tools. I used that in the olden days to do extremely fast stuff on graphics cards. But it was also possible to fry a graphics adapter that way.

r,

le

you cut the setence in half.

I'd use a clamped fet to let the flyback go to something like 2xVcc to get the fast turn-off

the gate drive thought of as: if it takes usec for the solenoid current to rise it wouldn't big so big of an issue that it takes usec for the fet Ron to go down.

and getting a solenoid to move in usecs ? that's mega G's for a millimeter of movement

-Lasse

Usually solenoids like that are already being driven at several times continuous voltage capability. So you want to transit as fast as possible. Just take a look at the pull-up resistor you need even for a usec, to swing a gate of, say, 2-3000pF. A few hundred Ohms. Tsssss ... hot, hot.

Sometimes the distance is much less than a millimeter. But yeah, I've moved plungers at multiple G's. First time I tried it out ... *BAM* ... and my ear drums hurt. Sounded like someone fired a rifle right next to me. Ok, this was at over 10x rated voltage and turn off was even more.

Say, now there's an idea. A monostable multivibrator should work if I can adjust the pulse width very precisely. That would significantly reduce signal frequency required on the port, as well as eliminate some very critical timing from the PC side. It might also reduce the chance of a printhead solenoid being left on too long (which would cause severe damage to the printer). Although DOS is the host OS, my program will bypass the OS and even the BIOS as well and control the hardware directly. Now some research on FET drivers and multivibrators is in order.

Drivers? You can get those by the baker's dozen. Micrel, Microchip, National, and so on.

Gets expensive if you want to see some accuracy specs there:

I like Tim's idea with the uC. Run it at the highest possible clock frequency. A complete 8-bit port is set up to generate an interrupt. The instant one or several bits on that go high the uC registers an interrupt, salutes, starts a timer, sets a corresponding set of 8 bits on another port accordingly but only as long as the timer is programmed to run. Then it sets them all low again, salutes, waits until next such event. Cheap and quite precise. The only parameter that would jitter should be the time between received command and action because the uC clock is not synchronous to anything in the PC, and typically it is less than 20MHz. Although you can get 8051 varieties that can be operated at

Depending on the extent and $-number behind such damage you might want to think about a HW-lock. Current sense plus low-pass. If any solenoid draws more than xxx mA over a period of xxx millisecond have it automatically shut down the driver, or better yet, the supply rail to the solenoid area.

Little micros with PLLs and clocks up to 50MHz are getting commoner and commoner. I'd go with the regular printer handshaking if I were going to do what you suggest -- look for a 'ready' from the PC, read the 8-bit port, and toggle the 'acknowledge'. Then on the other side do what you're suggesting: write to the port, wait a bit, then write all zeros (or all ones, as is convenient to the drivers).

You're basically using the micro as a PAL, but it may be easier to do than using a PAL.

I think I wouldn't even make this interrupt driven: let the micro spin on the 'ready' signal from the PC until it's valid, then it writes and spins on the timer popping off, then it acknowledges and the cycle starts again. The nice thing about doing it this way is that you can then make the thing completely deterministic if it's not pipelined.

Another way to do this that would allow more latitude in the software design (and more of a growth path) would be to come off the micro with the same 8 bits (or straight off the printer port), but apply them to a bank of AND gates or to some tri-state latches with low enough valued pull-down (or pull-up) resistors to get a good fast response. Then enable the latch from a timer-out pin on the micro. This puts all the really critical timing in the hands of hardware, and lets the micro off the hook -- thereby letting it be fancier if you want it to be.