CAN Remote Frames antworten

[Bert (Gast)]

Hallo,

ich habe zwei CAN Knoten welche miteinander Kommunizieren. Knoten 1 
liest ständig Sensorwerte aus.

Knoten2 benötigt die Sensorwerte gelegentlich. Durch eine Anfrage vom 
Knoten 2 zum Knoten 1 möchte ich die Sensorwerte Anfordern. Aus der CAN 
Theorie sollte das mit Remote Frames machbar sein.

Ablauf:

Knoten 2 schickt Remote Frame mit ID 0x002
Knoten 1 empfängt das Remote Frame in einer ISR und schickt die Daten 
des Sensors mit der gleichen ID 0x002 an Knoten 2 zurück.

Liege ich damit richtig oder wird von Remote Frames abgeraten ? Gibt es 
andere Vorschläge Daten mittels CAN abzufragen ?

[rcc (Gast)]

Lass die Sensorwerte einfach zyklisch senden und spar dir die Mühe und 
Probleme mit den Remote-Frames.

[henning (Gast)]

Dafür sind die Remote-Frames da. Zu beachten ist nur, dass das 
Remote-Frame keine Daten enthält, aber im Feld der Framegröße die Größe 
des folgenden Datenframes drin steht. Soll der Knoten 1 mit 4 Bytes 
antworten, muss es auch im Remoteframe stehen.

[Bert (Gast)]

Das Senden der Remote Frames klappt, genauso das Empfangen. Das Problem 
ist nun, dass ich sofort eine Antwort auf das Remote Frame bekomme, aber 
immer mit den Daten 0x00. Das heißt schon bevor die ISR des Message 
Objectes aufgerufen wird, antwortet der Knoten aber halt mit null Daten. 
Wird die Nachricht nicht in der ISR des Messages geladen ?

[holger (Gast)]

http://www.microcontrol-blog.net/2013/03/finger-weg-von-can-remote-frames/

[Rudolph (Gast)]

Eine Möglichkeit ist noch mit einer Botschaft direkt an andere zu 
triggern.
Ich habe eine Anwendung bei der mein Auftraggeber mehrere Echo-IDs 
definiert hat um festzustellen, ob die Frames wirklich sauber angekommen 
sind.

Also sowas:
ID 0x500 -> 0x510
ID 0x501 -> 0x511

In der ISR kopiere ich die Daten und setze ein Flag, in der 
Hauptschleife wird dann als nächstes die Anwort gesendet.
Damit bekommen ich eine Anwort in deutlich weniger als 1ms auf den Bus.

Zusätzlich gibt es noch IDs die über die Hauptschleife getimed ablaufen, 
also alle 50ms oder so gesendet werden.

[Florian (Gast)]

Ich habe das Problem im Moment durch zyklisches Senden gelöst. 
Funktioniert ganz gut. Nur finde ich es etwas "unsauber" gelöst, da ich 
die Werte wirklich selten brauche. Ich werd mich wohl noch durch 
Literatur durchbeißen müssen.

[rcc (Gast)]

Wenn dann mach sowas wie Rudolph beschrieben hat bzw. lies dich mal in 
das Konzept hinter UDS ein. Das bekommt man zig mal schneller und 
schöner stabil ans Laufen als Remote-Frames, ganz zu schweigen vom 
Fehlersuchen

[Ben (Gast)]

Florian schrieb:
> Ich habe das Problem im Moment durch zyklisches Senden gelöst.
> Funktioniert ganz gut. Nur finde ich es etwas "unsauber" gelöst, da ich
> die Werte wirklich selten brauche. Ich werd mich wohl noch durch
> Literatur durchbeißen müssen.

Als ich das erste Mal mit CAN in Berührung kam war ich auch verwundert 
dass der Bus so zugemüllt wird. Jeder beteiligte Knoten haut einfach 
ständig seine Infos raus...

Mittlerweile hab ich mich daran gewöhnt.
Das machen immerhin alle, wirklich alle großen Automobil-OEMs so, von 
daher ist das wohl Standard. Und vor allem: einfach und effektiv.

UDS ist für dein Vorhaben Oversized und auch nicht so einfach zu 
Debuggen. Wenn alle Infos zyklisch auf dem Bus vorhanden sind kannst 
einfach mit einem PC mitsniffen.
Lass einfach so wies momentan ist.