off the shelf RS485 network card

We have systems where a bunch of microcontrollers (up to 250) need to
communicate with each other in a circular ring.  All controllers need
to see all messages and if there is a single break in the ring, it
needs to continue working and report the fault.  It doesn't need to be
high speed, 200 kbps would probably do.  Are there any RS485 network
cards that can do this and how much do they cost.

TIA

>We have systems where a bunch of microcontrollers (up to 250) need to
>communicate with each other in a circular ring.  All controllers need
>to see all messages and if there is a single break in the ring, it
>needs to continue working and report the fault.  It doesn't need to be
>high speed, 200 kbps would probably do.  Are there any RS485 network
>cards that can do this and how much do they cost.
>
>TIA
>

RS485 (aka EIAA-485) is specified for up to 32 drivers and 32 receivers per
network.

You need a dual contrarotating ring network, rather like FDDI in terms of
topology. Sounds rather fun to specify and design! I would be pleasantly
surprised if there is anything COTS that does the job.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Tue, 12 Oct 2010 05:20:46 -0700 (PDT), Shane williams
<shane.2471958@gmail.com> wrote:

>We have systems where a bunch of microcontrollers (up to 250) need to
>communicate with each other in a circular ring.  All controllers need
>to see all messages and if there is a single break in the ring, it
>needs to continue working and report the fault.  It doesn't need to be
>high speed, 200 kbps would probably do.  Are there any RS485 network
>cards that can do this and how much do they cost.

Network cards implies a bus or backplane. Are you using one or should
these be stand-alone modules?

The RS-485 standard only allows up to 32 drops, IIRC, and doesn't do
particularly well in a ring configuration.

-- 
Rich Webb     Norfolk, VA

On 12/10/2010 15:17, Rich Webb wrote:
> On Tue, 12 Oct 2010 05:20:46 -0700 (PDT), Shane williams
> <shane.2471958@gmail.com>  wrote:
>
>> We have systems where a bunch of microcontrollers (up to 250) need to
>> communicate with each other in a circular ring.  All controllers need
>> to see all messages and if there is a single break in the ring, it
>> needs to continue working and report the fault.  It doesn't need to be
>> high speed, 200 kbps would probably do.  Are there any RS485 network
>> cards that can do this and how much do they cost.
>
> Network cards implies a bus or backplane. Are you using one or should
> these be stand-alone modules?
>
> The RS-485 standard only allows up to 32 drops, IIRC, and doesn't do
> particularly well in a ring configuration.
>

Most buses have trouble in a ring configuration if you are pushing the 
speed/distance barriers, but will work fine if your demands are light. 
For example, RS-485 is ideally wired as a bus with resistor terminators 
at each end.  But for slow rates and short distances, it should work 
fine to connect everything as a ring and have the terminators pretty 
much anywhere (including as larger resistors at each node).

I believe you can get 1/8th load RS-485 drivers, which will then allow 
256 devices on a bus.

A simple ring like this would work and be redundant in the case of a 
breakage, but it would not tell you where the break had occurred (or 
even /if/ a break had occurred.  You could find out about breaks by 
intentionally breaking at another point, and testing how far you can 
communicate in each direction.

Some RS-485 drivers will work reasonably well even if there is a break 
on one of the lines.

There are also CAN drivers that can handle redundant or faulty 
conditions, that might be of interest.

On Tue, 12 Oct 2010 15:48:51 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>There are also CAN drivers that can handle redundant or faulty 
>conditions, that might be of interest.

Good comments on the ring topology. WRT CAN, yes I'd certainly second
the suggestion to the OP to take a look at it. A large number of nodes
and relatively slow data rate sounds like a sensor & control network
where CAN's small packet size would be a good fit (not to mention the
built-in error checking, retransmission, prioritization, etc.).

-- 
Rich Webb     Norfolk, VA

Hi Shane,

Shane williams wrote:
> We have systems where a bunch of microcontrollers (up to 250) need to
> communicate with each other in a circular ring.

Your wording implies a *physical* set of point-to-point links.
This can be accomplished "literally" in that same sense.  E.g.,
much like FDDI.

Does a powered down/defective node count as a "break"?
I.e., can you count on all nodes being "up" at any given time
(two or more being OFF would be an irrecoverable failure)

For example, a pair of RS232 links -- one clockwise and one
counterclockwise -- from each node to its two adjacent neighbors
gives you the physical capabilities you seek (though it forces
each node to participate actively in every message exchange).

You can also implement a Token Ring network (e.g., ArcNet)
in which a "communications device" handles much of the
overhead of moving messages around (years ago, there were
8051-ish solutions with ArcNet controllers).

If you have any need for synchronization between nodes
(e.g., shared timebase), then the easier implementation is
a bus-oriented one.  (Note that the physical topology can
*force* a ring's "problems" onto a bus topology)  This
allows all nodes to see the same data/event COINCIDENTLY.

> All controllers need
> to see all messages and if there is a single break in the ring, it
> needs to continue working and report the fault.  It doesn't need to be

If you need the ring to bretain some integrity in the face
of a break, then you need at least two physical connections
per node.  Note that you need not have both connections *active*
at all times.  Rather, you just need to be able to sense your
"current" connection is defective and "recover" by switching
to your "backup" connection.  (of course, your protocol must
be smart enough that the controls don't start oscillating)
The relative cost of the hardware to do so must be weighed
against recovery time, protocol complexity, etc.

> high speed, 200 kbps would probably do.  Are there any RS485 network
> cards that can do this and how much do they cost.

Have you considered a wireless solution?  (you've not explained
the physical size of the ring but ~250 would probably NOT all
be colocated in a 1 meter segment!  :> )  ZigBee is an
attractive, low power solution in your stated bandwidth.
(you can chose to implement a ring protocol, bus protocol,
mesh, etc.)

On Oct 12, 12:02=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).
>
> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).
>
> If you have any need for synchronization between nodes
> (e.g., shared timebase), then the easier implementation is
> a bus-oriented one. =A0(Note that the physical topology can
> *force* a ring's "problems" onto a bus topology) =A0This
> allows all nodes to see the same data/event COINCIDENTLY.
>
> > All controllers need
> > to see all messages and if there is a single break in the ring, it
> > needs to continue working and report the fault. =A0It doesn't need to b=
e
>
> If you need the ring to bretain some integrity in the face
> of a break, then you need at least two physical connections
> per node. =A0Note that you need not have both connections *active*
> at all times. =A0Rather, you just need to be able to sense your
> "current" connection is defective and "recover" by switching
> to your "backup" connection. =A0(of course, your protocol must
> be smart enough that the controls don't start oscillating)
> The relative cost of the hardware to do so must be weighed
> against recovery time, protocol complexity, etc.
>
> > high speed, 200 kbps would probably do. =A0Are there any RS485 network
> > cards that can do this and how much do they cost.
>
> Have you considered a wireless solution? =A0(you've not explained
> the physical size of the ring but ~250 would probably NOT all
> be colocated in a 1 meter segment! =A0:> ) =A0ZigBee is an
> attractive, low power solution in your stated bandwidth.
> (you can chose to implement a ring protocol, bus protocol,
> mesh, etc.)



I think the winsystems Zigbee bd. uses the Xbee-pro. It has indoor/
urban range listed as 100m.

What interface/connection does the OP's controllers have (usb or PCI
or PC104 or ??)  or is he building an SBC?

On Oct 12, 12:02=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).


We did that a long time ago and put a relay on one of the RS-232 modem
control outputs.  If that wasn't powered, the relay bypassed the node
(can't really take credit for the idea, we were inspired by Token-
Ring, which does something very similar).  Also, you don't really need
pairs of RS-232 links, just a funky cable to connect TX from one node
to the RX of the next node.  A second ring would present opportunities
for redundancy.


> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).


ARCNet is actually token bus, not token ring.  It uses a broadcast
medium with repeaters/hubs.  It manages *access* by bouncing a token
around the network to all the nodes in sequence, only the holder of
the token can transmit, but those transmissions are broadcasts.
Contrast that to a token ring (like 802.5 Token Ring, or FDDI), which
physically transmits messages around a ring of point-to-point links,
with one of those messages being the token that allows transmission.
A token ring actually allows several messages to be circulating on the
ring at once (presuming the bandwidth-delay product of the physical
ring is high enough, of course), which is not possible with a token
bus.  A token ring also has certain electrical advantages from being
composed of point-to-point links.

