Transistor to drive solenoid & trigger voltage

I was more thinking that this would obviate any interrupt latency issues, giving you more latitude for using the processor for blinking those lights and playing those ring tones.

Yup. If you leave software in a position to damage hardware, you will, inevitably, have damaged hardware.

I would, conceivably, design a system where the micro could cook something -- but only if I had a _lot_ of confidence that the software quality was going to be _really really high_ on the list of important things to the organization actually doing the maintenance. (Which, I suppose, means I'll never actually do it).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

... It might also reduce the

That was not the kind of damage that I was referring to, because something else will happen long before that. If the pin remains extended, it will drag against the ribbon and paper, which will destroy the pin in short order as the print head is moving quite fast. This reminds me that there are techniques in controlling BLDC motors by monitoring the back EMF. I wonder if it's also possible to use a similar technique to monitor the position of the rod in the solenoid. The inductance of the coil should vary as the rod moves, so a circuit might get the rod going until it has enough momentum to bring it to full extension, then shut off the current, so it will just bounce back upon impact.

I plan to eventually build a controller for the printer mechanism. I want to work out all the details of the software that will control the mech on the PC first, since that will be much easier. Then later I'll port it to a microcontroller. I've never developed anything around a uC before, so this will be my first project, but I have a lot of experience controlling and interfacing external devices at the hardware level from a PC.

Many ways to measure that. The high-tech method would be displacement transducers:

I don't know how your solenoids look but a simple capacitive method might work. One can also monitor the coil current. As the piston flies the inductance changes, which has an impact on coil current.

But if I understand right it could be much simple in your case: The solenoid is most likely run at several times its continuous duty voltage in order to move the piston fast. So what about a simple but fast current sense? If for whatever reason the coil is engaged longer than normal the current would exceed some high threshold -> shutdown ... siren blares ... big red warning light comes on. The simplest way to monitor that would be sense resistors between the sources of your FETs and ground, then comparators hung onto those. You might have to gate out the turn-on spike that happens because Cgs gets charged but only if this has to be super-duper fast, for example if damage can occur within in a couple of microsecond or so.

Momentum should be quite proportional to the power than goes in. All under your control because you have access to current and voltage. If your solenoid/piston combo is always the same you can characterize that and then I don't see a need to even go that far.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I wouldn't be so sure about the "easier" part. I found the timing inaccuracy and sluggishness to be quite frustrating with PCs. Forgot to disengage some TSR program ... phut ... *POOF*

A uC can be magnitudes faster and and predictable.

I'd not wait and go to a uC right away. The design suites for uC are plush and luxurious these days and cost little to nothing. For example, for the MSP430 series from Texas you can spend $20 or less and then you have everything you need. A uC or several of them, a little in-circuit programmer pod, the software, a support forum. Bug in the code? Correct, recompile, load to target, test again.

But you have to make sure you get a uC with enough physical port pins, I never needed many (and I am not really a uC expert). That could cause the test board to cost a little more but it won't break the bank.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

parallel port is piss-easy in linux.

as root:

# rmmod lp # uninstall parellel printer driver # insmod ppdev # install parallel port device driver # adduser WHOEVER parport # add whoever to the group for the parallel port

from then on WHOEVER can access the parallport pins via IOCTL calls.

the parport often already has something like 74HCT behind it, each outpuut pin of mine can source 40mA into a short circuit to ground.

--
?? 100% natural

I would look for driver transistors at the same source that provided the other hardware (I'm guessing you have the whole printer)

IME often ULN7003 are used to drive the pins

50uS is not considered fast by most, and I'm fairly sure the pins are slower than that.

--
?? 100% natural

x put

ould

too

.

er

I l d

I'm not sure thats a long way off actually. They basically rely on using only brief pulses to fire the hammers, plus the fact that the typical printed page has maybe 5% ink cover, plus intermittent use, plus a moving air cooled heatsink. DMs overheat readily.

NT

Though I've been caught in the past by assuming that 5uS (albeit 10 times less) is a sufficiently long time that I could ignore the time it takes for a transistor to come out of saturation. Using a darlington pair presumably just makes the situation worse.

Sylvia.

An HCT244 is good for 35mA *absolute maximum* on a pin, 70mA per package. Recommended is only 6mA per pin, to meet .4V LNDL/LPUL.

The company where I sit still has a dot-matrix printer; they use it for making stencils for the electroetch machine.

Cheers! Rich

Here's a 1995 application note on a circuit for that:

John Nagle