Moin, ich habe zu diesem Thema schon die Suche verwendet, aber noch keine befriedigende Antwort gefunden. Ich möchte einen Hausbus aufbauen. Anforderungen: -Single-Master -max. 255 Teilnehmer -max. 150m Leitungslänge -Stern/Baum-Topologie -min. 9600Baud -Leitung: CAT.5 Zum jetzigen Zeitpunkt habe ich mich viel mit RS485(4-Wire) beschäftigt und bin der Meinung es damit umsetzen zu können. Trotzdem scheint CAN auch eine ziemlich gute Alternative zu sein. Leider fehlt es mir an Erfahrungen mit den beiden Bus-Systemen. Habe mich in der Vergangenheit eher mit RS232, SPI und I2C beschäftigt. Vielleicht kann jemand seine Erfahrungen und sein Wissen mitteilen. (Als eine Art Wegweiser.)
bei der wahl rs485/can mit mehreren teilnehmern nimmt man eigtl immer can. alleine schon weil der bus direkt multimaster fähig ist. das vereinfacht eine menge dinge.
KNX, der sehr ausgreife und verbreitete Hausbus, hat viel Ähnlichkeit mit CAN Beide haben keine Master oder Slave da sie Botschaft-orientiert arbeiten. Für 9.6kBaud (die wirklich ausreichen) benötigt man kein Cat5 wichtiger ist das man wie z.B beim KNX Kabel einen verstärkte Isolierung hat die es erlaubt das Kable neben 230V zu legen. Und auch genug Strom zu Versorgung der Teilnehmer verträgt
Patrick S. schrieb: > -Stern/Baum-Topologie So richtig wird das weder mit RS485 noch mit CAN funktionieren, es sei denn du gehst mit der Datenrate sehr weit herunter. Auf der anderen Seite führt jede Stichleitung von der Linie streng genommen auch auf eine Sterntopologie und das funktioniert natürlich trotzdem, wobei es selbstverständlich auf die Länge ankommt. Für den Bus selbst würde ich CAN gegenüber RS485 vorziehen. CAN ist im Grunde einfacher als RS485 weil die ganzen möglichen Fehler (Kollisssionen, Übertragungsfehler.) schon auf Protokollebene abgefangen werden. Vom Preis her ist CAN mittlerweile auch fast günstiger als RS485, zumindest bei den Transceivern und CAN-fähige Controller sind auch sehr erschwinglich.
:
Bearbeitet durch User
Patrick S. schrieb: > Trotzdem scheint CAN auch eine ziemlich gute Alternative zu sein. Ist es auch. Das CAN macht eine sichere Übertragung komplett in Hardware, d.h. der Firmwareaufwand ist minimal. Zuverlässige Protokolle allein in Firmware mit der dummen UART sind dagegen riesig.
Peter D. schrieb: > Ist es auch. Das CAN macht eine sichere Übertragung komplett in > Hardware, d.h. der Firmwareaufwand ist minimal. > Zuverlässige Protokolle allein in Firmware mit der dummen UART sind > dagegen riesig. Das scheint mir bis jetzt das stärkste Argument zu sein. Habe mich am Wochenende damit näher Beschäftigt und werde auf CAN umsatteln. Danke.
Suche "single-master"... finde CAN... find den Fehler. UART mit zusätzlichen CRC-Bytes ist genauso sicher wie CAN. Das würde ich jetzt nicht als "riesigen" Aufwand bezeichnen. Die Physik, die CAN benutzt ist in der Tat robust und kollisionsfrei. Kleiner Tipp, benutz einen CAN-Phy mit Master/Slave auf UART Basis.
Erik schrieb: > UART mit zusätzlichen CRC-Bytes ist genauso sicher wie CAN. > Das würde ich jetzt nicht als "riesigen" Aufwand bezeichnen. Der Aufwand entsteht ja nicht beim CRC senden. Der Master muß den Fehler auch feststellen können und ein Retry veranlassen. Der Master kann nur den Empfänder adressieren und wenn der nichts sendet, gab es wohl irgend einen Fehler. D.h. er setzt einen Timeout auf und wartet erstmal ne Weile. Der CRC-Fehler kann auch im Adreßfeld auftreten, d.h. er ist sich ja nichtmal sicher, welcher Slave nicht antwortet. Beim CAN hängt die Empfängerhardware einfach einen Errorframe an und die Senderhardware macht automatisch ein Retry.
Auch bei CAN kannst du nicht garantieren, dass deine Nachricht angekommen ist. Im Gegenteil, du weißt es nicht mal. Im Falle eines Fehlers, bekommt man lediglich eine negative Quittung. Sowas könnte man ebenso beim UART mittels ACK durch den Slave implementieren, kein Timeout notwendig. In dem Falle hätte man zumindest eine positive Quittung. Wenn man das Protokoll jetzt noch stateless implementiert, umgeht man zumindest das two-army Problem. Für nen Master-Slave Protokoll würde ich mir da mal Profibus anschauen.
CAN kostet doch nichts mehr - warum sollte man sich das antun, irgendwas selbst zu stricken, um die korrekte Kommunikation zu sichern? Die haben sich ne Menge dabei gedacht und umgesetzt. Fehlerrate ist extrem klein. http://www.elektroniknet.de/elektronik-automotive/sonstiges/serielle-bussysteme-im-automobil-ii-303-Seite-3.html Wenn man den Bus korrekt betreibt,sind echte Fehler fast ausgeschlossen. Ansonsten ist mir persönlich ein Multimasterbus sowieso lieber, macht vieles einfacher. Und Multimaster mit RS485 will man nicht ohne Not (klar, RS485 kann deutlich schneller als CAN sein und/oder längere Leitungen möglich), für die meisten Anwendungen reichen die Datenraten/Längen völlig aus. Und dass eine eigene Protokollschicht besser/sicherer wäre muss man auch erst mal nachweisen :-)
Patrick S. schrieb: > -Single-Master > -max. 255 Teilnehmer > -max. 150m Leitungslänge > -Stern/Baum-Topologie > -min. 9600Baud > -Leitung: CAT.5 Ethernet?! Als Master einen einfachen Webserver mit PHP und Datenbank.
Schreiber schrieb: > Ethernet?! Ja, nach aktueller Planung CAT7. Ich möchte nicht in die Bredouille kommen jemals die Wände wieder öffnen zu müssen. Ich habe noch eine Frage. Gibt es einen empfehlenswerten CAN-Transceiver für LOW-Speed CAN? Macht CAN-Split in diesem Anwendungsfall Sinn?
Moin. Ich habe einen Self-Made-Hausbus auf CAN-Basis am laufen. Dazu habe ich einen alten 24 Port-Switch ausgeschlachtet. Den eigentlichen BUS bilden die 20cm zwischen Port 1 und Port 24 innerhalb des Switches. Über meine CAT-Verkabelung werden also Stichleitungen vom Keller zu den Sensoren in den Wohnräumen in den Bus gehangen. Gesamt z.Zt. 12 Sensoren im Netz mit Stichleitungslängen zwischen 7m(Keller) und 25m (Dachboden). Die CAN-Geschwindigkeit liegt bei 10kB/s. Zusätzlich wird über die RJ45 Stecker auch noch 12V Versorgung zu den Sensoren gegeben und 2 Statusleitungen, damit beim Switch der Link und der Traffic des Sensors angezeigt werden können. Außerdem befindet sich im Switch eine Platinen mit STM32F407 die die Verbindung zwischen dem CAN-Bus und diversen Schnittstellen bereitstellt, sowie ein LCD für Bus-Statusinformationen befeuert. Schnittstellen sind z.B. - RS422 - RS485 - RS232 - USB - LAN (noch nicht fertig implemetiert) Hier verwende ich einen ADUM3053 als CAN-Transceiver um den CAN-Bus auch galvanisch von den anderen Schnittstellen zu trennen. Das ganze läuft bislang störungsfrei. Höhere CAN-Geschwindigkeiten habe ich nicht ausprobiert. Die Sensoren basieren auf STM32F303. Sie messen mittels SHT21 Luftfeuchte und Temperatur, einer misst zusätzlich den Luftdruck per BMP280. Ein Kreuzschalenaneometer mit Hall-Sensor ist im Bau. Der CAN-Tranceiver ist ein SN65HVD232 ohne galvanische Trennung. Außerdem sitzt neben dem Stromzähler ein Hutschienen-Modul mit einem STM32F407 der u.A. den aktuellen Stromverbauch über eine S0-Schnittstelle ermittelt und in den CAN-Bus schickt. Auch hier verwende ich einen SN65HVD232 mit zusätzlicher galvanischer Trennung über einen ADUM1201. Vorteile von CAN sind ganz klar: - Bei vielen STM32 onboard - automatische Bus Arbitrierung, Sensoren schicken ihre Werte einfach in den Bus (alle 5..10s) - Jedes Modul greift sich die passenden Informationen aus dem Bus - Es bedarf keiner aufwendige Abfrageroutine Als Erweiterung ist geplant: - Kreuzschalen-Aneometer + evtl. Regensensor - Das Modul im Zählerschrank schaltet über 2..3 Relais die taupunktgesteuerte Kellerlüftung - Die Viessmann-Heizung wird abgefragt, Messwerte in den Bus - Die Schnittstellenplatine im Switch wird über USB oder LAN mit einer VM auf dem Server verbunden, der die Messwerte aufzeichnent, z.B. über Cacti.
1 | S Sensor an Heizung zur Messwertabfrage (geplant) |
2 | S | | |
3 | | | | Modul im Zählerschrank (Relais, S0), galv. getrennt |
4 | | | | | |
5 | |======================================| CAN-Bus 20cm im Switch, terminiert |
6 | | | | |
7 | | S | |
8 | | STM32 im Switch für LCD und Schnittst., galv. getrennt |
9 | S | |
10 | |USB oder LAN |
11 | | |
12 | Server zur Messwertaufzeichnung (geplant) |
13 | |
14 | S = Sensoren an Stichleitungen 7..25m, Cat6A/Cat7 |
Patrick S. schrieb: > Schreiber schrieb: >> Ethernet?! > > Ja, nach aktueller Planung CAT7. Ich möchte nicht in die Bredouille > kommen jemals die Wände wieder öffnen zu müssen. Der vorschlag war auf CAN oder RS485 zu verzichten und komplett auf ethernet zu setzen. Da ist Cat 5 völlig ausreichend, bei 10MBit (für Automatisierung völlig ausreichend) kann man auch 2 Geräte über ein Kabel anschließen. Stromversorgung über PoE geht auch, benötigt aber alle 8 Adern des Kabels. Zukunftssicher, erprobte und günstige Technik, was will man mehr? Zudem keine Probleme bei der Anbindung an ein Netzwerk. Man muss nicht immer alles selber entwickeln. Kabellose Geräte kann man auch noch bequem per Wlan einbinden.
Schreiber schrieb: > Der vorschlag war auf CAN oder RS485 zu verzichten und komplett auf > ethernet zu setzen. Der Vorschlag ist trotzdem Mist. Rechne mal bei den oben genannten 255 Teilnehmern die Kosten für die Hubs und den Strom zusammen...
Meine natürlich Switche, ändert aber nichts daran, dass das für die Aufgabenstellung nicht passt.
temp schrieb: > Der Vorschlag ist trotzdem Mist. Rechne mal bei den oben genannten 255 > Teilnehmern die Kosten für die Hubs und den Strom zusammen... So teuer sind 100MBit Hubs nicht und besonders viel Strom brauchen die auch nicht. Zudem kann man ja auch einiges drahtlos per Wlan anbinden.
Schreiber schrieb: > Da ist Cat 5 völlig ausreichend, bei 10MBit (für Automatisierung > völlig ausreichend) kann man auch 2 Geräte über ein Kabel anschließen. Wenn ich schon LAN-Kabel im gesamten Haus verlege, dann sicherlich nicht auf Basis von 10 MBit. Habe mit meinem Vater letztens (endlich!) das zentrale Koax-Kabel und die beiden Hubs ersetzt...
Eindeutig CAN ... Arbeite mit beiden Systemen beruflich und bei CAN gibt es auch viel bessere Tools zur Analyse, Tracen und wenn du die IDs vernünftig aufteilst kannst du viel besser sehen wär was wie mit welcher Priorität schickt und gewinnt etc.
An eine Ethernet Verbindung habe ich auch gedacht. An für sich auch super. Aber aus beruflicher Erfahrung weiß ich was ein Ethernet-Switch an Leistung ziehen... Ich habe hier auch einen 48 Port Cisco Switch(100Mbit) liegen, werde den aber schlachten und die Idee von SG umsetzen. Die Idee finde ich richtig gut. Zusätzlich verwende ich noch ein Baugruppenträger.
Patrick S. schrieb: > und die Idee von SG umsetzen die natürlich komplett der idealen Bustopologie widerspricht :-)
Wenn du schon eine zentrale Steuerung willst, dann schau dir auch CANopen CiA-401 an, kann zwar nur die Hälfte der Teilnehmer an einem Strang, dafür ist alles schön standardisiert. Als Controller hat sich der LPC11C14 als recht brauchbar heraus gestellt. Christian_RX7
Patrick S. schrieb: > Das ist nicht von der Hand zu weisen. ;) Wird aber dennoch bei moderaten Baudraten funktionieren. Deine 255 Busteilnehmer sind wohl eher theoretischer Natur, das wäre schon ein ordentliches Kabelbündel :-), und der zweckentfremdete 48port-switch reicht dannn auch nicht mehr.
Ich nutze im Keller für die Heizung, Wasserverbrauch und in Zukunft auch Tankstand Gartenbewässerung und Stromverbrauch den CAN-Bus. Damit die Daten an dem Zentralen Raspberry kommen hab ich mir aus nem SAME70 Devboard ein CAN-LAN Gateway gebaut. Über das Gateway bekommt der Raspberry die Daten und gleichzeitig kann ich vom PC über das Gateway die Firmware der Module flashen. Das Prtokoll für die CAN Nachrichten im LAN ist ein eigener Ethertype. Gruß JackFrost
> die natürlich komplett der idealen Bustopologie widerspricht :-) Ja ich war auch nicht sicher ob das funktioniert. Läuft aber. Demnächst wird die längste Stichleitung dazukommen, ca. 50m, die Verbindung in die Garage. Daran soll dann der Außensensor mit dem Windmesser hängen. Bin zuversichtlich das es weiterhin störungsfrei laufen wird. Hier sind ein paar Längen angegeben: https://gemac-fieldbus.com/de/leitungslaengen-stichleitungen/ Bei 250kBit/s 250m Bus, max. 10m Stichleitung, max. 50m Gesamtlänge der Stichleitungen. Bei 50kBit/s 1000m Bus, max. 50m Stichleitung, max. 250m Gesamtlänge der Stichleitungen. Es scheint sich also halbwegs Linear zu verhalten. Somit sollte ich bei 10kBit/s theoretisch irgendwas bei 250m Stichleitung und 1200m Gesamtstichleitungslänge erreichen können. Das reicht für mich und meine kleine Hütte allemal.
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.