On Oct 13, 6:02=A0am, D Yuniskis <not.going.to...@seen.com> wrote:
> Hi Shane,
>
> Shane williams wrote:
> > We have systems where a bunch of microcontrollers (up to 250) need to
> > communicate with each other in a circular ring.
>
> Your wording implies a *physical* set of point-to-point links.
> This can be accomplished "literally" in that same sense. =A0E.g.,
> much like FDDI.
>
> Does a powered down/defective node count as a "break"?
> I.e., can you count on all nodes being "up" at any given time
> (two or more being OFF would be an irrecoverable failure)
>
> For example, a pair of RS232 links -- one clockwise and one
> counterclockwise -- from each node to its two adjacent neighbors
> gives you the physical capabilities you seek (though it forces
> each node to participate actively in every message exchange).
>
> You can also implement a Token Ring network (e.g., ArcNet)
> in which a "communications device" handles much of the
> overhead of moving messages around (years ago, there were
> 8051-ish solutions with ArcNet controllers).
>
> If you have any need for synchronization between nodes
> (e.g., shared timebase), then the easier implementation is
> a bus-oriented one. =A0(Note that the physical topology can
> *force* a ring's "problems" onto a bus topology) =A0This
> allows all nodes to see the same data/event COINCIDENTLY.
>
> > All controllers need
> > to see all messages and if there is a single break in the ring, it
> > needs to continue working and report the fault. =A0It doesn't need to b=
e
>
> If you need the ring to bretain some integrity in the face
> of a break, then you need at least two physical connections
> per node. =A0Note that you need not have both connections *active*
> at all times. =A0Rather, you just need to be able to sense your
> "current" connection is defective and "recover" by switching
> to your "backup" connection. =A0(of course, your protocol must
> be smart enough that the controls don't start oscillating)
> The relative cost of the hardware to do so must be weighed
> against recovery time, protocol complexity, etc.
>
> > high speed, 200 kbps would probably do. =A0Are there any RS485 network
> > cards that can do this and how much do they cost.
>
> Have you considered a wireless solution? =A0(you've not explained
> the physical size of the ring but ~250 would probably NOT all
> be colocated in a 1 meter segment! =A0:> ) =A0ZigBee is an
> attractive, low power solution in your stated bandwidth.
> (you can chose to implement a ring protocol, bus protocol,
> mesh, etc.)

Sorry, I guess I didn't ask my question very well.  The distance
between nodes can be several kilometers or just one or two meters.  We
can use fibre for the larger distances.  The network cards need to be
standalone with a connection to the host preferably RS232 but maybe
whatever's available.  The topology is not a bus but more of a daisy
chain.  We were thinking of a scheme where messages propagate in both
directions around the ring, to get the redundancy.  All nodes are
powered up all of the time except when there's a fault/ power fail.

Hi Shane,

Shane williams wrote:
> Sorry, I guess I didn't ask my question very well.  The distance
> between nodes can be several kilometers or just one or two meters.  We

Ouch!  "Important detail", that.  :-/

You've indicated performance criteria. What about cost, size
and reliability?

> can use fibre for the larger distances.  The network cards need to be
> standalone with a connection to the host preferably RS232 but maybe
> whatever's available.  The topology is not a bus but more of a daisy
> chain.  We were thinking of a scheme where messages propagate in both
> directions around the ring, to get the redundancy.  All nodes are
> powered up all of the time except when there's a fault/ power fail.

Without really knowing your application, I would look into
a pair of RS232 interfaces -- one counterclockwise, the other
clockwise -- with an external "media adapter module" that
you "select at deployment".

E.g., if B's clockwise neighbor (C) is a meter away, then B's
"clockwise media adapter module" is populated with something
like an EIA232 translator (perhaps even less depending on
other electrical characteristics).  The same applies to *C's*
"COUNTERclockwise media adapter module".  Similarly, if B's
counterclockwise neighbor (A) is a *mile* away, you could
populate B's "counterclockwise media adapter module" with
something like an RS232-fiber module (long haul modem)
as well as A's "CLOCKwise media adapter module".

[hopefully I've been consistent in my clockwise and counterclockwise
terms in that example  :>  if not, hopefully you can figure out
what I mean with the help of a little sketch with two interfaces
on each node]

This puts each node *in* the message loop physically and
procedurally.  I.e., the message has to pass *through*
each node and be handled by the processor, there.

If you have the budget, add a small MCU for each node that
simply does all of the communications protocol.  E.g.,
something with two UARTs and an SPI interface (which talks
to the "main CPU").  Since you can "nail down" your
protocol, you can test and debug that code and "fix" it
into that "communications processor".

Hint: since you are going to *process* packets (messages)
circulating around the ring, you can modify your protocol
so that you *tag* each packet with the "ring sequential"
ID of its sender (which might be different from it's
*logical* ID).  In that way, a node can "know" that it
is "node X" and, if it can't talk to "node Y" on it's
clockwise link but *can* talk to Y-1, it can deduce that
there is a break between Y and Y-1 (since Y and Y-1 "must"
be "ring adjacent").

[look at the RUPI for some historical context]

You can still look at wireless options but long distance
radio modems get pricey (OTOH, stringing a km of fiber isn't
cheap!)

Also, the synchronization issue gets trickier given this mix
of different interconnect technologies (assuming synchronous
operation *might* be required above syntonous requirements)