Moderne Bustechnologie gesucht

CAN kann das, wenn man mit mittleren Datenraten arbeitet.

Klingt definitiv nach CAN. Etwas einfacher wäre ggf. MODBUS (RS485), 
wobei das auch nicht "modern" ist, dafür robust.

Sehr speziell würde dann ggf. noch IO-Link gehen, aber das würde einen 
sehr großen Rattenschwanz mit sich ziehen

Jazeel Jeybalan schrieb:
> Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne
> Slaves an, sondern die Slaves senden einfach Ihr Datenpaket.

Das ist sehr ungünstig. Was ist der Hintergrund für diese Anforderung?

Jazeel Jeybalan schrieb:
> Das
> zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen

Wie wird dieser Ausschluß denn realisiert?

Wenn man 30 Geräte mit der selben Firmware zur gleichen Zeit 
einschaltet, werden die auch gerne zur gleichen Zeit das gleiche machen 
wollen.

Würde auch sagen, dass RS485 für die Lösung als passabel erscheint.

Jazeel Jeybalan schrieb:
> Der Master fragt nicht einzelne
> Slaves an, sondern die Slaves senden einfach Ihr Datenpaket.

Dann ist CAN das Mittel der Wahl.

RS-485 ist ungeeignet, da der Master die Slaves erst zum Senden 
adressieren muß. RS-485 kann keine Kollisionen erkennen oder auflösen.

Jazeel Jeybalan schrieb:
> - Die Datenrate ist extrem wechselnd, für einen Moment müssen 32 BYTE
> versendet werden, dann ist aber in der Regel wieder für >1h ruhe. Das
> zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen
Du verlässt dich auf dein Gefühl, und das trügt dich:
https://de.wikipedia.org/wiki/Geburtstagsparadoxon

In der Praxis bedeutet das, dass du (gefühlt) laufend mit solchen 
Kollisionen zu tun hast. Und blöderweise kann es dann sein, dass "wenn 
sich zwei gefunden haben" mehrere Stunden lang die Telegramme zweier 
Slaves kollidieren. Du solltest dir also eine Strategie zur 
Kollisionsauflösung ausdenken.

> (keine Spezialkabel wie z.b. LVDS)
Wie kommst du bei LVDS auf "Spezialkabel"? Gerade LVDS (oder z.B. 
Derivate wie CAN, RS485) kommt wegen der differentiellen Übertragung mit 
simpler verdrillter Klingellitze aus...

Peter D. schrieb:
> RS-485 ist ungeeignet, da der Master die Slaves erst zum Senden
> adressieren muß. RS-485 kann keine Kollisionen erkennen oder auflösen.

Sicher. Aber wenn man die kaputte Designentscheidung (Slaves senden 
unaufgefordert) weglässt und stattdessen ein sinnvolles 
Master-Slave-Konzept verwendet, funktioniert RS485 auch. Und RS485 kann 
man mit deutlich geringeren Datenraten betreiben als CAN, was die 
Angelegenheit robuster und vor allem deutlich toleranter bei der 
Verkabelung macht.

Der schon angesprochene Modbus arbeitet üblicherweise mit 9600 Baud.

Jazeel Jeybalan schrieb:
> - Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne
> Slaves an, sondern die Slaves senden einfach Ihr Datenpaket.

und

Jazeel Jeybalan schrieb:
> - Der Bus darf nicht Hardwareadressiert, oder "geschlauft"

und

Jazeel Jeybalan schrieb:
> - Im Idealfall ist der Bus so aufgebaut, das einzelne Slaves einfach
> entfernt oder zugeschaltet werden können, ohne das der Master etwas
> machen muss.

klingt nach einer unmöglichen Anforderung und einem Alptraum für den 
Betrieb/Debugging.
Was sind das für Slaves? Einfache Sensorknoten? Müssen die Slaves im 
Betrieb hinzufügbar sein?
…

Plug and Play ohne Adressierung beim Slave wird wohl eher in die 
Richtung TCP/IP mit DHCP Server (würde von der Topologie und den Längen 
auch passen) oder USB gehen. Oder du baust dir selber ein Protokoll auf, 
dass beim Hochfahren des Busses zuerst alle Slaves durchgeht und denen 
eine definierte Adresse vergibt. Einfach sendende Slaves finde ich 
extrem unpraktisch, ausser du hast mehrere Master.

