Hallo miteinander,
ich bin gerade auf der Suche nach einen Bussystem das auch Sternförmig
betrieben werden kann.
Folgendes habe ich vor:
Als "Server" will ich einen RaspberryPi (oder etwas ähnliches) nutzen.
Dieser kommt auf eine hübsche Platine an die mehrere
Sensor/Aktor-Platinen über RJ45 Buchsen angeschlossen werden können. Die
Kabellänge vom Raspi zu den einzelnen Platinen beträgt zwischen 1 und 25
Metern. Über das gleiche Kabel sollen die "Sub-Platinen" auch mit
Energie (12V & 5V) versorgt werden.
Die einzelnen Sub-Platinen müssen nicht untereinander kommunizieren
können - das soll dann alles über den Raspi gehen. Allerdings sollten
die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort
Daten an den Server schicken können.
Bei CAN oder RS485 ist Sternförmig ja (so wie ich bisher gelesen habe)
nicht möglich. Was gibts da sonst noch? Ethernet wäre ne Möglichkeit -
frisst mir aber zu viel Strom.
Das ganze sollte mit möglichst wenig Komponenten machbar sein.
Danke! :)
Timo schrieb:> Bei CAN oder RS485 ist Sternförmig ja (so wie ich bisher gelesen habe)> nicht möglich.
Könnte man aber mit Hin- und Rückleitung aufzwirbeln. Braucht dann halt
mehr Adern - und hat die Verfügbareit von Thinwire Ethernet, d.h. die
erste kaputte Buchse stört den Bus.
Timo schrieb:> Das ganze sollte mit möglichst wenig Komponenten machbar sein.
USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485
Treiber anschließt.
Vorteil: Viele Busse, Störungen bleiben auf einzelnen Bus begrenzt,
sendende Ereignisse erzeugen weniger Kollisionen.
CAN funktioniert bei niedrigen Baudraten auch sternförmig. Dazu gab es
hier mal einen Link zu "CAN in Automation", dort stand eine Tabelle mit
den maximal möglichen Stichleitungslängen in Abhängigkeit von der
Baudrate. Leider ist der Link mittlerweile tot (hat jemand noch diese
Tabelle offline gespeichert?). Die Werte bei 20kbaud habe ich aber noch
in einem alten Thread gefunden:
> Bei 20kbit/s darf z.B. eine Stichleitung nicht länger als 137m sein,> alle Stichleitungen zusammen dürfen nicht länger als 687m sein.> Natürlich sind diese Angaben abhängig von den verwendeten Treibern. Die> Tendenz ist aber klar: je niedriger die Baudraten desto weniger Probleme> bekommst Du mit Stichleitungen. Analog trifft das auch auf RS485 zu.
Ich persönlich verwende in meinem CAN-Hausbus eine sternförmige
Verkabelung (geschätzte 600m verteilt auf ca. 15 Stichleitungen) ohne
Probleme.
Übrigens sind die meisten anderen Bussysteme nur deshalb unkritischer,
weil sie von Haus aus für eine niedrigere Übertragungsrate spezifiziert
sind.
Viele Grüße, Stefan
rmu schrieb:> mehrere transceiver-ICs?
Darüber hatte ich auch schon nachgedacht. Allerdings wäre ich dann ja
bei der Anzahl der Teilnehmer auf die Anzahl der Transceiver beschränkt.
Sollte also irgendwann mal noch ein Platinchen hinzukommen siehts
schlecht auch.
Jim M. schrieb:> Könnte man aber mit Hin- und Rückleitung aufzwirbeln. Braucht dann halt> mehr Adern - und hat die Verfügbareit von Thinwire Ethernet, d.h. die> erste kaputte Buchse stört den Bus.
Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf
einer Platine/Leitung keine Auswirkungen auf das restliche System hat.
Jim M. schrieb:> USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485> Treiber anschließt.
Auch das möchte ich nicht unbedingt. Ich will den Raspi "kopfüber" auf
die Platine stecken und alles über die GPIO Pins abgreifen.
Stefan K. schrieb:> Leider ist der Link mittlerweile tot (hat jemand noch diese> Tabelle offline gespeichert?).
Habe gerade mal ein bisschen gegoogelt... Meinst du das hier?
https://www.can-cia.org/de/can-knowledge/canopen/canopen-lower-layers/
Hmm... Ich denke ich werd das ganze mit CAN versuchen. Laut der Seite
müssen die einzelnen Stichleitungen nicht terminiert werden?
> "and the maximum unterminated cable drop lengths"
Wo muss ich dann terminieren?
Direkt am Transceiver und dann nochmal nach den RJ45-Buchsen?
Timo schrieb:> Habe gerade mal ein bisschen gegoogelt... Meinst du das hier?> https://www.can-cia.org/de/can-knowledge/canopen/canopen-lower-layers/
Exakt. danke fürs Raussuchen ;-)
> Hmm... Ich denke ich werd das ganze mit CAN versuchen. Laut der Seite> müssen die einzelnen Stichleitungen nicht terminiert werden?
Ja. Es gibt die Methode der Zentralterminierung. Dabei wird im
Sternpunkt ein einzelner Terminierungs-R eingesetzt, der den normalen 2
* R parallelgeschaltet entspricht, also 60Ohm.
Wenn ich mich recht erinnere, habe ich bei mir an 2 Stichleitungen die
"normalen" Terminierungs-R eingesetzt.
Willst Du die 5V direkt für die Versorgung der dezentralen Elektroniken
verwenden? Das halte ich für störanfällig - besser ist die dezentrale
Erzeugung der VCC aus den 12V.
Viele Grüße, Stefan
>Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf>einer Platine/Leitung keine Auswirkungen auf das restliche System hat.
Dann bleibt dir doch nur noch Ethernet.
Timo schrieb:> Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf> einer Platine/Leitung keine Auswirkungen auf das restliche System hat.
Dann ist das aber nicht die Lösung...
Timo schrieb:> Hmm... Ich denke ich werd das ganze mit CAN versuchen.
...denn ein Kurzschluß oder eine Fehlfunktion bei einem der Teilnehmer
legt den Bus lahm.
Wirklich robust gegen Störungen ist in der Tat:
holger schrieb:> Dann bleibt dir doch nur noch Ethernet.
Hmmmm.... OK, überzeugt^^
Über einen Kurzschluss auf der Bus-Leitung hatte ich garnicht
nachgedacht. Ich meinte eigentlich einen Kurzschluss der
Versorgungsspannung - hier sollte nicht das ganze System lahmgelegt
werden. Aber an die Busleitungen hab ich hierbei nicht gedacht.... Das
hab ich wohl unglücklich formuliert ;)
Ich denke ich nehme dann doch RS485 und werde dann wohl doch für jeden
Teilnehmer einen eigenen Transceiver verwenden und auf der Platine
einfach etwas Platz für weitere Transceiver vorsehen.
Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom
Raspi hängen? Also... Ungefähr so:
Timo schrieb:> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom> Raspi hängen?
Nein, nicht ohne weiteres. TxData köntest du zwar ev. parallel an alle
senden, das kommt auf das Protokoll an ob das geht (Adressierung). Die
RxData kannst du aber nicht miteinander verbinden. Wenn du aber sowieso
eine Platine machst, kannst du die Transceiver einzeln mit je einem
Enablesignal schalten, oder, wenn sie keines haben, über abschaltbare
Treiber anbinden. Mehrere empfangsbereite Uarts brauchst du allerdings,
wenn sich die Slaves spontan melden sollen, denn dann weisst du ja nicht
wann was über RxData reinkommt.
Ich verwende in solchen Fällen ein Protokoll mit Slaveadresse und frage
die Slaves ständig reihum ab. Nicht vergessen: auch Slaves abfragen, die
nicht online sind, sie können ja online werden, und ebenso können Slaves
sich verabschieden, das muss alles im Protokoll geregelt sein!
Georg
Timo schrieb:
> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom> Raspi hängen?
Nicht direkt, aber über ein AND-Gatter mit einem Eingang pro Tranceiver.
So ein Monster-Gatter kann man natürlich aus mehreren normal kleinen
zusammensetzen. Multi-Master geht damit schlecht, aber mit einem echten
RS-485-Bus geht's auch nicht einfacher.
Georg schrieb:> wenn sich die Slaves spontan melden sollen,
Was bei RS485 sowieso nicht wirklich angenehm ist. Der Zirkus, den man
sich mit Arbitrierung einhandelt, denn muss man erst einmal zuverlässig
in den Griff kriegen.
Timo schrieb:> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom> Raspi hängen? Also... Ungefähr so:
Im Prinzip schon - wenn man immer nur einen Transceiver aktiviert. Da
aktive Transmitter Strom fressen, und das nicht zu knapp, wär das
vielleicht ohnehin sinnvoller. Viele Transceiver-Bausteine haben
entsprechende Rx/Tx-Enables.
Einen einzelnen Master alle infragekommenden Slaves reihum abklappern zu
lassen ist jedenfalls deutlich einfacher, als zu versuchen, von der
grünen Wiese weg einen Multimaster-RS485 in Sterntopologie einzurichten.
Mit dem LIN-Bus lässt sich sowas realisieren, allerdings muss der Master
die Slaves pollen, weil die sich nicht selbständig melden dürfen. LIN
ist grob gesagt so eine Mischung von UART und I2C.
Max. Kabellänge bei 19.2kbps sind 40 Meter.
Jim M. schrieb:> Timo schrieb:>> Das ganze sollte mit möglichst wenig Komponenten machbar sein.>> USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485> Treiber anschließt.>> Vorteil: Viele Busse, Störungen bleiben auf einzelnen Bus begrenzt,> sendende Ereignisse erzeugen weniger Kollisionen.
Das war auch mein erster Gedanke. Wenn der zentrale Knoten der Master
sein soll und Teilnehmer nicht direkt miteinander kommunizieren braucht
man im Prinzip gar keinen Bus. Es reicht, wenn der Master soviele
Peer-to-Peer Verbindungen ermöglicht wie man Teilnehmer hat.
Dein Ansatz mit USB-Hub und seriellen Wandlern ist komfortabel und
einfach erweiterbar. Ich würds so machen, zumal:
A. K. schrieb:> Einen einzelnen Master alle infragekommenden Slaves reihum abklappern zu> lassen ist jedenfalls deutlich einfacher, als zu versuchen, von der> grünen Wiese weg einen Multimaster-RS485 in Sterntopologie einzurichten.
Timo schrieb:> Allerdings sollten> die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort> Daten an den Server schicken können.
Das bedeutet Multi-Master. Und das ist mit CAN wesentlich einfacher zu
realisieren als mit RS485.
Selbst wenn Du nur 2 Geräte am RS485 hast (Raspi und Transceiver) hast
Du ein Master/Slave System. Der Transceiver darf (eigendlich) nicht
selbstständig Daten an den Master schicken, weil dieser zur selben Zeit
den Slave ansprechen könnte.
Gruß, Stefan
ich würd
* RS485 nehmen, mehrere Transceiver ICs verwenden, ein UART
* Transmit Enable "zu fuss" über IOs, ein Schieberegister oder einen
Demux ansteuern
* Telegramme mit definierter Maximallänge verschicken
* Slaves haben eine "Adresse"
* Master pollt Slaves
* jeder Slave schickt immer genau eine (oder evt. keine bei Broadcasts)
Antwort
natürlich brauchts da noch einiges an Software, z.B. muss der Master
herausfinden können, welcher Slave an welchem Transceiver hängt etc...
Um out of band reagieren zu können brauchts eine eigene
"Interrupt"-Leitung, die dann einen Reihum-Poll auslöst. Evt. als RS422
Differenzsignal übertragen.
Vielleicht ist CAN doch einfacher ;)
Stefan K. schrieb:> Das bedeutet Multi-Master. Und das ist mit CAN wesentlich einfacher zu> realisieren als mit RS485.> Selbst wenn Du nur 2 Geräte am RS485 hast (Raspi und Transceiver) hast> Du ein Master/Slave System. Der Transceiver darf (eigendlich) nicht> selbstständig Daten an den Master schicken, weil dieser zur selben Zeit> den Slave ansprechen könnte.
Bei einem Stern mit vielen Transceivern kann man dann auch RS422 mit 4
Adern also Vollduplex benutzen.
Wenn Kurzschlüsse oder Kabelbrüche nur auf den jeweiligen Teilnehmer
beschränkt sein soll, könntest du auch CAN und mehrere AMIS-42770
Bausteine nehmen. Du musst aber dabei auf das Delay der AMIS-42770
Bausteine achten, denn das verringert deine maximale Buslänge. Durch CAN
hast du ohne Softwareentwicklung ein Multimaster bzw. ein master-loses /
dezentrales System.
Ansonsten: Ethernet. Beim Stromverbrauch kenne ich mich leider zu wenig
aus.
Andere Idee: Alle Sensoren und Aktoren mit einer eigenen I2C
Schnittstelle bedienen. Da sollten 25m auch kein Problem sein, sofern du
keine stark gestörte Umgebung hast.
Der ATxmega64 hat schonmal 4x I2C. Oder du nimmst ein PCA9518 also ein
I2C Hub
Man nehme pro Client einen RS-422-Tranceiver, 4 Datenadern und ein UART.
Wenn der Pi zuwenig UARTs hat, kann man einen uC mit z.B 6 UARTs davor
schalten. Wenn das nicht reicht, kann man mehrere uC kaskadieren. Damit
dürfen Master und alle Clients jederzeit senden und das "Protokoll" legt
nur den Datenrahmen fest.
Die Stromversorgung der Clients kann zentral über je einen High Side
Switch erfolgen, der den Kurzschluss-Strom begrenzt. Je nachdem wie
viele Client-Kurzschlüsse man gleichzeitig erlauben will, muss das
zentrale Netzteil evt. etwas kräftiger sein (aber s.u). Die 3.3V/5V
werden sowieso Client-seitig geregelt.
Bleibt noch, die RS-422-Pins des Masters (und evt. der Clients) gegen
direkte Kurzschlüsse gegen die Betriebsspannung zu schützen. 12 Volt
vertragen die meisten Tranceiver, von TI gibt es auch welche, die 48
Volt vertragen. Man kann die Pins auch mit relativ kleinen TVS schützen,
wenn der Master die Client-Versorgung überwacht und rechtzeitig
abschaltet.
Diese Konfiguration ist nicht nur fehlertolerant sondern auch beliebig
schnell bzw. nur von der Rechenleistung des Masters begrenzt. Man kann
die Punkt-zu-Punkt Datenleitungen ja beliebig terminieren, von garnicht
für langsam, kurz und stromsparend bis korrekt an beiden Enden.
Was hab' ich noch vergessen?
eagle user schrieb:> Was hab' ich noch vergessen?
Welcher Mikrocontroller hat mehr als 4 UARTs? Ich denke ich wuerde eher
die Lösung mit einem USB Hub und vielen USB RS422 Wandlern vorschlagen.
Und wieder wird das Rad erfunden ...
Timo schrieb:> Allerdings sollten> die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort> Daten an den Server schicken können.
Nur alleine durch diese Forderung nagelst Du Dich auf eine Punkt zu
Punkt Verbindung bzw. auf Multimaster Betrieb fest.
Für menschliche Bedienung reichen 300ms zwischen Aktion und Reaktion
Deines Systems damit man keine Verzögerung spürt.
Reichen würde Dir wahrscheinlich ein adressierter 2Draht Bus wie LIN
oder DALI um Power + Daten zu übermitteln.
Auch mit RS485 sind beliebig gemischte Bus / Stern Verkabelungen kein
Problem wenn die Datenrate niedrig genug ist.
Entweder unterminiert oder mit komplexer (RC) Terminierung.
Auf Slave Seite begrenzt man per Hardware die maximale Zeit die ein
Treiber auf senden stehen kann und verwendet den Watchdog gegen
Softwarehänger.
Wenn fehlerhafte Slaves so häufg vorkommen das ein Busbetrieb nicht mehr
möglich ist dann sollte man dringend die Designfehler beheben statt
Systeme mit Maximalverkabelung zu bauen.
Mit einer 100ms Pollingrate alle Slaves lesen / schreiben reicht für
eine flüssig bedienbare Sensor / Aktor Installation.
Ab welchem Timing bei Raspi + Linux die 'Echtzeit' Probleme anfangen
kann ich nicht einschätzen.
Zur Not ein Master am USB Port des Raspi der gegenüber dem Bus das harte
Timing macht.
Baendiger schrieb:
> eagle user schrieb:>> Was hab' ich noch vergessen?>> Welcher Mikrocontroller hat mehr als 4 UARTs? Ich denke ich wuerde eher> die Lösung mit einem USB Hub und vielen USB RS422 Wandlern vorschlagen.
Der STM32F091 (LQFP-64) hat 8, ist aber EMV-mäßig eher mäßig, die
STM32L47x sind besser und haben 6 UARTs. Und das sind nur die, die ich
für mich ausgesucht habe.
Michael Knoelke schrieb:
> Mit einer 100ms Pollingrate alle Slaves lesen / schreiben reicht für> eine flüssig bedienbare Sensor / Aktor Installation.
Mit einem echten Stern hast du aber Totzeiten im einstelligen ms Bereich
und nur soviel Traffic wie wirklich nötig ist; immerhin baust du eine
ziemlich ausgedehnte Antenne auf.
> Ab welchem Timing bei Raspi + Linux die 'Echtzeit' Probleme anfangen> kann ich nicht einschätzen.
Ein Standard-Debian-Kernel hat 4ms Zeitscheiben. Die Taskwechselzeiten
sind kurz verglichen mit der seriellen Übertragung, aber natürlich, die
Masse macht's. Wir wissen ja nicht, wie schnell Daten von wie vielen
Clients kommen. Was wirklich bremst, sind Massenspeicher, vor allem
SD-Karten.
eagle user schrieb:> Wir wissen ja nicht, wie schnell Daten von wie vielen> Clients kommen
Eigentlich schon, jedenfalls nach den ursprünglichen Wünschen des TO:
wenn die Clients spontan senden können, ist es natürlich möglich, dass
sämtliche Clients gleichzeitig Daten übertragen, und auf diesen worst
case muss die Verarbeitung ausgelegt sein. Ich würde in so einem Fall
für jeden Anschluss einen Slave-Prozessor vorsehen, der eine
Client-Übertragung selbständig abwickeln und zwischenspeichern kann,
dann skaliert die Übertragungskapazität mit der Anzahl der Clients.
Zur Sinnhaftigkeit dieser Forderung wurde schon genug gesagt.
Georg
