ISOBUS - CAN PGN Nummern und Daten

Hallo

Ich hab ein wenig angefangen mich mit dem CAN Bus zu beschäftigen.
Dazu hab ich eine Platine mit dem MCP2515 - MCP2551 und nem AVR Controller entworfen.
Ich möchte eine ISOBUS Anwendung Implementieren.

Nun zu meinen Problemen:
Welches Nachrichtenformat wird beim ISOBUS verwendet Short, oder Long Format mit EID's, oder beide gemischt?

Mit welcher Geschwindigkeit ( Bit / Sek ) läuft der ISOBUS oder ist das nicht festgelegt ? Welche Busraten sind möglich?

Bei vielen ISOBUS Anwendungen werden PGN Nummern angegeben. Wo kann ich die bei den ID bzw. EID wieder finden?

Laut Definition gibt's ja bei CAN keine Knoten Adressierung, trotzdem gibt es da Remote Bits - Ich meine irgendwo müssen ja somit auch die Knoten bzw. Daten Endpunkte irgendeine Art von Adresse haben, damit sie wissen, das sie auf eine Remote Anfrage antworten sollen. Woher kommt die? Wie wird sowas in einem CAN Bussystem ausgehandelt?

Wie kriege ich zu den einzelnen PGN Nummern raus welche Daten sich in welchem Format sich in den Daten Bytes einer CAN Message befinden? Wie viele Bytes einer Message werden dafür genutzt?

Nun noch ein ganz triviales Problem - Welche Steckverbindungen werden in der Traktorkabine für die Anbindung an den ISOBUS verwendet? Wo kriegt man die her?

Für CAN Profis sind das sicher Peanuts, aber ich mach da meine ersten Schritte in diesem Bus System und allein schon der MCP2515 war da ein ganz schöner Brocken.

Hi,

ich kenn die Probleme, die man beim ersten basteln mit dem MCP2515 hat nur zu gut :)
Ich bin auch mehr oder weniger dabei einen CAN-Bus mit einem MCP2515, MCP2551 und einem AVR zu entwerfen. Nur ich wollte das erstmal nur ganz klein als Sensornetzwerk im Haus haben ;)
Und das zieht sich (wegen akutem Zeitmangel) extrem in die Länge.....
Zum ISOBUS....schau mal hier:

http://de.wikipedia.org/wiki/ISOBUS

ob dir das weiter hilft.
Zum Thema CAN-Bus kann ich dir dieses Buch empfehlen. Das hat mich bei meinen ersten Gehversuchen mit dem CAN-Bus auch begleitet:

http://www.elektor.de/products/books....1920556.lynkx

Das habe ich mir auch bestellt und da wird der CAN-Bus sehr gut erklärt.
Ein CAN "Byte" besteht aus einem Startbit, einem Messageidentifier, der eigentlichen Nachricht (bis max. 8 Byte), einer CRC und noch son bischen Hühnerfutter. Ganz auswendig weiß ichs nicht. Da kann ich dir erst helfen wenn ich Zuhause bin und in das Buch schauen kann ;)
Du kannst ja in jedem MCP2515 einen Filter reinschreiben. Dieser Filter filtert Daten, die einen anderen Messageidentifier haben als der der im Filter steht, aus. Dadurch kannst du deinem Datenpaket einen Identifier von z.B. 0x02 geben und nur die MCP2515 die in ihrem "Aceptancefilter" 0x02 stehen haben nehmen das Datenpaket an. Alle anderen ignorieren das Paket (aber sie empfangen es! Das ist ganz wichtig. Jeder Knoten empfängt jedes Paket. Nur anhand der Filter entscheidet der Knoten ob er es haben will oder nicht).
Remote Bits werden in einem Remote-Frame gesendet und ein Remoteframe enthält keine Daten. Mit diesem Frame wird eine Datenanfrage gestellt und der dazu notwendige Identifier mitgeliefert. Dieser Identifier wird dann nachher für die Daten, die als Antwort auf die Remoteanfrage gesendet werden, mitgeschickt, sodass der Knoten der den Remote-Frame gesendet hat auch seine Daten bekommt.
Zu deinen Fragen zum ISOBUS....les dir mal den Wikipedia Artikel durch ob da das drin steht was du brauchst ;)

Hoffe das hilft dir erstmal weiter. Wie gesagt ich arbeite hin und wieder selber mit der gleichen Hardware wie du und ich kenne deswegen deine Probleme :)

Edit:
Zum Stecker....in dem Wiki-Artikel habe ich gerade gesehen, dass die Stecker der DT-Reihe der Firma Deutsch verwendet werden. ;)

Hallo Kampi schonmal Danke für deine Antwort.

Das mit dem Message Identifier hab ich im Pronzip scon verstanden.
Wobei es da natürlich 2 Frametypen gibt. Einen mit einem 11 Bit Identifier und einen mit einem 29 Bit Identifier.

