www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN-Nachrichten nur bei Events oder zyklisch


Autor: Christian Ortlieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Wolf (mictronics) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: willivonbienemaya (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Je (frank5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Konrad Heisig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank W (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Ortlieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh hier hab ich die andere eMail eingetragen. Philipp ba4@cose... und
Philipp news@cose... sind ein und die gleiche Person

Gruß Philipp

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.