On Thu, 12 Nov 2009 18:22:14 -0000, "Rowan Sylvester-Bradley" <rowan@sylvester-bradley.org> wrote:>I have an application that needs to drive lots of solenoids. These are >distributed around a plant - they may be a couple of inches apart, or many >feet apart. Currently the solution is to cable the solenoids individually >back to a control rack via custom made multi-way cable looms where a >microprocessor based system decodes serial commands and energises the >correct solenoids. There can be thousands of solenoids, so this is a very >expensive solution in terms of wiring. Many custom looms need to be made up >and installed. If the configuration changes the looms need to be modified or >re-made. Faults can occur etc. etc. I'm looking for a way in which each >solenoid could be equipped with a decoder/driver which could receive power >and data via a simple bus (I envisage two-wire or three-wire) and could >detect "on" and "off" commands addressed to it and energise or de-energise >the solenoid. The bus and electronics would have to be quite fast, since any >more than about a 2ms delay in turning the solenoid on or off would damage >system performance. The solenoids normally operate from 18V, and require >anywhere from 600mA to 3A to operate. > >Does anyone know of a chip that would do this job? > >Or a mixed logic and power custom or semi-custom chip technology that could >be used? > >Since there will be thousands of these, cost will be an issue. Also since >the solenoids are physically distributed, a single-way solution (with a >separate decoder and single driver for each solenoid) is probably optimum, >since then the electronics could be integrated with the solenoid to give a >fully distributed solution. If this is not possible (or not cost effective) >I could look at a partially distributed soluton in which a "driver box" >could drive 10 or 100 nearby solenoids, but this is less than ideal. > >Thanks for your ideas! RowanYou 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.
Single chip decoder/power-driver
Started by ●November 12, 2009
Reply by ●November 13, 20092009-11-13
Reply by ●November 13, 20092009-11-13
On Fri, 13 Nov 2009 10:44:43 -0500, Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:>On Thu, 12 Nov 2009 18:22:14 -0000, "Rowan Sylvester-Bradley" ><rowan@sylvester-bradley.org> wrote: > >>I have an application that needs to drive lots of solenoids. These are >>distributed around a plant - they may be a couple of inches apart, or many >>feet apart. Currently the solution is to cable the solenoids individually >>back to a control rack via custom made multi-way cable looms where a >>microprocessor based system decodes serial commands and energises the >>correct solenoids. There can be thousands of solenoids, so this is a very >>expensive solution in terms of wiring. Many custom looms need to be made up >>and installed. If the configuration changes the looms need to be modified or >>re-made. Faults can occur etc. etc. I'm looking for a way in which each >>solenoid could be equipped with a decoder/driver which could receive power >>and data via a simple bus (I envisage two-wire or three-wire) and could >>detect "on" and "off" commands addressed to it and energise or de-energise >>the solenoid. The bus and electronics would have to be quite fast, since any >>more than about a 2ms delay in turning the solenoid on or off would damage >>system performance. The solenoids normally operate from 18V, and require >>anywhere from 600mA to 3A to operate. >> >>Does anyone know of a chip that would do this job? >> >>Or a mixed logic and power custom or semi-custom chip technology that could >>be used? >> >>Since there will be thousands of these, cost will be an issue. Also since >>the solenoids are physically distributed, a single-way solution (with a >>separate decoder and single driver for each solenoid) is probably optimum, >>since then the electronics could be integrated with the solenoid to give a >>fully distributed solution. If this is not possible (or not cost effective) >>I could look at a partially distributed soluton in which a "driver box" >>could drive 10 or 100 nearby solenoids, but this is less than ideal. >> >>Thanks for your ideas! Rowan > >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..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.
Reply by ●November 13, 20092009-11-13
Rowan Sylvester-Bradley schrieb:> I have an application that needs to drive lots of solenoids. These are > distributed around a plant - they may be a couple of inches apart, or manyDo 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
Reply by ●November 13, 20092009-11-13
<robertwessel2@yahoo.com> wrote in message news:1e04d4e6-346b-4bea-9982-1d5b0bcee16e@e23g2000yqd.googlegroups.com... << 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 � assuming 12ga power leads, you�d probably be able to drive ten solenoids at the 3A level. CAN would work too, although you�ll have more distance limits. >> 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
