<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 &#4294967295; assuming 12ga power leads, you&#4294967295;d probably be able to
drive ten solenoids at the 3A level.  CAN would work too, although
you&#4294967295;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

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

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. 

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 of the data and clock lines. 

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

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

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.

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

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