Aber um eine sehr intelligente Software wirst du nicht herumkommen.

temp schrieb:
> Am AVR
> hingen einfach Transistoren die als Open-Kollektor auf einen gemeinsamen
> Widerstand arbeiten. Den kann man dann ausreichend niederohmig machen.

Wenn man dann noch das Datensignal auf einen Pin des MC zurückführt, 
wäre sogar eine einfache Kollisionserkennung möglich, ähnlich wie bei 
I²C. Wenn das Signal low ist, obwohl ich 'high' sage, muss ein anderer 
gerade den Draht besetzen.

Rufus Τ. F. schrieb:
> Und RS485 kann
> man mit deutlich geringeren Datenraten betreiben als CAN

CAN kann man auch mit niedrigen Datenraten betreiben und kommt dann 
kilometerweit oder kann viele lange Stichleitungen machen, das ist also 
kein Argument.

Rufus Τ. F. schrieb:
> Sicher. Aber wenn man die kaputte Designentscheidung (Slaves senden
> unaufgefordert) weglässt

Das ist per se keine kaputte Designentscheidung, das kann zum Beispiel 
so gewollt sein weil es in der konkreten Anwendung mehr Sinn ergibt und 
weniger Buslast erzeugt und geringere Lazenzen als wenn der Master 
ständig mit Vollgas reihum zwölfunddreißig Slaves pollen muß die 
allesamt 99.999% der Zeit nichts neues zu vermelden haben.

Oder willst Du etwa auch Ethernet oder CAN als "kaputt by Design" 
bezeichnen?

Jazeel Jeybalan schrieb:
> Entweder muss vom Master je ein Kabel zu
> einem Slave gelegt werden, oder es wird ein "Hauptstrang" verlegt an
> welchen die Slaves über kurze sogenannte Stubs angeschlossen wird.
>....
> - Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen
> Stub-Abgänge jeweils 2m. Pro Strang sollten ca. 20-30 Slaves anhängbar
> sein

Am besten geht das wohl mit slew rate limited RS485 Treibern ohne 
Abschlußwiderstände. Wobei du das schon angesprochene Kollisionsszenario 
welches dir garantiert irgendwann mal Probleme machen wird, durch ein 
richtiges Master/Slave Konzept in den Griff kriegen solltest.

Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. 
Weiters hast du bei so einem Aufbau das Problem, dass es keine optimalen 
Positionen für die zwingend notwendigen Abschlußwiderstände gibt. Dafür 
könntest das Kollisionsszenario elegant und einfach in SW lösen. Ich 
würde bei so einem Aufbau mit CAN statt der üblichen 2 
Abschlußwiderständen nur einen beim Master einbauen und relativ 
hochohmige bei jedem Slave UND externe RC bei den Treibern dazubauen um 
die slew rate zu begrenzen. Oder einen nicht so modernen/billigen CAN 
Treiber nehmen bei dem man noch die slew rate einstellen kann. Mit 
Standard CAN hat das aber nicht mehr viel zu tun außer dem billigen und 
robusten Treiber IC.

Darüber würd ich ein Standard UART Protokoll empfehlen. Außer du hast eh 
so einen "teuren" Mikrcontroller der CAN Behandlung in HW drinnen hat.

Jazeel Jeybalan schrieb:
> Der Fall ist übrigens fast nicht möglich.

D.h. er ist nicht ausgeschlossen. So wie der 49,7 Tage-Bug:
https://www.cnet.com/news/windows-may-crash-after-49-7-days/

Bei CAN gibt es damit keinerlei Probleme. Der unterlegene Sender wartet, 
bis der andere fertig ist und sendet nochmal, ganz ohne jeden 
Softwareoverhead.

Bei RS-485 braucht man eine zusätzliche Software, die eine 
Fehlererkennung und Retry ausführt. Ansonsten sind beide Datensätze 
korrupt.

