Single chip decoder/power-driver

y

up

or

r e

any

e 2ms is plenty of time for a uC. Any 50 cents uC can drive the solenoid with a 25 cents fet. You can build them for less tha $1 per node, probably cheaper with volume.

Use an RS422 solution and a simple cmd structure.... 16 bit address, + cmdon or cmdoff+crc checksum. Piece of cake..... Or if you can compress the nodes to 256, then 8 bit address You won't get a single chip to do the job... two, maybe three,yes.

For 2 ms timing per solenoid, and "thousands of solenoids", you're talking about at least 1 million commands per second. With 16 bit address, cmd, checksum, that bus needs to be quite fast.

If you choose a micro with built in ethernet, you could do this single chip + power mosfet. Then, assign a private ip address of your own choosing to each node, or even encapsulate your own protocol into the basic frame. That is, just use the hardware capability.

Usb or rs423 multidrop async or synchronous protocol may be a simpler answer. Again single chip + mosfet solution. Don't know enough about usb to say if address range is a limiting factor, but you may be able to fudge this in some way at a lower level in the protocol. That is, it doesn't have to be standard right through the stack.

Basic idea is to design so that you can use cheap commodity hardware and protocols to cut costs and design time...

Regards,

Chris

y

up

or

r e

any

e

ld

, a

e)

I think you=92ll want to try to separate the power and signal lines. You=92re talking about a lot of power, and solenoids are pretty noisy (not to mention the fact that you=92re essentially tying a few dozen big inductors to the line you=92re hoping to signal over).

But a four wire approach, two power and two signal (the former probably being 12 or 14ga), might work. You=92ll need to figure out how you=92re going to do the connections. A daisy chain is appealingly simply, but tends to be fragile. Something with taps is going to either need two connectors, or one very odd one.

You=92ll need to figure out if your code allows you to run the signal wires in the same conduit as the power leads, since you=92re basically going to be having ordinary source wiring for the later.

As for the signaling itself, RS-485 is the one choice, and would allow

31 devices on the bus (plus the controller). That matches your power load fair well =96 assuming 12ga power leads, you=92d probably be able to drive ten solenoids at the 3A level. CAN would work too, although you=92ll have more distance limits.

Toss a simple async protocol on top of that (command from controller, plus acknowledgement, and a minimal checksum), and you should have no real problems hitting you performance targets from the bus controller. The network connecting the bus controllers to whatever central controller you=92re using will be a different issue. The implementation of the solenoid node would need a basic microcontroller with a serial port, a =91485 driver (or the CAN equivalents), and whatever power electronics you need to drive the solenoid (and run the device =96 tapping 5V off the ~20V power leads should be easy).

Distributed intelligent nodes would seem like a nice option here.

I can appreciate where you are coming from here.

I presume you would be running suitable power feed around the site to provide the energy required for each solenoid. I would consider that the feeds could be a nominal line voltage with an individual power supply unit for each node.

You haven't hinted at what Safety Hazards might be involved in your process so any advice you get here is only going to address the control aspects and leave you to address the safety aspects of the project. If ALL SOLENOIDS OFF is a safe state then cutting the power feeds should be incorporated into the Safety Control aspect of the job. That will, however, be for you to consider.

The least expensive options would probably be a cheap micro-controller chip and a discrete power diver stage. As another respondent said, probably almost any of the small, cheap and fast processors would do.

We have no feel for scale of plant dimensions here. However, even on some quite small plant areas the distributed solution is often most effective. Considering the number of nodes you are implying you may wish to consider suitable networking protocols that will ensure the rapid delivery of command messages to the solenoids. When you have done some basic math on the nodes, messages and baud-rates involved you may get better options from here.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

That depends on how often you actually need to change the values - you could send out a thousand slow "prepare to change" commands to the individual nodes, then broadcast a "change now" command to all nodes.

On Nov 13, 7:22=A0am, "Rowan Sylvester-Bradley"

So, where does these 'decoded serial commands' come from, at what speed and in what format ?

