Single chip decoder/power-driver
Rowan Sylvester-Bradley
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
linnix
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.
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.
TTman
"Rowan Sylvester-Bradley" <ro...@sylvester-bradley.org> wrote in message
news:Kj_Km.14201$Zu5....@newsfe24.iad...
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.
Arlet
>>> 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
>>
> 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.
ChrisQ
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
robert...@yahoo.com
I think you’ll want to try to separate the power and signal lines.
You’re talking about a lot of power, and solenoids are pretty noisy
(not to mention the fact that you’re essentially tying a few dozen big
inductors to the line you’re hoping to signal over).
But a four wire approach, two power and two signal (the former
probably being 12 or 14ga), might work. You’ll need to figure out how
you’re 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’ll need to figure out if your code allows you to run the signal
wires in the same conduit as the power leads, since you’re 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 – 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.
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’re using will be a different issue. The
implementation of the solenoid node would need a basic microcontroller
with a serial port, a ‘485 driver (or the CAN equivalents), and
whatever power electronics you need to drive the solenoid (and run the
device – tapping 5V off the ~20V power leads should be easy).
Paul E Bennett
> 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.
Distributed intelligent nodes would seem like a nice option here.
> 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 can appreciate where you are coming from here.
> 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.
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.
> 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?
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.
> 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.
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.
> Thanks for your ideas! Rowan
--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
David Brown
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.
-jg
> 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, 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
Paul Keinanen
wrote:
>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.
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
Spehro Pefhany
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.
Spehro Pefhany
>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.
Stefan
> 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
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
Mark Moulding
<robert...@yahoo.com> wrote in message
news:1e04d4e6-346b-4bea...@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