Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30405

Re: Multi-master RS485

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: Multi-master RS485
Date 2021-03-31 14:49 +0200
Organization A noiseless patient Spider
Message-ID <s41r5n$ulo$1@dont-email.me> (permalink)
References (1 earlier) <s3l03h$gob$1@z-news.wcss.wroc.pl> <s3ofjd$4tv$1@dont-email.me> <s40925$83t$1@dont-email.me> <s41big$d9v$1@dont-email.me> <2eo86gpm6rhkc58rl5iebc69gg8638dl8p@4ax.com>

Show all headers | View raw


On 31/03/2021 14:29, upsidedown@downunder.com wrote:
> On Wed, 31 Mar 2021 10:23:43 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 31/03/2021 00:34, pozz wrote:
> 
>  
>>> After first connection the master sends many configuration data to
>>> slaves (around 2-4kB), so CAN bus is not ideal because of its small
>>> packets (however I can split data on different packets).
>>> Then the bus stays idle for most of the time. The user could interact
>>> with a slave and only in that case the slave has something to tell to
>>> the master.
>>
>> CAN is a short-range protocol.  If your bus is over about 20-30 m,
>> forget CAN.  (People do use it for longer distances, at low speeds, but
>> it's horrible for the task.  
> 
> If you try to run CAN at 1 Mbit/s it is quite critical with limited
> distance and strict rules how long branches you can connect from the
> main bus. Ideally the main bus should be routed through all nodes
> without branch cables.

Yes.

You can be a little loser if you can impose some rules on the messages
you send (like avoiding collisions).

> 
> At 250 kbits/s you can still run about 250 m and the branch lengths
> are not that critical. Should be sufficient for home automation,

I wouldn't want to rely on CAN for anything like that distance/speed
combination - my experience is not as good.  However, there are all
kinds of details involved such as the type of cable, grounding, driver
power, EMC protection, etc.

> 
>> And CANOpen and other "standards" look like
>> they were designed specifically to be as complex and inefficient as
>> possible.)  
> 
> CanOpen is great for setting up the system with EDS (Electronic Data
> Sheet) or inquiring the node capabilities with SDOs request messages.
> 
> For real-time communication the PDOs are mapped directly to real-time
> CAN-frames, so no performance issues.
> 
>> For a short range, small message bus on a closed network
>> entirely under your control, CAN is great.
> 
> I  assumed that the OP is designing both the master and slaves.
> 
>>> Yes, you are right when you say that putting a known limit on the worst
>>> case can be done with a polling approach. However my goal is not limit
>>> the worst case, but minimizing the "normal"/mean delay in the
>>> slave->master->slave transaction.
>>> I know this mean of delays can be reduced a lot, because the bus is idle
>>> most of the time, so the probability of a conflict is very very low.
>>>
>>> Even number of slaves was just an example. I can think of systems with
>>> 50 or 100 slaves and in those cases the polling approach performance
>>> would be very bad.
>>>
>>
>> You should try to think about having multiple bus segments with fewer
>> nodes per segment, and some sort of aggregator or gateway that combines
>> them.
> 
> I have designed both CAN as well as RS-485 networks with 60 - 100
> nodes and in practice, most problems were related to the electro-
> mechanical reliability of the cabling harnesses.
> 
> For this reason, it is a good idea to split the network  into multiple
> segments, each with own independent master.
> 

Agreed.

> If the master doesn't have sufficient number of serial ports one
> solution is to connecting multiple Ethenet/RS-485 or Ethernel/CANbus
> converters with ordinary Ethernet cabling and Ethernet switches. This
> may also simplify RS-485 or CAN cable length issues by inserting the
> converters closer to the nodes,
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:27 +0100
  Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:33 -0700
    Re: Multi-master RS485 Grant Edwards <invalid@invalid.invalid> - 2021-03-25 16:38 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:57 -0700
      Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-25 20:28 +0100
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:57 +0100
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 10:04 -0700
  Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-25 19:02 +0200
  Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-26 15:54 +0000
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-28 00:37 +0100
      Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-27 20:14 -0400
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 07:32 +0300
          Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 07:20 -0400
            Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 14:59 +0300
              Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 08:09 -0400
      Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-28 02:01 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-27 19:57 -0700
      Re: Multi-master RS485 Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-03-28 15:52 +0200
        Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 13:06 -0400
      Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 00:34 +0200
        Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-30 18:51 -0700
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 06:42 +0300
          Re: Multi-master RS485 Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2021-03-31 09:50 +0200
        Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 10:23 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 12:27 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:43 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 13:39 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:46 +0200
            Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-31 06:20 -0700
          Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 15:29 +0300
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:49 +0200

csiph-web