Ich beschäftige mich gerade mit dem Thema CAN-Bus. Das funktioniert auch soweit mit AVRs und RaspberryPi. Ich kann also munter CAN-Nachrichten hin und her schicken - so weit, so gut. Gibts irgend ein Regelwerk/Leitfaden, welche CAN-IDs zu welchen Zwecken zu nutzen sind, oder kann man das einfach "frei Schnauze" festlegen? Gibts ID-Bereiche, die eine "Sonderbehandlung" bekommen, oder gemieden werden sollten? Einsatzzweck wird SmartHome sein. Sorry für die vielleicht dummen Fragen, aber ich sehe da gerade den Wald vor lauter Bäumen nicht
Gast
#5023768
Rein technisch : je wichtiger, desto niedriger... Und dann gibt es natürlich auch noch Protokolle, die auf Can aufbauen und dann Vorgaben machen.
Gast
#5023781
Kommt halt immer auf den Bereich an, bei der KFZ-Diagnose wird zum Beispiel der Bereich 700 bis 7FF verwendet, das Päärchen 7E0/7E8 oder 7E7/7EF wird gewöhnlicherweise für die Motorelektronik verwendet.
fop schrieb: > Rein technisch : je wichtiger, desto niedriger... Guter Hinweis! Danke!
Gast
#5023803
Harry L. schrieb: > fop schrieb: >> Rein technisch : je wichtiger, desto niedriger... > > Guter Hinweis! Das hat übrigens nichts mit Regelwerk/Leitfaden zu tun, sondern ist ganz grundlegend durch die CAN-Übertragung so vorgegenen. Niedrigere IDs sind dominant gegenüber höheren.
Gast
#5023976
Ganz wichtig ist sich vorher ein Konzept zu machen. Dann kann man später nach CAN IDs besser Gruppen filtern.
Gast
#5027233
Ich empfehle das CANopen Protokoll zu verwenden. Dort sind Bereiche für die Identifier und der Aufbau der Nachricht definiert. Dazu gibt es auch komplette Software-Stacks. Wenn man es einfach machen will verwendet man davon nur das PDO Protokoll. https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
Gast
#5027239
Martin, für eine Hausautomation ist CANopen nicht wirklich notwendig. CANopen ist deutlich umfangreicher und als Hobbyprogrammierer hat man viel Aufwand und wenig Nutzen. Es sei den er will CANopen Komponenten einsetzen.
Gast
#5027371
CAN User schrieb: > Martin, für eine Hausautomation ist CANopen nicht wirklich notwendig. > CANopen ist deutlich umfangreicher und als Hobbyprogrammierer hat man > viel Aufwand und wenig Nutzen Daher habe ich empfohlen, sich am PDO Protokoll zu orientieren. Die PDO Messages sind auch ohne CANopen Stack umzusetzen. Wenn man das Netz dann später erweitern will, so ist es problemlos möglich, in das vorhandene Netz CANopen Knoten hinzuzufügen - vorausgesetzt, man hat die entsprechenden identifier-Bereiche, wie sie für die SDO, emcy, NMT, Heardbeat Protokolle vorgesehen sind, frei gehalten.
Gast
#5028646
CANopen ist für solch eine Anwendung wirklich oversized. Ich bin aber auch kein wirklicher Fan von dem Protokoll, aber ich muss es beruflich einsetzen. Bei solch einer Anwendung sehe ich keine Einschränkungen/Nachteile durch CAN. Ich würde die jeweiligen Sensoren/Aktoren einfach gruppieren. Teilnhemer der Küche benutzen die IDs 0x10 - 0x1A, Esszimmer 0x20 - 0x2A usw...
Gast
#5028647
Anstatt A natürlich F ... Es ist einfach zu warm zum Denken ;-)
Ich hab CAN aktuell nur in Keller für meine Heizung und Wasserzähler. Tankstand, Garten Gießen und Türöffner kommen noch. Ich hab die ID 0x01 für Systemnachrichten wie Timestamp oder Mitternachts Signal. Die Nachrichten wie Temperatur , Ölverbrauch usw haben dann IDs nach Priorität. Das höchste Bit ist nur für Firmwareupdates. Gruß JackFrost
Ich stand vor einiger Zeit vor der selben Fragestellung und fand diese Seite ganz inspirierend: http://doku.canathome.de/ Es ist vielleicht auf den ersten Blick etwas irritierend, beim Broadcast-orientierten Medium CAN in die ID einen Sender- und Empfängerknoten hineinzukodieren. Auch die selbsterfundenen Abkürzungen und die Logik mit den Nebenbedingungen finde ich ziemlich kompliziert. Aber die vergebenen CAN-IDs und das Nachrichtenformat haben mich überzeugt. Das Schema sollte für fast alle Kommunikationswünsche reichen ohne dass irgendwann der Nummernraum ausgeht. Grüße, Tilo
Ich habe bei mir auch die IDs eher als Adresse missbraucht. Ist ja eigentlich nicht der Sinn hinter CAN, aber ich fand die Möglichkeiten ganz gut. Ich hab die einzelnen Bits der ID in Gruppen aufgeteilt. Da gibts dann Felder für Etagen und Räume. Auch mit der Möglichkeit eines Broadcasts über verschiedene Bereiche oder Funktionen. ZB. genügt dann eine Nachricht um zu sagen: Alles was Licht ist geht jetzt aus. Oder: Alle Steckdosen aussen gehen jetzt aus. Eine Art Priorisierung mit den niederwertigen Adressen für Wichtiges habe ich auch vorgesehen. Ist ja praktisch kostenlos mit drin, wenn man von Anfang an dran denkt :) Allerdings wird beim Hausbus selten soviel los sein, dass das mal zum Tragen kommen wird.
Tilo R. schrieb: > Ich stand vor einiger Zeit vor der selben Fragestellung und fand diese > Seite ganz inspirierend: > http://doku.canathome.de/ Vielen Dank! Das schau ich mir mal näher an. CANOpen erschien mir auch etwas übertrieben für mein Vorhaben.
Gast
#5029190
Markus schrieb: > Ich würde die jeweiligen Sensoren/Aktoren einfach gruppieren. > Teilnhemer der Küche benutzen die IDs 0x10 - 0x1A, Esszimmer 0x20 - 0x2A > usw... Nimm stattdessen die Identifier 0x100 .. 0x500. (PDO Bereich) Halte die IDs 0x0 .. 0xFF frei, wird für NMT und Emergency benötigt. So lässt sich das ganze später immer noch mit CANopen auf einem Bus kombinieren.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.