Der Frameaufbau ist mir im Prinzip auch klar.

Das mit den Filtern beim MCP2515 hab ich mir auch soweit angelesen und verstanden.
Wobei ich im ersten Schritt mal beschlossen habe alle Nachrichten durchzulassen und erst später zu filtern.

Das mit den Remoteframes war schon mal eine wichtige Info und neu für mich.
Was ich noch nicht verstehe ist, wie weis der Empfänger einer Remote Nachricht, das er gemeint ist und er die Daten zurückschicken soll?

Der Wikipedia Artikel kratzt sehr an der Oberfläche, lässt sich aber in keinster Weise über die verwendeten Nachrichtentypen oder Identifier aus.

Bei den Kabinensteckern sollen auch noch andere Typen verwendet werden, wäre interessant welche.

Ich hab auch schon mal in NMEA2000 reingeschaut, dort ist dann von sog. PGN die Rede ohne genau zu spezifizieren wo die nun im CAN Bus wieder auftauchen.

Das ELEKTOR Buch werd ich mir mal besorgen. Wobei die Elektor Bücher oft nur die absoluten Grundlagen behandeln und sehr auf ELEKTOR Projekte ausgelegt sind. Ob's bei diesem Buch anders ist - mal gucken.

Hab soeben das ELEKTOR Buch bestellt - Mal gucken.

Hi,

Zitat:

---

Zitat von wkrug

Das ELEKTOR Buch werd ich mir mal besorgen. Wobei die Elektor Bücher oft nur die absoluten Grundlagen behandeln und sehr auf ELEKTOR Projekte ausgelegt sind. Ob's bei diesem Buch anders ist - mal gucken.

---

dieses Buch geht halt von der Erfindung des CAN-Buses hin zum Aufbau der beiden Frames (Data und Remote) übers Bit-Timing bis zu Projekten mit PICs und dem MCP2515 (PICs sind mir egal, aber das andere ist recht interessant). Nur das Buch ist halt in Englisch (falls du es noch nicht gesehen hast ;) )

Zitat:

---

Zitat von wkrug

Das mit den Remoteframes war schon mal eine wichtige Info und neu für mich.
Was ich noch nicht verstehe ist, wie weis der Empfänger einer Remote Nachricht, das er gemeint ist und er die Daten zurückschicken soll?

---

Müsste ich nochmal genau gucken aber ich meine es wird ein Remote-Frame mit Identifier geschickt und der Empfänger mit dem zum Identifier passenden Filter "bearbeitet" die Remoteanfrage dann auch und schickt die Daten mit dem selben Identifier zurück.
Aber wie gesagt ich lese das heute nochmal nach und sage es dir heute/morgen nochmal genauer.

So ich habe nochmal in dem Buch nachgelesen.
In dem Buch steht auf Seite 62 folgendes:

"Nodes recieving remote frames and accepting them will send a data frame with the requested data but only one node can send the data."

Das heißt soviel wie, dass die Knoten den Remote-Frame empfangen und wenn sie ihn annehmen senden sie einen Data-Frame mit den angeforderten Daten.
Ein Absatz weiter unten steht (wenn ich es richtig übersetzt habe) folgendes:
Die Datenanfrage erfolgt nach dem Senden von zwei Frames. Als erstes wird ein Remote-Frame gesendet (RTR = 1) damit die Knoten wissen das Daten angefragt werden.
Der zweite Frame ist ein Data-Frame mit dem selben Identifier wie der Remote-Frame, welcher dann sagt welche Daten angefragt werden.
Der DLC des Remote-Frames muss der gleiche sein wie der DLC des Data-Frames der unmittelbar nach dem Remote-Frame gesendet wird (DLC = Data Lenght Code).
Wenn ein Remote-Frame und ein Data-Frame mit dem selben Identifier gleichzeitig am Bus anliegen, hat der Data-Frame IMMER Vorrang, weil das RTR Bit (welches zur Bus Arbitration gehört) 0 ist und die Frames mit dem niedrigsten Wert des Arbitration-Fields (Message-Identifier + RTR Bit) Priorität haben.
Das heißt eine Message mit einem Message-Identifier von 0x01 und einem RTR-Bit von 0x00 hat Vorrang zu einer Message mit Message-Identifier 0x01 und einem RTR-Bit von 0x01 (RTR = 0 signalisiert ein Data-Frame und RTR = 1 signalisiert ein Remote-Frame).

Hi Kampi,

Das das Buch in Englisch ist hat mich vor länger Zeit von der Bestellung abgehalten. Da es aber anscheinend doch was taugt, werd ichs mal versuchen.

Das mit den priorisierten Nullen hab ich mir schon gedacht - Ist ja auch bei der Adressvergabe so.
Was leider immer noch nicht beantwortet wurde ist die Sache mit den PGN Nummern und den zugehörigen Daten in den Datenbits einer CAN Nachricht.

