CAN BUS Datenübetragung von mehrere Sensoren zum Steuergerät

Gast #3882999
Lesenswert?

Hallo zusammen,

bin ziemlich ein Can-neuling und würde gerne fragen, welche Art von 
nachrichten ist am besten geeignet wenn ich ein Netzwerk mit eine kleine 
Anzahl Sensoren habe, die Daten an einem Steuergerät senden. Ich habe 
bis jetzt BAM Nachrichten und peer to peer gefunden. Die BAM Nachrichten 
haben kein Acknowledge, also dachte ich ist eventuell eine Sicherheits 
Lücke. Ich weiss nicht ob die Daten angekommen sind. Bei den peer to 
peer habe ich ein Adressen Problem. Ich musste alle Nachrichten an 
meinen Steuergerät schicken, der eine feste Adresse haben muss. Die 
Adresse darf sie also nicht ändern. Woher sollen sonst die Sensoren 
wissen wo sie die Daten verschicken müssen. Das begrenzt meine 
Möglichkeiten, finde ich. Alle Steurgeräte müssen ab Werk feste Adressen 
bekommen, die sich nicht ändern dürfen. Wie sollen dann die sensoren 
wissen welche Adresse ist gerade ein Steuergerät? Hilfe!!!!

Bin dankbar für Vorschläge
Gast #3883016
Lesenswert?

CAN arbeitet nicht mit Adressen sondern über IDs. Das bedeutet, dass 
jeder Sensor mit einer anderen ID senden muss und das Steuergerät muss 
halt unterschiedliche IDs auswerten. Du kannst doch bestimmt die ID der 
Sensoren frei vergeben? Und im Steuergerät sollte es erst rech kein 
Problem sein.
Gast #3883029
Lesenswert?

Normalerweile wird beim CAN nicht das einzelne Gerät adressiert. Es wird 
der entsprechenden Nachricht eine ID gegeben. Und das Steuergerät 
beispielsweise sucht sich selbst die IDs raus, auf die es reagieren muß.
Beispiel:
Du hast du 3 Temperatursensoren, der erste sendet seine Temperatur mit 
der ID 0x300 auf den Bus, der zweite mit der 0x310, der dritte mit der 
0x320.
Wenn sich ein Steuergerät für die Temperatur an Sensor 2 interessiert, 
muß es eben die 0x310 auslesen und auswerten. Ein anderes Gerät könnte 
dann die 0x300 und 0x320 auslesen für Sensor 1 und 3. Und wenn du im 
Flur noch ein Display anbringst, kann dieses parallel dazu auch alle 
drei IDs mitschreiben, um alle drei Temperaturen anzuzeigen.
Auf diese Weise wird das normalerweise gehandhabt (die Zahlen sind nur 
Beispiele). Keine Geräteadressen, sondern die Nachrichten selbst 
bekommen ihre ID. Wenn ein Sensor z.B. Temperatur und Luftfeuchte mißt, 
kann er auch zwei (oder mehr) verschiedene IDs versenden (0x300 für die 
Temperatur und 0x400 für die Luftfeuchte zum Beispiel).
Ich hoffe, ich konnte das Prinzip einigermaßen verständlich rüberbringen 
:-)
Gast #3883064
Lesenswert?

Uau, danke für die super schnelle Antworten.
Die ID ist dann die PDU Format? In PDU Specific schreibe ich die globale 
Adresse 255? Richtig?
Und ich kann mir die IDs selber suchen? Unabhängig der Industrie Zweig?
Gast #3883080
Lesenswert?

Vicky schrieb:
> Uau, danke für die super schnelle Antworten.
> Die ID ist dann die PDU Format? In PDU Specific schreibe ich die globale
> Adresse 255? Richtig?
> Und ich kann mir die IDs selber suchen? Unabhängig der Industrie Zweig?

Das klingt auch hier so, als wenn du von CANopen sprichst. Da kann ich 
dir aber leider nicht weiterhelfen. Damit habe ich noch nichts gemacht. 
Ich arbeite nur mit CAN, und ja, dort kann man beliebige IDs benutzen.
Zum Thema CANopen soll sich mal jemand anderes äußern, der was davon 
versteht :-)
Gast #3883175
Lesenswert?

Ok du nutzt also J1939, dann wird mir das auch mit der BAM klar. Wer 
genau spricht denn J1939? Die Sensoren oder das Steuergerät? Vermutlich 
das Steuergerät aber wenn es J1939 kann kann es auch CAN. Bei Sensoren 
ist CANopen ein gängies Protokoll.
Wie gesagt mach dir erst einmal klar welches Gerät welches Protokoll 
nutzt.
Gast #3883261
Lesenswert?

Vicky schrieb:
> ich würde alle, Steuergerät und Sensoren mit dem Protokoll SAE J1939
> programmieren. Sie sind alle eigene Entwicklung.

Worin siehst du den Vorteil J1939 zu nutzen anstelle von CAN pur? Du 
hast eher den großen Nachteil das Protokoll noch zu schreiben. Selbst 
wenn es schon einen J1939 Stack gibt, sehe ich bei solchen Anwendungen 
keinen Vorteil von J1939.
J1939 wird vor allem bei der Kommunikation mit Motoren verwendet. Also 
das Protkoll stammt aus einem ganz anderen Bereich und ist für Sensoren 
eigentlich nicht gedacht. Klar geht das aber warum?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren