Forum: Mikrocontroller und Digitale Elektronik CAN-Bus: Was passiert eigentlich...


von crazy horse (Gast)


Lesenswert?

Situation:
fremdes CAN-Netz, 2 (!) Adressen zugeteilt bekommen.
Die eine wird für die eigentliche Funktion benötigt, über die andere 
will ich Parametrierdaten schicken und ggf. ändern.
Beisp:
ID=0x720 Prozessdaten (20ms)
ID=0x721 eingestellte Parameter, kommt nur einmal/s

Und nun die eigentliche Frage: Was passiert, wenn ich von einem 
PC-Dongle einen frame mit ID=0x721 schicke? Die Daten würden dann im 
EEPROM gespeichert.
Spricht irgendwas dagegen?
Es wäre nicht unbedingt nötig, dass die Daten auch im laufenden Betrieb 
angezeigt/geändert werden können (habe noch andere Schnittstellen), wäre 
aber schöner und bequemer.
Den einzigen Problemfall, den ich mir im Moment vorstellen kann, dass 
beide exakt im gleichen Moment mit gleicher ID versuchen zu senden, das 
kann man praktisch aber ausschliessen, da vom Gerät wie gesagt nur 1/s 
gesendet wird, vom PC aus überhaupt nur einmal.
MCP2515 + ATMega32.
Alle Kontras willkommen!

von Stefan W. (wswbln)


Lesenswert?

Hi,

verstehe ich das richtig, dass Du 2 Datenquellen hast, die Nachrichten 
mit der selben ID verschicken wollen? Das wäre ungut!

Versuche mal eine dritte dritte ID zu bekommen, etwa so:
0x720 Prozessdaten
0x721 eingestellte Parameter (Report)
0x722 einzustellende Parameter (Setup vom PC)

Wenn das nicht geht, brauchst Du irgendeine Form von Protokoll (und 
wenn's nur ist jeweils eine Parameter-Nachricht vom Gerät abzuwarten und 
gleich danach versuchen die Nachricht vom PC abzusetzen - mit Timeout, 
damit man den Versuch bei vollem Bus ggf. abbricht, bevor man mit der 
nächsten Nachricht vom Gerät kollidiert).

von unsichtbarer WM-Rahul (Gast)


Lesenswert?

Irgendwie sehe ich das Problem nicht ganz:
Du hast 2 CAN-IDs. Auf der einen werden dir Prozessdaten geschickt und 
die andere wird dafür verwendet, Parameter deines Gerätes zu ändern.

Es ist egal, woher ein CAN-Frame mit deinen IDs kommt.
Wenn dein Controller auf die beiden IDs reagiert (sie herausfiltert und 
für sich als gültig befindet), dann ist die Quelle für ihn 
uninteressant.
Die wird im CAN-Frame ja auch gar nicht mitübertragen.
Wenn dein Controller jetzt selber etwas an diese ID schickt, müsste er 
es meiner Meinung auch selbst empfangen (Datenblatt...).

Wo siehst du denn das Problem?
IDs im CAN-Bus sollten nur für eine Funktion verwendet werden. Diese 
kann aber auch von mehreren Controllern empfangen und ausgewertet werden 
(CAN-Sniffer sind meist sehr passiv...).

von crazy horse (Gast)


Lesenswert?

@Stefan: nein, ich bekomme keine weiteren IDs. Und dass es dann jenseits 
aller Sorgen wäre, ist mir auch klar. Aber nicht immer bekommt man 
alles, was man sich wünschst...
@Rahul:
mein Gerät SENDET auf ID 0x720 seine Sensordaten und auf 0x721 
Parametrierdaten (Offset, Steilheit, Entprellzeit etc), darauf könnte 
ich zur Not auch verzichten, schöner wärs aber, wenn ich die im 
Einricht/Servicefall alle sehen könnte.
Selbst geschickte Frames werden zwar vom Transceiver empfangen und auch 
vom CAN-Controller ausgewertet, ob korrekt auf dem Bus, aber nicht als 
empfangene Botschaft an den MC weitergeleitet, oder (?). Habe mich 
jedenfalls noch nie aktiv darum gekümmert, gesendete Botschaften aus dem 
Empfangsbuffer zu lesen.
Die Information auf 0x721 wird von niemand anders ausgewertet. Und 
selbst wenn - es sind ja auch korrekte Daten. Ab dem Zeitpunkt, wo sie 
von extern eingespielt werden, sind es ja auch automatisch aktuelle 
Betriebswerte vom node. Ich sehe einfach keine anderen Probleme ausser 
einem extrem unwahrscheinlichen gleichzeitigen Zugriff.
Ich glaube, ich probier es einfach mal aus.

von Henrik (Gast)


Lesenswert?

Es müsste eigendlich funktionieren, da der CAN ja Low als dominanten 
Pegel kennt. Das zwei Sender nicht die gleiche ID benutzen drüfen ist 
deshalb festgelegt, damit einer im Fall des gleichzeitigen Sendens 
bereits beim Senden der ID mitbekommt, dass ein zweiter ebenfalls 
sendet. Im Datenteil sollte das nicht passieren, da dann möglicherweise 
keiner von beiden mehr abbricht. Im schlimmsten Fall stimmt dann aber 
die Checksumme nicht und die Nachricht wird verworfen, denke ich mal. 
Was ein Problem sein könnte ist, dass einige CAN-Controller auf ihre 
eigene ID warten, (Remote-Request) um zu senden. Wie sich der Controller 
aber verhält, wenn er eine Nachricht seiner ID detektiert bei der das 
R.-R.-Bit nicht gesetzt ist, weiß ich nicht.
Wenn der zuletzt genannte Fall kein Problem darstellt und das 
gleichzeitige Senden unwahrscheinlich ist, ist es zumindest einen 
Versuch wert.

Henrik

von crazy horse (Gast)


Lesenswert?

Gemacht - funktioniert bestens :-)

von A.K. (Gast)


Lesenswert?

Konflikt jenseits der ID müsste wohl zu einem Error-Frame führen. Bei 
hinreichend Retries mit exakt gleichem Timing kann das dann bis zu 
"error passive" so weitergehen. Theoretisch.

von crazy horse (Gast)


Lesenswert?

allenfalls könnte es ja in dem Moment was passieren, wenn ich mit dem PC 
am Bus bin und Daten verschicke. Und dann sehe ich ja auch im 
receive-Fenster, ob der  unwahrscheinliche Fall eines Aufhängers 
eintritt (ich glaube, eher habe ich einen Sechser im Lotto durch 
Versehen der Lottogesellschaft, da ich gar nicht spiele).
Also, wie gesagt, prinzipiell funktionierts, der CAN-Controller merkt 
gar nichts davon, dass ich auf einer Sende-ID auch empfange.

Bitte 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
Noch kein Account? Hier anmelden.