Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30405
| 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> |
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
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