In Zeiten von IoT wäre das doch ohne Kabel direkt über z.B WLAN 
NodeMCU's .. und nem Server zu realisieren. MQTT oder ähnliches.

Ethernet DHCP ..

A ist das modern GRINS
B es funktioniert
C es gibt schon einiges fix und fertig.

Mir scheint, die theoretisch möglichen Kollisionen werden hier etwas 
überbewertet. Viel spannender finde ich den Batteriebetrieb:

Jazeel Jeybalan schrieb:
> Die Slaves befinden sich beim Status "unused" im Schlafmodus (1uA),
> werden sie von einem Bediener verwendet wechseln sie im "Startup" auf
> kurzzeitig mehrer mA und dann in den Satus "used"  (40uA). Beim
> "Shutdown" wechseln sie von 40uA auf (1uA).

Um in die Nähe von 1uA zu kommen, muss man im Shutdown die 
Stromversorgung der Bus-Transceiver abschalten, auch ICs mit 
Disable-Eingang werden nicht so sparsam. Nur gut, dass die Slaves nichts 
empfangen sollen...

Der Master muss natürlich immer empfangsbereit sein, damit wird der 
Stromverbrauch vom Bus-Empfänger bestimmt. Ein normaler Transceiver 
kommt also garnicht in Frage. Ein einzelner RS485-Empfänger ist besser, 
aber der sparsamste, den ich kenne (ISL32612E), braucht auch noch 
135uA(max). Ein sparsamer Transceiver (ISL3172E) braucht 700uA bzw. 
800uA beim Senden. Für die Slaves wäre der allerdings gut. Gibt es 
eigentlich ähnlich sparsame CAN-Transceiver?

Insofern ist ein "moderner Bus" nicht die erste Wahl. Bei 22m Kabel, 
minimaler Datenrate und Batteriebetrieb ist die differentielle 
Übertragung evt. auch übertrieben. Wenn die Slaves potentialfrei sind, 
ist eine Datenader plus Masse quasi auch differentiell. Dafür müsste der 
Master-Empfänger keine besondere Gleichtaktunterdrückung können.

temp schrieb:
> Am AVR
> hingen einfach Transistoren die als Open-Kollektor auf einen gemeinsamen
> Widerstand arbeiten. Den kann man dann ausreichend niederohmig machen.

Damit hat man sowas wie einen Stromschleifen-Bus. Mit Stromschleifen hat 
man früher Kilometer überbrückt. In den uCs benutzt man UARTs, z.B. mit 
9600 Baud. Das Beste: der Ruhestrom ist auf beiden Seiten Null (na gut, 
Leckströme).

Solange der Master nicht senden muss, könnte über eine Datenader plus 
Masse könnte sogar die Stromversorgung der Slaves laufen. Der 
Master-Empfänger müsste nur eine Schaltschwelle bei einem bestimmten 
Strom haben.

Erik schrieb:
> Andi B. schrieb:
>> Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten.
>
> Zeig mir einen.

TJA1057

Hallo,
> Jazeel Jeybalan schrieb:
> Ich suche nach einer Modernen Bustechnologie (zeitgemäss)
ich denke, deine Aufgabenstellung hat gar nichts mit "modern" oder alt 
zu tun, sondern vielmehr damit, sehr spezielle Anforderungen zu 
erfüllen.

> Ein Gerät (Betriebsspannung 3.3V, LIPO Akku) soll mit einer
> Bustechnologie vernetzt werden, aufgrund der Baulage kommt nur eine
> "Sternverkabelung" in Frage. Entweder muss vom Master je ein Kabel zu
> einem Slave gelegt werden, oder es wird ein "Hauptstrang" verlegt an
> welchen die Slaves über kurze sogenannte Stubs angeschlossen wird.
Da fehlen zunächst konkrete Werte zu Datenmengen und Datenraten.
Weiter unten schreibst du aber, dass nur wenige Bytes in eher sehr 
großen Abständen (Minuten bis Stunden) übertragen werden sollen.
Dazu kommt, dass der BUS nur paar 10m lang sein soll.

Ich nehme auch an, dass der Betrieb in nicht stark störbehafteter 
Umgebung erfolgt und nach der Beschreibung ist hohe Zuverlässigkeit eh 
kein kritisches Thema, oder?

> Ebenfalls ist es in Planung die Geräte per Kabel (optional) mit Strom zu
> versorgen (Die Versorgungspannung sollte im Bereich 5-12V liegen, und
> wird dann per SMPS auf 3.3V gewandelt werden und dient als Akku
> alternative). Somit kann auch eine Bustechnologie in Frage kommen welche
> gleich Spannung mitliefert.
Bei deinen Anforderungen sind die Anforderungen einerseits sehr viel 
einfacher, als übliche Bus-Systeme leisten müssen. Dafür ist das Thema 
Strombedarf primär wichtig.
Der Physical Layer kann also sehr viel einfacher gestaltet werden, als
es bei üblichen Bus-Systemen sonst üblich ist.
Ich empfehle dir einen einfachen Bus mit Übertragung von 
Spannungspegeln.
Das kann bei den geringen Anforderungen auch mit TTL-Pegeln (5V oder 
auch 3,3V) erfolgen.
Die Verwendung von leistungsfähigen Bus-Tranceivern ist da gar nicht 
nötig und passt auch nicht so gut zum Thema "Strom sparen" wegen 
Akkubetrieb.

> Folgende weitere Details kann ich zu der Sachlage liefern:
> - Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne
> Slaves an, sondern die Slaves senden einfach Ihr Datenpaket.
Bei den gegenene Bedingungen würde das wohl schon ohne spezielle 
Maßnahmen zu fast 100% funktionieren. Die Zuverlässigkeit könnte man 
durch eine wiederholte Übertragung (2...3 mal) mit zufällig gewählten 
Zeitabständen im Sekundenbereich verbessern.

Mit dem Prinzip der Busarbitrierung bei CAN sind aber auch 
Datenkonflikte zu vermeidbar. Allerdings bedingt das ja auch schon, dass 
die Busteilnehmer auch empfangen können. In dem Fall kann man aber auch 
Datenkonflikte durch das Protokoll abfangen und bei Bedarf eine 
Wiederholung anfordern.
Bei Trennung von Sende- und Empfangsleitungen (mind. 3 Drähte) wäre ein 
Request von der MCU zu den Sensoren aber auch kein Thema.

> Für zukünftige Anwendungen wäre es ein Bonus wen die Bustechnologie
> auch zweiweg Kommunikation unterstützt
Ja wo ist das Problem. Mithören am Bus geht mit minimalem Aufwand auch 
sehr stromsparend. Zum Senden von TTL-Pegel gibt es Treiber mit 
Tri-State-Ausgängen. In CMOS-Technologie brauchen die nur paar uA 
Ruhestrom.

> - Der Bus darf nicht Hardwareadressiert, oder "geschlauft"
Wenn es bidirektional werden soll, wäre es aber schon irgendwie 
notwendig, entweder die BUS-Teilnehmer zu addressieren oder wie bei CAN 
die Nachrichten mit Identifiern zu kennzeichnen.
Bei einem Bus mit Rückleitungen (3-Draht) wäre auch die einfache 
Quitierung innerhalb einer def. Zeit vorteilhaft.

> - Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen
> Stub-Abgänge jeweils 2m. Pro Strang sollten ca. 20-30 Slaves anhängbar
> sein
Physikalisch sind das sehr einfache und günstige Bedingungen.
Ich empfehle eine niedrige Baudrate (z.B. 1200 Baud oder weniger) mit 
deutlich Bandbreite begrenten Signalen (Tiefpass). Damit sind jegliche 
HF-Effekte raus und der Bus muß nicht terminiert werden (geringer 
Leitungsbedarf).  Auf dem Bus kann mit recht hochohmigen Pull-Down-R ein 
Ruhepegel definiert werden.

> - Die Datenrate ist extrem wechselnd, für einen Moment müssen 32 BYTE
> versendet werden, dann ist aber in der Regel wieder für >1h ruhe.
Das ist nicht die "Datenrate", sondern eher das Datenaufkommen.

> Das zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen
Du mußt wissen ob der seltenen Fall von Datenkonflikten akzeptiert 
werden kann.

