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:
1 | Raspi Transceiver 1 |
2 | +------+ +-------------+ |
3 | | RX | ---+--|>|---- | TX | |
4 | | TX | -+-|--------- | RX | |
5 | +------+ | | +-------------+ |
6 | | | |
7 | | | Transceiver 2 |
8 | | | +-------------+ |
9 | | +----|>|-- | TX | |
10 | +-|--------- | RX | |
11 | | | +-------------+ |
12 | ..... |
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Es gibt sogar fertige Module: http://www.mouser.de/Search/m_ProductDetail.aspx?FTDI%2FUSB-COM422-PLUS4%2F&qs=nswjyC6mNJp%252b9v404rWEGg%3D%3D Ich hab zwar eben nur schnell geguckt aber die RS422 Anschlüsse sollten Vollduplex unterstützen.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.