CAN Bus im VM!

Reinhard · 29.03.2023

OT entsorgt.

Es geht hier nicht darum, ob ein Bus-System oder konventionelle Verkabelung Vor- oder Nachteile haben, sondern eben um CAN-Bus im VM. Und das bitte ich zu respektieren ...

JKL · 29.03.2023

Reinhard schrieb:
OT entsorgt.

Es geht hier nicht darum, ob ein Bus-System oder konventionelle Verkabelung Vor- oder Nachteile haben, sondern eben um CAN-Bus im VM.

fho schrieb:
Einfach um etwas mehr Argumente für weniger Kabel zu haben: Wieviel Litzen hast du da jetzt insgesamt verlegt?

Hmm ... mir ging es bei meinem OT auch nur darum, das man mit Bus nicht ein einziges Kalbel spart, sondern min 4 mehr im VM hat.

Gruß Jörg

Reinhard · 29.03.2023

JKL schrieb:
Hmm ... mir ging es bei meinem OT auch nur darum,

Und wovon träumst Du nachts? Lass das sinnlose OT einfach sein.

JKL · 29.03.2023

Reinhard schrieb:
Und wovon träumst Du nachts? Lass das sinnlose OT einfach sein.

Wo zählst du weniger Leitungen?
Ja ... beim Bus sie sind kürzer, aber nicht weninger.

Gruß Jörg

beate · 29.03.2023

Naja, über die Frage, ob ein CAN-Bus im VM über haupt sinnvoll sein kann, kann man trefflich diskutieren. In meine Augen ist das jedenfalls kein OT-Müll. Man muss schon arg engmaschig denken, um das anders zu sehen.

Und die Gedanken anderer dann als Müll anzusehen ... ok, entspricht wohl dem Zeit-Ungeist.

JKL · 29.03.2023

beate schrieb:
Naja, über die Frage, ob ein CAN-Bus im VM über haupt sinnvoll sein kann, kann man trefflich diskutieren.

Darüber will ich auch hier nicht diskutieren.
Für den ein oder anderen mag das durchaus sinvoll sein, aber es sind mehr Kabel.
Die Aussage, das es weniger wären ist schlicht weg falsch.

Gruß Jörg

Reinhard · 29.03.2023

Leute, ich möchte hier von einer Umsetzung der Elektronik auf CAN-Bus lesen, nicht ob es 'ne Leitung mehr oder weniger ist. Das tut nichts zur Sache und ist nicht Diskussionsgegenstand in diesem Thread.

beate · 29.03.2023

Dann könntest auch Du zur Abwechslung einmal das versuchen, was wir anderen grundsätzlich machen, wenn uns Beiträge nicht gefallen: überlesen.

Und schade, dass wir hier wieder einmal genötigt werden, ins OT zu verfallen und Kritik an der Moderation üben müssen.

Goucho · 29.03.2023

Naja, über die Frage, ob ein CAN-Bus im VM über haupt sinnvoll sein kann, kann man trefflich diskutieren.

Aber über die Sinnhaftigkeit von CAN im VM wurde doch im Ursprungsthread schon ausgiebig diskutiert.
Dieser Thread wurde doch gerade eingerichtet, damit der ursprüngliche nicht mit technischen Details bzgl. CAN überfrachtet wird.

beate · 29.03.2023

Die Sinnhaftigkeit einer besser strukturierten Elektrik im VM stellt aber doch niemand in Frage. Am wenigsten ich - immerhin hatte ich ja eine strukturierte Masseleitung ins Spiel gebracht und dazu konstruktive Möglichkeiten zum ordentlichen (teilverdeckten) Verlegen von Leitungen im VM

Fanfan · 29.03.2023

JKL schrieb:
Ja ... beim Bus sie sind kürzer, aber nicht weninger.

Das hatten wir schon in einem anderen Thread, in dem hier wird nach meinem Verständnis die Frage nach Sinn und Unsinn eines CAN im VM als beantwortet angenommen. Es gibt trotzdem noch einen Punkt, den @JKL nebenher angerissen hat, und der hier m.E. von Interesse ist: Jede Kontaktstelle ist eine potentielle Fehlerquelle.
1) Wie minimiert man deren Anzahl?
2) Wie kann man sie erkennen und beseitigen/überbrücken, falls sie mal zuschlagen?

Es gibt Kontakte, die man um die einzelne Ader drumklemmt und die sich durch die Isolation stechen. Damit könnte man die einzelnen Slaves an die durchlaufenden Busleitungen hängen. Da das für die durchlaufende Ader keine Kontaktstelle ist, die aufgehen könnte, wären Unterbrechnungen im Bus damit weniger ein Thema. Ich weiß nur nicht, ob es sowas auch in feuchtigkeitsbeständig gibt und wie das auf Dauer mit dem Gerappel zurechtkommt.

Reinhard · 29.03.2023

@beate nehmen wir hier wg. OT aus dem Thread ...

fho · 29.03.2023