> - Im Idealfall ist der Bus so aufgebaut, das einzelne Slaves einfach
> entfernt oder zugeschaltet werden können, ohne das der Master etwas
> machen muss.
Wenn die eh passiv sind, gibt es auch keine Probleme damit, sofern du 
keine solchen Mechanismen im Protokoll anforderst.

> - Der Bus sollte einen alltagstauglichen Aufbau haben (keine
> Spezialkabel wie z.b. LVDS)
Im einfachten Fall reicht einfacher Klingeldraht. Wenn dieser verdrillt 
ist (TP - twistetd pairs), ist es umso besser. Einfache TP-Signalkabel 
mit Schirmung verbessern die Störmepfindlichkeit nochmal deutlich, 
sofern der Schirm korrekt auf Erde gelegt werden kann.

> - Je weniger externe Hardware nötig, je besser. Im Idealfall kann der
> Bus direkt an einen MCU angebunden werden.
Kann man machen. Allerding sollten uC-Ports besser mit einem 
Leitungstreiber entkoppelt werden. Schutzbeschaltungen sind auf alle 
Fälle zu empfehlen (siehe unten).

> Ich hoffe genügend Daten geliefert zu haben, und hoffe nun auf einige
> Ratschläge welche Bustechnologie eingesetzt werden kann
Es gibt trotz der sehr einfachen Möglichkeiten zu beachten, dass 
Überspannungsschutz (z.B. durch Blitzschlag bei Gewitter) in 
ausreichendem Maße realisiert ist.
Das ist aber wegen der niedrigen Baudrate leicht mit Suppressordioden zu 
bewerkstelligen. Eingänge können eh recht hochohmig gemacht werden.
Die empfohlenen Leitungen mit Verdrillung und Schirm sind diesbezüglich 
auch vorteilhaft.
Gruß Öletronika

Jazeel Jeybalan: Du willst kein (Single-Master/Multi-Slave)-Netzwerk 
sondern ein (Multi-Master/Single-Slave)-Netzwerk. Dieses Wissen könnte 
dir helfen bei der Recherche im Internet. Master = Netzwekteilnehmer, 
der eine Kommunikation "lostritt" (salopp gesagt). Dein "Master" hört ja 
nur zu und ist somit eigentlich ein Slave und deine "Slaves" sind 
eigentlich Masters.

Wenn es einfach sein muss, dann schau dir die Hardware vom LIN-Bus an, 
da geht nix kaputt, wenn mal 2 gleichzeitig senden. Ich verwende es in 
meiner Aquariensteuerung mit diversen Slaves, jedoch habe ich mein 
eigenes Protokoll geschrieben, dass mehr Payload hat (auch habe ich die 
LIN-Treiber einfach selbst gemacht aus zwei LocigLevel-N-MOSFETs + TVS). 
Du brauchst dafür drei Drähte (12V-Versorgung, GND, LIN-Leitung) und gut 
ist. Wenn du Unterlagen brauchst oder Schaltungsbeispiele, dann schick 
mir eine PM.

So oder so: Wenn alle Master unkontrolliert senden können sollen, so 
würde ich dir zumindest beim Slave empfehlen, dass der den Empfang 
bestätigt (z.B. schickt er ein XOR-Byte aller empfangenen 32 Bytes 
gleich im Anschluss zurück, der sendende Master kann somit überprüfen, 
ob seine Daten angekommen sind). Denn wie schon geschrieben: Wenn du 
alle Teilnehmer gleizeitig einschaltest, werden die sich tendenziell 
gleich verhalten (auch zeitlich), und somit kann es vorkommen, dass 
immer irgendwelche gleichzeitig senden - und das über längere zeit.
ps: (Single-Master/Multi-Slaves)-Netzwerk ist massiv einfach zu 
implementieren als andersrum. Da gibt es auch ansätze, dass der Master 
periodisch (z.B. alle 30 Sekunden) nach neuen Slaves sucht, die vom 
Master noch keine zugewiesene Adresse erhalten haben.

rcc schrieb:
> Andi B. schrieb:
>>>> Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten.
>>>
>>> Zeig mir einen.
>>
>> TJA1057
>
> Datenrate mit Baudrate verwechselt?