Noch was, was ich meine verstanden zu haben, aber noch mal verifiziert haben möchte ist das Bit Timing des MCP2515.
Soweit ich das verstanden habe wird die Taktfrequenz ( z.B. 16MHz ) mit einem Vorteiler heruntergeteilt.
Dadurch ergeben sich pro Bit eine Anzahl von TQ's - Üblicherweise so um die 16.
Das Sync ist ja fest 1*TQ
Die anderen 3 Segmente müssen sich die restlichen TQ's aufteilen
In der Summe müssen aber die TQ's der einzelnen, eingestellten TQ Schritte für das PropSegment + PS1 +PS2 + und das eine Sync TQ wieder die Anzahl der TQ's pro Bit ergeben. - Hab ich das so richtig interpretiert ???
Ist es günstiger den Sample Point einmal abzufragen, ist die dreimalige Abfrage die bessere Option, oder ist das von der Busgeschwindigkeit abhängig.

Hi,

ob das Buch was taugt (im Sinne auf die Korrektheit usw.) kann ich dir nicht beantworten, weil ich selber nicht so der CAN-Experte bin :)
Was es mit den PGN Nummern auf sich hat weiß ich leider auch nicht....hab das bisher auch noch nicht gehört.
Zum Bit-Timing:
Ja genau der takt wird mit einem Prescaler geteilt. Dadurch entsteht der "Baud Rate Clock". Ein TQ ist dann ein Takt des Baud Rate Clocks.
Der Synch entspricht 1xTQ und ist fest. Das Prop_Seg und das Phase_Seg1 sind variabel von 1-8 und das Phase_Seg2 ist gleich lang wie das Phase_Seg1.
Und wenn du die ganzen TQs dann addierst hast du die Länge von einem Bit.
Dementsprechend kann ein Bit mind. 4 TQ lang sein (1x Synch, 1x Prop, 1x Phase_Seg1 und 2) oder max. 25 TQ (1x Synch, 8x Prop, 8x Phase_Seg1 und 2).
Kleine Beispielrechnung aus dem Buch:

TBit = TQ x (Synch_Seg + Prop_Seg + Phase_Seg1 + Phase_Seg2)

TQ = 2 x BRP / FOSC
TQ = 2 x 2 / 20MHz
TQ = 0,2µs

TBit = 8 x TQ (Es wurde festgelegt das 1 Bit 8 TQ lang sein soll)
TBit = 8 x 0,2µs
TBit = 1,6µs

NBR = 1 / TBit
NBR = 1 / 1,6µs
NBR = 625000bps
NBR = 625kB/s

Zu der Frage mit dem Sample Point kann ich dir leider keine vernünftige Antwort geben, weil in dem Buch nicht so genau auf den Punkt eingegangen wird. Aber das sollte für dich glaub ich auch nicht so ausschlaggebend sein.
Auf jedenfall wählst du aus wie lang ein Bit sein soll. Dies machst du durch die Wahl der TQs pro Bit.
Aber im Grunde hast du das schon richtig interpretiert :)
Ich nehme mal an du bist von dem Standpunkt ausgegangen, dass du eine fest definierte Länge des Bits gegeben hast und daraus die Anzahl der TQs herleiten willst.
Ich habe für mein CAN-Bus ein Mikrochip Tool verwendet um den ganzen TQ Rummel auszurechnen (war da ein wenig faul ;) ).

Edit:
Bzgl PGN...hast du das hier schon gefunden/gelesen?:

http://de.wikipedia.org/wiki/SAE_J1939

Der Link war gut!
Diese Grafik zeigt das was ich gesucht habe: http://de.wikipedia.org/w/index.php?...20090908102337
Ich hab mich auch schon ein wenig in das CAN Tutorial von "kreatives Chaos" eingelesen.
Die Leute da haben das sehr gut beschrieben.
Dann wär bei den PGN's nur noch zu klären, welche Source Adressen ich verwenden kann und darf.

Ich hab mal das Buch "Controller Area Network Projects" durchgearbeitet.
Sehr viel neue Erkenntnisse hat's mir nicht gebracht. Immerhin bin ich der Meinung den CAN Bus einigermassen verstanden zu haben.

Nun zu meinem neuerlichen Problem:
Ich hab mir die ISOAg lib heruntergelden. Leider find ich in dieser Library irgendwie keinen Einstieg.
Link: http://isoaglib.com/de/download
Die Library besteht aus 360! Header Dateien, aber irgendwie sind das nur Definitionen und Prototypen ohne ausführbaren Code.

Es ist auch irgendwie nicht klar, welche Dateien eingebettet werden müssen ( Diagnostic usw. ) und welche optional sind.
Ich denk mal die Plattform, die da genutzt wird ist der PC.
Ich hätte mir zumindest erhofft irgendwelche Initialisierungsabläufe aus dieser Lib herausziehen zu können.

Doch bei dem Umfang seh ich da mal keinen Weg.

Hat von Euch da jemand eine Idee?