If you already have a Serial-to-relay system in a large case, then the smart step is to keep the same serial commands, if possible, but feed them to each solenoid.

Then, questions like these can be looked at...

• read back of status

• Diagnostics

• More precise time-stamp techniques...

2ms sounds ok, until you need LOTS of solenoids inside that time window, and then the bus speeds balloon

What is this controlling ?

-jg

In order to keep the data rate at some reasonable level, send the solenoid setting to multiple solenoids in a single message. Each solenoid driver then picks the correct bit from the message frame. This requires that each solenoid must assign an individual address (e.g. DIP switches).

With standard RS-485 receiver chips 31, solenoids could be controlled on a single bus with 4 byte payload in the message.

With CAN bus 64 solenoids can be controlled with a single message.

Do you need the full 18 V voltage on the solenoid once it has changed state, or could the hold current be maintained with a lower voltage. This may require two control bits for each solenoid.

The question if individual control logic on every solenoid or the use of 8/32/64/256 solenoids on a single controller has a lot to do with the actual power distribution. It is likely that you would have to use some two level power distribution system, i.e. AC mains or 48 VDC to the group controller and the 18 V to the individual solenoids or 20 V to individual solenoid controllers. So why not use group controllers with this division in order to avoid long addresses or long bit masks.

If individual solenoid controllers are used, the address selection is a problem. DIP switches are not too reliable in industrial applications. One way is to use a chip with a globally unique serial number and a method to translate this to a short 3-8 bit address, so that the correct bit from the command frame bit mask can be selected. Of course, this will require two way communication at startup.

Paul

You could do something like DMX512 and send off the state of every solenoid in a continuous loop over a twisted pair at (say) ~10MHz. That would give you a ~210usec update rate for 2000 solenoids. You'd need a microcontroller and a driver for each solenoid,plus a way of setting the address (maybe 12 bits from a DIPswitch).

The main issue with this is fan-out of the data and clock lines.

Oops, didn't mean to hit send.. fan-out of the data out. It would be possible to have a number of drivers, each handling a reasonable fanout (maybe 16 or 32). That would also simplify troubleshooting if there is a cabling issue.

I would strongly suggest considering opto-isolation of the data line using a high speed logic optocoupler or equivalent.

Rowan Sylvester-Bradley schrieb:

Do you have to drive several solenoids at a time, or only one of them?

Probably, it is possible to build a matrix as it is used in LED-Displays. Even if you have to switch several solenoids at the same time, it could be possible to drive the solenoids with small pulses. Second advantage is, you would need much less solenoids.

Eventually, you could combine several matrx, e.g. one 8x8 matrix for 64 solenoids and another 8x8 matrix for the next 64 solenoids...

best regards

Stefan DF9BI

Using the CAN physical layer alone (rather than RS485) can be worthwhile. The MicroChip MCP2551 is a CAN transceiver that's inexpensive, and the advantage over RS485 is that the transceiver will automatically release the bus regardless of what the micro is doing after a certain length of time, so that a single bad solenoid won't clobber the whole system.

The OP didn't specify how important reliability is, but if a (very) occasional lost packet can be tolerated, a broadcast-only protocol (with for example a simple XOR checksum) seems appropriate. In this case, a surprisingly robust receiver can be made using just a FET connected directly to an RS-232 level data line. (For a large system, a low-impedance buffer should be used to drive the line; for small systems, the output of a standard serial port can be used directly.)

I don't know of any single chip solutions, but we're pretty close at this point, especially in terms of cost: an input FET, a driver FET (as suggested by another poster - choose one with a built-in free-wheel diode, or use an external Schottky device), and an 8-pin micro such as one of the PICs with a built in clock. Also needed is a voltage reguator to get from the 18V bus supply (select one of the automotive units, to provide protection from line transients and accidental reverse hook-up), and that's pretty much it. Each micro would need to be individually programmed with its address, or one with more pins could be used to support configuration jumpers.

I definitely agree that separate data and power lines are required; a common ground would be convenient, but it would have to be really beefy - perhaps the mechanical frame itself can be used?

-- Mark Moulding