Single chip decoder/power-driver

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

On Nov 12, 10:22=A0am, "Rowan Sylvester-Bradley" <ro...@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 man=
y
> 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 powe=
r
> 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-energis=
e
> 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 damag=
e
> 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.

"Rowan Sylvester-Bradley" <rowan@sylvester-bradley.org> wrote in message 
news:Kj_Km.14201$Zu5.1370@newsfe24.iad...
>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
>
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. 

On Thu, 12 Nov 2009 22:15:44 +0000, TTman wrote:

>>> 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.

Rowan Sylvester-Bradley 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
> 

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

On Nov 12, 12:22=A0pm, "Rowan Sylvester-Bradley" <ro...@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 man=
y
> 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 powe=
r
> 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-energis=
e
> 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 damag=
e
> 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 cou=
ld
> 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 effectiv=
e)
> 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.



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).

Rowan Sylvester-Bradley 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.

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.Bennett@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..
********************************************************************

Arlet wrote:
> On Thu, 12 Nov 2009 22:15:44 +0000, TTman wrote:
> 
>>>> 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.
> 

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"
> 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

On Thu, 12 Nov 2009 22:15:44 -0000, "TTman" <someone.pc@ntlworld.com>
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