Fanfan schrieb:
Jede Kontaktstelle ist eine potentielle Fehlerquelle.

Das ist ja auch ne Wissenschaft für sich. Ich bin da nicht mega firm drin, aber ich glaub die Lehrmeinung da ist, dass Crimpverbindungen "besser" sind als gelötete. Die sind soweit ich weiß wasserdicht und zumindest bedingt mechanisch belastbar. Im Vergleich dazu können sich Lötstellen durch Vibration freiarbeiten, was aber nur heißt, dass man die besser zugentlasten muss.

Hilft natürlich alles nicht wenn man an ner Lampe nur zwei Lötösen hat. Aber die andere Seite am CAN Verteilerboard wäre dann ein gecrimpter Stecker.

Leicht OT: Professionelle Crimpzangen sind auch echt teuer ... da bezahlt man locker mal nen paar Hundert Euro für eine Zange die genau einen Steckertyp crimpen kann. Aber dafür kriegt man halt ein Werkzeug das 100% der Zeit funktioniert und das ist im Großen und Ganzen halt mehr wert als wenn Karl der Crimper sich bei jedem Stecker nicht sicher sein kann ob er das richtig gemacht hat.

Tragwas · 29.03.2023

Ich habe mit CAN-Bus noch nicht gearbeitet, aber schon Interesse Erfahrungen damit zu sammeln und dann eventuell auch CAN-Bus Geräte zu entwickeln. Damit ich mir besser vorstellen kann, worin die Herausforderung und der Reiz von CAN-Bus Verwendung liegt, müsste ich als Arbeitsgrundlage zunächst ein minimales Beispiel-Protokoll verstehen. Im zweiten Schritt wollte ich dann verstehen, welche Probleme (wie z.B. Inkompatibilitäten) bei Erweiterungen gegebenenfalls auftreten können.

Gibt es da einen Entwurf, für ein Beispielprotokoll, welches im Velomobil eingesetzt werden könnte? Welche Geräte könnten/müssten entwickelt werden? Welche bestehenden Geräte könnten kompatibel eingebunden werden? Soweit ich "weiß" benutzen einige Pedelec Motorsysteme (Bosch) einen CAN-Bus. Kann es sein, dass viele CAN-Bus Systeme proprietär sind und absichtlich bezwecken Barrieren gegenüber Bastlern und "Marktbegleitern" in der Nutzung zu schaffen?

RobertS · 29.03.2023

fho schrieb:
…
Leicht OT: Professionelle Crimpzangen sind auch echt teuer ... da bezahlt man locker mal nen paar Hundert Euro für eine Zange die genau einen Steckertyp crimpen kann. …

Der Unterschied zwischen gutem Hobby und gutem Profiwerkzeug ist die Härte der Crimpbacken. Bleibst du unter 1500 Crimpungen pro Monat wirst du auch mit einer guten Hobbyzange glücklich.
Als Zugentlastung und Knickschutz setz ich gerne Heißkleber und Schrumpfschlauch ein. Die Crimpung mit Heißkleber auffüllen, nicht übertreiben, dann Schrumpfschlauch drüber und Schrumpfen.

fho · 30.03.2023

Tragwas schrieb:
Gibt es da einen Entwurf, für ein Beispielprotokoll, welches im Velomobil eingesetzt werden könnte?

Ne, ich hab mir da bisher hauptsächlich auf Hardware Ebene darüber Gedanken gemacht. Ich denke so ein Protokoll sollte aber möglichst einfach gehalten werden.

Design Philosophie

Ich sammel mal nen paar "Stichpunkte" wie ich mir das "philosophisch" vorstellen würde, in Reihenfolge meiner wahrgenommenen Wichtigkeit:

Einfach - Wir sind kein Millionenschweres Unternehmen, Komplexität ist der Tod
Robust - Da hängen Sicherheitskritische Endgeräte dran (Lichter, im Extremfall Bremsen)
Erweiterbar - Neue Geräte sollen relativ einfach eingebunden werden können

Wenn man das erstmal so festhält und bei Kompromissen im Hinterkopf behält steht man mMn schon mal ganz gut da:

Beispiel 1: Theoretisch könnte man das so bauen, dass jedes Licht elektronisch überwacht wird um zu schauen ob es wirklich angegangen ist. Das wäre Robust ... in der Praxis ist es aber relativ egal, weil das System vom Fahrer "überwacht" wird. Dann ist es erstmal Einfacher kein Feedback im Protokoll einzuplanen. Im Zweifelsfall wird der Fahrer das Licht nochmal anschalten.

Beispiel 2: Theoretisch könnte man sich ein elaboriertes System mit automatischer Entdeckung neuer Endgeräte überlegen. Dazu eine grafische Oberfläche zur Konfiguration in der der Anwender neue Endgeräte nur "zusammenstöpseln" muss. Wäre super Erweiterbar, definitiv. Ist aber mit beschränkten Mannstunden erstmal utopisch. Dementsprechend würde ich für eine erste Version erstmal davon ausgehen, dass sich das an technisch versierte Anwender richtet die auch mal die Arduino IDE aufmachen und ein paar Zeilen Code schreiben können.

Protokoll Entwurf

Damit im Hinterkopf würde ich als einen ersten Entwurf folgendes Protokoll, angelehnt an Zigbee, vorschlagen:

Knoten - Jeder Knoten hat eine eindeutige 8bit Adresse (256 Nodes) und hat Eingabe und Ausgabe Kanäle die wiederum durch eine 8bit Adresse adressiert werden. Beispielhaft:

YAML:

front_node (0x01)
inputs:
  - turn_signal_left (0x01, bool)
  - turn_signal_right (0x02, bool)
  - high_beam (0x03, int8)
  - low_beam (0x04, int8)
  - horn (0x05, bool)
  - air_vent (0x06, int8)
  - ...
outputs:
  - wheel_rpm_left (0x01, int16)
  - wheel_rpm_right (0x02, int16)
  - temperature (0x03, int8)

Wenn ich das richtig sehe, kann man einfach bis zu 8 Byte lange Pakete über den CANBus schicken (und die Bibliothek und die Hardware kümmern sich dann darum, dass die ankommen). Eine Nachricht/ein Paket um die Lichter vorne einzuschalten würde dann aus einem 3-Tuple bestehen:

Code:

(SET, 0x01, 0x03, 256)

  ^    ^     ^     ^
  |    |     |     +-  Neuer PWM Wert (256 -> voll an)
  |    |     +-------  Zielkanal (high_beam)
  |    +-------------  Zielknoten (front_node)
  +------------------  Update Nachricht

Zeitgleich sendet jeder Knoten periodisch den aktuellen Wert der Ausgaben an alle Knoten am CANBus:
(Caveat: Ich glaube das Broadcast da Standard ist, so genau hab ich mir das noch nicht angeschaut)

Code:

(STATE, 0x01, 0x01, 102)

   ^     ^     ^     ^
   |     |     |     +- Aktueller RPM Wert
   |     |     +------- Quellkanal (left_wheel_rpm)
   |     +------------- Quellknoten (front_node)
   +------------------- Status Nachricht

Wie oft diese Nachrichten gesendet werden ist dem Benutzer überlassen (Einfach), während die Raddrehzahl 100x pro Sekunde gesendet wird interessiert die Temperatur höchstens einmal pro Sekunde.

Das Ganze würde ich mit MessagePack packen, einfach weil ich damit gute Erfahrung gemacht hab und man so relativ einfach dasselbe Datenformat in C (auf den Arduinos) und zB in Java (auf nem Android) nutzen kann. Sobald eine "CANimVM" Arduino Bibliothek existiert wäre das dann relativ einfach zu nutzen. Ich geh etwas davon, dass man einen leistungsstärkeren Mikrocontroller "in der Mitte" hat der die "dummen" Verteiler verwaltet:

C:

// list of nodes
NODE_FRONT = 0x01;
NODE_HANDLE = 0x02;

// list of channels
HIGH_BEAMS = 0x03;          // channel in front node
HIGH_BEAM_TRIGGER = 0x05;   // channel in handle node


void loop() {

    // receive and handle CAN packets
    while(msg = CANimVM.available()) {
        
        // if the high beam trigger is pressed ...
        if(msg.node == NODE_HANDLE && msg.channel == HIGH_BEAM_TRIGGER) {
            bool high_beam_state = CANimVM.getBool(msg);
            
            // ... set high beam state to the new trigger state
            CANimVM.setPWM(NODE_FRONT, HIGH_BEAMS, 255 * high_beam_state);
        }
    }
}

(Das ist jetzt komplett an den Haaren herbeigezogen, ich seh aber auch nicht warum das nicht so einfach sein sollte.)

Zusammenfassung

Wenn ich jetzt, sofort, ein Protokoll erdenken sollte würde ich das so einfach wie möglich halten und die "Verantwortung" in die Hände des Anwenders legen. Dabei kommt uns zugute, dass CANBus von Haus aus sehr robust ist und zB Bestätigung von Nachrichten und Prüfsummen eingebaut sind.

fho · 30.03.2023

Tragwas schrieb:
Kann es sein, dass viele CAN-Bus Systeme proprietär sind

Ja

Tragwas schrieb:
absichtlich bezwecken Barrieren gegenüber Bastlern und "Marktbegleitern" in der Nutzung zu schaffen?

Nein

Wenn Bosch da nicht irgendwelches Schindluder treibt kochen die da auch nur mit Wasser. Sprich, sie nutzen dieselben CAN Chips wie jeder andere, damit ist das grundlegende Protokoll dasselbe und theoretisch kann man die Nachrichten mithören und damit kommunizieren.

Auf der anderen Seite werden die aber auch nen Teufel tuen und veröffentlichen wie man deren Motoren ansteuert, sprich man müsste sich wirklich an nem funktionierenden System dazwischenklemmen und die Steuerbefehle reverse-engineeren.