Liebe Experten, ich bin mir nicht ganz sicher, ob ich hier off topic bin, denn ich habe eine mehr grundsätzliche frage, die sich keiner speziellen Hardware zuordnen läßt. Es geht um das versenden von CAN-Nachrichten in einem (CANopen-)System. Stellen wir uns vor, es gibt einen Master (z.B. ein Bediengerät) und einige Slaves (irgendwelche Steuergeräte). Was macht nun mehr Sinn : 1. Nachrichten nur dann zu senden, wenn am Bediengerät etwas passiert (z.B. ein Bediener eine Taste drückt), also die Nachricht : Bediener hat Taste für Funktion xy gedrückt. --> event-orientierter Ansatz 2. Nachrichten über den Status einer Funktion zu schicken und zwar zyklisch, d.h. wenn ein Bediener eine Taste drückt wird die Nachricht : Funktion xy ein geschickt, diese wird dann zyklsch wiederholt (bis sich wieder etwas ändert und der neue Status dann geschickt wird) --> status-orientierter Ansatz Eigentlich ist der vent-orientierte Ansatzt aus meiner Sich einfacher zu handeln, gerade wenn es mehr als ein Eingabegerät gibt. Das einzige Argument, dass immer wieder für den status-orientierter Ansatz ins Feld geschickt wird ist ein Sicherheitsargument. Wenn, warum auch immer, ein Slave (der z.B. eine Presse einschaltet) das Kommando zum Abschalten der Press (kein Notaus, normaler Betrieb) nicht empfängt, kann das zu unschönen Situationen führen. Beim status-orientierter Ansatz wird das beim nächsten zyklischen Senden des Status (Presse aus) geheilt, beim event-orientierter Ansatz dagegen muß ich die entsprechende Taste nochmal drücken. Hat jemand (der bisher die Geduld hatte lesen) Erfahrungen oder Tipps ? Danke Christian
Ich habe das bei mir im Auto kombiniert. (hatte vorher keinen CAN Bus) Wenn ich die Zentralverriegelung öffne oder schließe wird das sofort gesendet bei Statusänderung. Zusätzlich wiederhole ich den Status noch alle 30s falls wirklich mal ein Steuergerät die Nachricht nicht erhalten haben sollte (kam aber noch nie vor), bei den weniger kritischen Sachen sende ich nur die Events, was bisher noch nie zu Problemen führte. Die Frage ist wohl immer wie sicherheitsrelavant die Anwendung ist. Wenn es sehr sicher sein muss, sollte man vielleicht noch darüber nachdenken die Kommunikation in beide Richtungen laufen zu lassen, also nicht nur Befehl senden, sondern anschließend auch den Status des Slaves abfragen um zu schauen um es ankam und befolgt wurde. Gruß Philipp
Das ganze ist eine Frage der Sicherheit. Sollte dein System eher sicherheitskritisch sein, dann würde ich zyklische Übertragung benutzen, damit sichergestellt ist, das zu jedem Zeitpunkt jedes Steuergerät einen definierten Status vom Master bekommt. Ein eher unkritisches System kann man azyklisch laufen lassen, also Event basierend. Oder man kombiniert beides. Das heist kritische Meldungen überträgt man zyklisch und eher unkritische nur bei Bedarf.
ich habe oft diese kombination gesehen: eventgesteuert mit zusätzlicher totmannabfrage. also zyklisch nachrichten, die beantwortet werden müssen um zu testen ob die hardware noch lebt.
und noch ein 3.Ansatz - remote-frames. Die "Datenerzeuger" machen gar nichts, bis irgendeine Datensenke diese Information tatsächlich benötigt und anfordert. Vorteil: unnötiger Datenmüll unterbleibt, es steht mehr Buskapazität für anderen traffic zur Verfügung. Hat natürlich auch wieder Nachteile: es werden 2 frames für einen Datensatz benötigt (das ist bei anderen CAN-ähnlichen Systemen besser gelöst, da ergänzt der angesprochene Knoten direkt den remote-frame) und es entstehen zus. Verzögerungen. Die eierlegende Wollmilchsau gibts also auch hier wieder mal nicht :-)
Den 3. Ansatz habe ich auch im Auto gemacht. Zb wird das Modul das unter anderm Bordspannung misst nur dann nach der Bordspannung gefragt, wenn das Display vorne diese auch anzeigt oder sie anderweitig benötigt wird. Dafür gibt es bei CAN ja das RTR Paket. Gruß Philipp
Hallo Das klingt ja interessant was ihr da in Euren Autos realisiert habt! Habt Ihr dieses Projekt irgendwo Dokumentiert,dass man mal sehen kann wie sowas selbstgebautes im Auto funzt? Gruss Frank
@Frank Ich habe es nicht weiter dokumentiert. Sind mehrer Module. Fast immer Mega8 mit MCP2515 und dann halt das drumrum was gemacht werden soll. Für genaueres einfach ne Mail schreiben oder so, wird hier glaube ich ein wenig OT. Gruß Philipp
aufgebohrter 996er-Motor im 997er Porsche. Leider funktioniert der 996-Motor nicht mit dem 997-Motorsteuergerät. Und der CAN-Bus des 996er funktioniert nicht mit dem Rest des Autos, da hat Porsche ganz kräftig gewürfelt. So langsam funktioniert aber alles :-)
Du bist also am Original CAN? Leider hat mein Auto sowas ja nicht (91'er Honda Prelude) Wie sind so Dinge wie zB Drehzahl usw eigentlich auf den Bus gelegt? Wird das zyklisch gesendet? Kannst du vielleicht mal ein wenig grob umreißen wie sowas Herstellerseitig implementiert ist? Also Struckturen usw? Vielen Dank Gruß Philipp
jo, wird zyklisch alle 10ms gesendet. Die Drehzahlinformation steckt in einer Botschaft vom Motorsteuergerät, aufgeteilt in 2 Bytes. Es sind allerdings 8 Datenbytes in jeder Botschaft, es werden also mit jeder Botschaft mehrere verschiedene Werte übertragen. Tja, und dann muss man noch wissen, was die Zahlen physikalisch bedeuten. Bei der Drehzahl z.B. wird der volle Wertebereich 0...65535 ausgenutzt, die tatsächliche Drehzahl entspricht 1/4 des Wertes, also 0...16384U/min.
Währe es nicht das Einfachste, die sicherheitsrelevanten Daten einfach vom Empfänger zurückschicken zu lassen, so dass der Sender sicher weiß, dass seine Nachricht angekommen ist ... erzeugt zwar auch mehr Traffic, aber nicht so viel wie ein zyklisches Senden. Gruß Konrad
Ich würde den Event Ansatz bevorzugen. Das ergibt einfach weniger Last auf dem Bus. Datenkollisionen sind bei canOpen ja kein Problem. Nur die Durchsatzrate könnte in die Knie gehen. Wenn ein canOpen Knoten verloren geht, dann muss die SW das ja sowieso schnell erkennen. Das ist eine der Grundfunktionen von canOpen. Und wenn Du wirklich was sicherheitskritisches bauen willst, dann musst Du das sowieso einfehlersicher aufbauen. Sprich - Die Taste zum auslösen deiner Presse ( oder zumindest der Sicherheitsschalter vor dem Zugriffsschutz in die Presse ) muss zweikanalig und drahtbruchsicher ausgeführt sein. Gruss Frank
So, erst mal vielen Dank für die vielen Antworten (finde ich ja bemerkenswert, daß jemand einen CAN-Bus in seinem Auto nachrüstet). Für mich stellt sich eigentlich am Ende eine Frage : ist es denkbar, dass eine CAN-Nachricht unbemerkt nicht den gewünschten Empfänger erreicht ? Meiner Meinung nach ist das denkbar, da ein Sender zufrienden ist, wenn irgendein Knoten seine Nachricht acknowledged. Daher müßte man wohl, wenn man einen event-Ansatz einsetzt, selber etwas implementieren, um zu erkennen, ob eine Nachricht wirklich da angekommen ist, wo sie hin sollte. Dann könnte man sich das zyklische Senden sparen. Gruß Christian
Ich beziehe bei mir den Status immer von dem Endknoten und gehe nicht davon aus, das der BEfehl schon ausgeführt sein wird. Also zum Beispiel drücke ich auf dem Touchdisplay meinetwegen auf "Heizungsluft nach oben" durch den Druck wird eine CAN Nachricht zu meinem Heizungssteuergerät gesendet, das die Lufdüsen verstellt werden sollen, das Heizungssteuergerät schickt quasi als Antwort darauf seinen Status und der Pfeil mit der Luft zum Kopf leuchtet. Als Benutzer merkt man natürlich nichts von dierser Kommunikation weil es so schnell geht. Da sieht es als als würde der Pfeil durch den Druck leuchten. Wäre jetzt die Verbindung getrennt, würde der Druck keine Änderung der Anzeige verursachen. Ich denke man kann nicht generell sagen, was wobei die beste Lösung ist, aber es ist ja kein Problem es zu kombinieren und sich etwas für die ganz spezielle Anwendung zu überlegen. Gruß Philipp
Oh hier hab ich die andere eMail eingetragen. Philipp ba4@cose... und Philipp news@cose... sind ein und die gleiche Person Gruß Philipp
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.