Ja, mein Fehler.

Auch weil kurz vorher geschrieben wurde, CAN könne auch bei "niedriger 
Datenrate kilometerweit und mit vielen Stichleitungen".

Hallo,

Erik schrieb:
> Andi B. schrieb:
>> CAN könne auch bei "niedriger
>> Datenrate kilometerweit und mit vielen Stichleitungen"
>
> Das kann es natürlich nicht.

Doch, kann er ;-) Folgende Empfehlungen zur Leitungs-/Stichleitungslänge 
gilt für den CAN:

1

baud rate   Leitungslänge    Stichleitung (einzeln)   Stichleitungen (gesamt)

2

50 kbit/s  1000 m               50 m                    250 m  

3

125 kbit/s  500 m               20 m                    100 m  

4

250 kbit/s  250 m               10 m                     50 m  

5

500 kbit/s  100 m                5 m                     25 m  

6

1 Mbit/s     20 m                1 m                      5 m

Und mit dem genannten TJA1057 kann man problemlos 50 kbit/s einstellen 
(minimal 0.6 ms time-out). Damit lässt sich eine (ein) Kilometer lange 
CAN-Leitung mit vielen (insgesamt 250m langen) Stichleitungen 
darstellen.

In der Praxis kann man einen 50kbit/s - CAN praktisch nicht durch die 
Leitungsführung kaputt machen.

Schöne Grüße,
Martin

Bauform B. schrieb:
> Ein sparsamer Transceiver (ISL3172E) braucht 700uA bzw.
> 800uA beim Senden. Für die Slaves wäre der allerdings gut. Gibt es
> eigentlich ähnlich sparsame CAN-Transceiver?

Z.B. der AT6560 braucht im Standby max 12µA. Ein dominanter Pegel läßt 
ihn aufwachen, d.h. der Empfangsteil bleibt aktiv.

Martin L. schrieb:
> Doch, kann er ;-) Folgende Empfehlungen zur Leitungs-/Stichleitungslänge
> gilt für den CAN:
> baud rate   Leitungslänge    Stichleitung (einzeln)   Stichleitungen
> (gesamt)
> 50 kbit/s  1000 m               50 m                    250 m
> 125 kbit/s  500 m               20 m                    100 m
> 250 kbit/s  250 m               10 m                     50 m
> 500 kbit/s  100 m                5 m                     25 m
> 1 Mbit/s     20 m                1 m                      5 m

Du kannst sogar noch ne Null an der Bitrate wegnehmen und dann reicht 
der CAN-Bus bis ins Nachbardorf, mit Stichleitungen an jedem 
Gartentürchen, es spricht nichts dagegen notfalls auf 10kHz oder gar 
5kHz runterzugehen.

Martin L. schrieb:
> baud rate   Leitungslänge    Stichleitung (einzeln)   Stichleitungen
> (gesamt)
> 50 kbit/s  1000 m               50 m                    250 m
> 125 kbit/s  500 m               20 m                    100 m
> 250 kbit/s  250 m               10 m                     50 m
> 500 kbit/s  100 m                5 m                     25 m
> 1 Mbit/s     20 m                1 m                      5 m

Kannst du mir die Quelle für diese Werte nennen? Das Problem mit den 
Stichleitung kommt bei uns häufiger vor.

Grüße

Bernd K. schrieb:
> es spricht nichts dagegen notfalls auf 10kHz oder gar
> 5kHz runterzugehen.

Bei 10 kbit/s werden es 6,7km Leitungslänge.

https://www.me-systeme.de/de/support/grundlagen/can-bus-grundlagen

Mit welchem Widerstand terminiert man solche Buslängen?

Thomas F. schrieb:

> Mit welchem Widerstand terminiert man solche Buslängen?

Mit dem Wellenwiderstand der verwendeten Leitung, wie sonst auch.

Allerdings machen einem die Abzweigungen von Stichleitungen die schöne 
Rechnung wieder kaputt. Jedoch bei solch niedrigen Bitraten dürften 
Reflexionen eh keine große Rolle mehr spielen.

Hallo,
ein paar Randbedingungen sollte man bei der ganzen Sache dann doch noch 
beachten.
> Simon T. schrieb:
> Kannst du mir die Quelle für diese Werte nennen? Das Problem mit den
> Stichleitung kommt bei uns häufiger vor.
Bei Stichleitungen hat man ja das Problem, dass diese nicht alle 
terminiert werden können, weil der Signalpegel dadurch unzulässig 
reduziert würde.

Ob aber unterminierte Leitungen Probleme machen, hängt nicht primär von 
der Baudrate ab, sondern vom Frequenzsprektrum des Signals.
Diese ist aber hauptsächlich von der Flankensteilheit der Bits abhängig.
Wenn die Baudrate auch nur 10kHz beträgt, man aber Treiber für eine max. 
Baudrate von 10MHz benutzt, muß man mit Oberwellen bis über 50Mhz 
rechnen
und bekommt auch schon bei paar 10m langen Leitungen kräftige 
Reflexionen.

Als Faustformel gilt: Eine Leitung ist ab ca. Lambda/10 als Wellenleiter 
zu betrachten. Spätestenz ab Lambda/4 hat man deutliche HF-Effekte auf 
nicht korrekt terminierten Leitungen.
Lambda ist dabei die höchste Frequenz mit noch relevanter Amplitude.

Wenn man also nur 10kBaud übertragen muß, dann sollte man tunlichst die 
Bandbreite des Signals begrenzen (also Flankensteilheit reduzieren).
Mit Oberwellen im Bereich bis 50MHz und höher werden dann schon 
Stichleitungen unter 1m Länge kritisch.
Bei Begrenzung der Bandbreite auf 100kHz sind aber auch Stichleitungen 
bis über 100m unproblematisch.

Die oben von Martin L. aufgeführten Leitungslängen beziehen sich bei CAN 
primär auf den Zusammenhang der Laufzeiten bei der Busarbitrierung.
Da wärend einer Bitzeit das Signal bis zum Ende des Busses laufen muß, 
dort erkannt und verarbeitet werden muß und dann wieder zurück läuft, 
darf die Baudrate nicht größer werden, als dieses Prinzip eben zuläßt.

Abgesehen davon sind Leitunglängen auch von dem Leitungwiderstand und 
HF-Eigenschaften (Induktivität und Kapazität) anhängig.
Bei einer typ. Signalleitung mit 0,25mm² Querschnitt hat man schon ca. 
80 Ohm pro km Widerstand.
Wenn oben behauptet wird, Leitungen könnten bei niedrigen Baudraten noch 
viel länger werden, so gilt das nur unter Voraussetzungen, dass die 
Leitungen ausreichden hohen Querschnitt haben.  Bei 6,7km Länge mit 80 
Ohm/km kommen auf der Hin- und Rückleitung schon über 1kOhm 
Leitungwiderstand zusammen. Bei einem Leitungabschluss mit 120 Ohm am 
anderen Ende reduziert das den Pegel dann schon auf ca. 1/10 der 
Sendespannung. Das reduziert den Störabstand schon deutlich und wenn der 
Pegel noch geringer wird, kann er nicht mehr sicher detektiert werden.

Diese Grundaussagen gelten (außer der Busarbitrierung) nicht nur für 
CAN, sondern im Prinzip auch für andere Bus-Systeme (z.B. RS485).

Deshalb rate ich auch jedem Bastler, der irgendwo RS485 verwenden will, 
moderate Baudraten bis max. 250 kBuad zu nutzen und bandbreitenbegrenzte 
Treiber zu einzusetzen (z.B. MAX483 statt MAX485)
https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf.
Gruß Öletronika

Hallo,

der Beschreibung meines Vorredners zu Stichleitungen und Gesamtlängen 
kann ich nichts mehr hinzufügen ;-). Die Quelle für die Tabelle hatte 
ich schnell gegoogelt, und da sie sich mit meiner Erinnerung deckte, 
hier angegeben. Das Original findet sich unter

https://gemac-fieldbus.com/de/leitungslaengen-stichleitungen/

Schöne Grüße,
Martin