Hallo zusammen Ich bastel gerade an einem Projekt im Auto, bei dem ich verschiedene selbst entwickelte Schaltungen über ein Bussystem verbinden möchte. Die einfachste Schaltung ist dabei vielleicht der Innenlichtdimmer und die anspruchvollste die Ladedruckregelung. Das Problem bei meinem Bussystem ist nun, das die einfachen Schaltungen wie der Innenlichtdimmer nicht die wichtigen Informationen wie die der Ladedruckregelung blockieren dürfen. Ich möchte auch gerne verschiedene Sensorwerte "für alle" auf den Bus geben, so daß jede Baugruppe sie abrufen und bei Bedarf verarbeiten kann. Fällt Euch da spontan ein einfaches Bussystem für solche Zwecke ein? Viele Grüße, Jan
Stimmt, in neueren Fahrzeugen ist eh schon ein CAN-Bus drin, über den alle Komponenten/Steuerteile kommunizieren. Gruß Stephan
Die Teilung ist oft Motor mit Hochgeschwindigkeit und Karosserie sowie Innenraum/Komfort mit niedrigerer Geschwindigkeit. Meistens laufen die Busse dann am Amramturenbrett (Tacho) zusammen da dort oft Statusinformationen angezeigt werden. Die Trennung ist sinnvoll da z.B. der motor und seine Komponenten nur auf einem engen Raum mit kurzen Leitungen und hoher Geschwindigkeit kommunizieren können und vom abgerissenen Buskabel der Bremsleuchte hinten links nicht gestört wird. Un dem Fahrer ist es Egal ob die Klimaanlage innerhalb von 10ms oder 100 ms auf einen Tastdruck reagiert. In moderneren Fahrzeugen werden aber mitlerweile auch andere Busse eingesetzt, z.B. Motor mit Flexray, Multimedia mit MOST, Türen mit LIN..... Gruß Martin
Ja, an CAN hatte ich tatsächlich auch schon gedacht. Ich bin aber wieder ein bißchen davon abgekommen, weil ich denke, dass es ein wenig "overdressed" ist. Ganz konkret wird es, wenn ich beispielsweise den Ladedruck auf den Bus geben will: Ich brauche für den Fühler einen IC, nur um den Wert auf den Bus zu geben. Ich kann das Protokoll nicht per Software abwickeln, weil es zu komplex ist. Ich brauche also zur Bearbeitung dann noch zusätzlich einen Controller (beispielsweise um die Abweichung des Druckfühlers zu berechnen). Wie würde das Bussystem denn ganz konkret aussehen? Sensor->SLIO <-> CAN <-> CAN-Controler <-> Verarbeitung? Danke für Eure Antworten! Jan
wenn CAN zuviel kann, nimm den AS Bus ein Master fragt zyklisch bis zu 32 Slaves ab Reaktionszeit ist < 5msec, übertragen werden pro Zyklus 4 Bit einfache 2Drahtverbindung (incl. Versorgung), max 100 m (reicht im Auto sicher ;) ist eigentlich ein Industriebus für die unterste Ebene Gruß Peter
AS-Bus ist mir kein Begriff! Hat da jemand eine genaue Hardware- und Protokollbeschreibung? mfg leo
Wieso nicht CAN? Das dürfte das am weitesten verbreitete System für solche Zwecke sein, dementsprechend billig ist auch die Hardware und es gibt jede Menge Controller aus allen Grössenklassen, die so etwas schon eingebaut haben. Von der Software im Internet ganz zu schweigen. Etwas anderes würde ich an Deiner Stelle nicht nehmen.
Also nachdem ich jetzt all Eure Meinungen gehört habe, denke ich auch, dass CAN mölicherweise die beste Lösung ist. Ich bin ursprünglich auf der Suche nach einem einfacheren System gewesen, aber mit einem MCP2502X/5X kann ich ja doch recht einfach Sensorwerte auf den Bus geben und diese dann mit dem 2510 wieder auslesen... Danke für Eure Antworten :-) Jan
Auch wenn es viel Unterstützung für CAN gibt, sollte man die Komplexität nicht unterschätzen. Man wird nicht umhin kommen, CAN in der Tiefe zu verstehen. Und um CAN halbwegs zu verstehen, kann man durchaus sich ein halbes Jahr Vollzeit mit beschäftigen... Oder ist die Unterstützung mittlerweile wirklich so weit, dass ich mich um Details wirklich nicht mehr kümmern muss? Für wie aufwändig haltet ihr den Einstieg. Meine Erfahrungen gehen 10 Jahre zurück, als wir in diese Technik einsteigen wollten und ich mich etwa einen Monat damit beschäftigt hatte. Wir haben dann doch etwas einfacheres genommen.
> Meine Erfahrungen gehen 10 Jahre zurück, als wir in diese Technik > einsteigen wollten und ich mich etwa einen Monat damit beschäftigt > hatte. Wir haben dann doch etwas einfacheres genommen. Definiere das ganze mal ... beim CAN handelt es sich doch eigentlich um ein sehr verständliches Medium ... anders als bei jedem anderen kommerziellen Bus-System wie Profibus oder Interbus, von Industrial Ethernet ganz zu schweigen ! Also für uns war die Implementation von CAN wirklich das was am wenigsten Entwicklungszeit benötigte, bei der Profibus Implementation mussten wir sogar ne Woche einen Siemens-Ing. holen, da das damals mit der gesicherten Datenübertragung nicht so einfach war ... Bis dann Michael
Würde einen RS 485 nehmen. Auch CAN arbeitet damit. Software dazu gibt es im Forum. Oder selber machen. UART mit 9 Bit initialisieren, Baud 9600. Falls 9 Bit == 1 ist es die Adressinformation. Alle Teilnehmer auf Empfang schalten. Zugriff auf den Bus nur nach einer Wartezeit x eigener Adresse (falls 2 gleichzeitig senden wollen). Jedes Adressbyte stellt den Buszugriffstimer der Teilnehmer auf den Ausgangswert. So haben Teilnehmer mit niederer Adresse Vorrang. Übertragung immer zB. mit 5 Byte. Adresse, Befehl, Par1,Par2, Absenderadresse. Werde in geraumer Zeit Software posten. Schöne Grüße Josef
"Würde einen RS 485 nehmen. Auch CAN arbeitet damit." Seit wann das denn? Man kann RS485 als Übertragungsmedium nehmen. Wird aber so gut wie nie gemacht, weil das viele Nachteile hat (keine dominanten / rezessiven Pegel -> Nur Master-Slave Konfiguration). Nimm CAN, dann musst Du Dir über das Protokoll keine Gedanken mehr machen. Multimaster, was ja in Deinem Fall sinnvoll ist, kostet dann keinen Gedanken mehr. Die ICs kosten auch fast nichts mehr, es gibt von Microchip auch SPI-CAN-Controller, ideal für den Anschluss an einen ATMega - Samples gibt es kostenlos.
Viel Spass mit der Einarbeitung auf die CAN Chips ;-) (Data Sheets ab 200 Seiten). CAN benützt gleich wie RS485 die Differenzspannungsauswertung. Die dominaten rezessiven Pegel bei CAN brauchste im Selbstbau nicht, da du Prüfsummen verwenden kannst. Nebenbei würde ich von einem Eigenbau-Netzwerk im KFZ abraten. es sei denn, du bist Mitglied beim ADAC oder so. Im Profibereich geht fast kein Weg an einem genormten Bussystem vorbei. Im Hobbybereich würe ich nicht so streng sein. Josef
Hallo, also CAN Systeme sind wirklich nicht mehr so komplieziert zu handhaben. Wir arbeiten da aus der Automobilindustrie jeden Tag damit und setzen ihn auch bei Prototypen gerne ein. Allerdings würde ich dringend davon abraten in ein bestehendes CAN system im Auto einzugreifen da sollte man wirklich den ADAC Fachmann in der Verwandschaft haben. Mithorchen und einen eigenen Bus aufmachen ist da angeraten. Von Atmel gibt es mittlerweile ja den AT90CAN ist ein Mega128 mit CAN dazu, gibts C Beispiele auf der Hompage. Also alles kein Hexenwerk. Das einzige den gibt in Stückzahlen wohl erst im November. Wenn man etwas mehr mit dem Bus machen will vieleicht noch einen CAN Dongel von Peak für den PC anschaffen... Gruss, Markus
Markus, du hast natürlich recht. Aber du sagst selber, dass du jeden Tag mit CAN arbeitest. Das ist nichts für Hobbybastler. Damit du den AT90CAN einsetzen kannst, bedarf es schon guter Kenntnisse, abgesehen davon, dass du ihn mal auf ein Board auflöten mußt. Für uns vieleicht kein Problem, aber für jüngere Kollegen ev.schon. Ein 485er Chip kostet gerade 40 Cent und funktioniert mit jedem MC (auch welche ohne HW-UART). Der CAN nimmt dir zwar Buszugriff und Senden ab, die Verwaltung der Daten von zB. 30 Teilnehmern bleibt aber immer noch bei dir. Ich persönlich habe mit CANDIP gute Erfahrungen gemacht, aber der kostet (http://www.lawicel.com/candip/) Josef
Ich mußte mal ein Gerät über das CANopen Protokoll anbinden. Ja, man muß erstmal die Doku vom CAN-Controller durcharbeiten. Nicht alle 200 Seiten, aber Spaß macht es nicht. Ja, man muß sich in das Protokoll hineindenken. Und von vornherein sauber strukturiert die logischen Ebenen programmieren, sonst hat man nach den ersten Anfangserfolgen irgendwann einen riesigen Ärger, wenn es voller wird auf dem Bus. Aber wenn man sich einmal die Mühe gemacht hat ... prima Sache. Und von einem halben Jahr kann keine Rede sein, zumindest nicht für CANopen (ich kann schwer eine genauere Angabe machen, weil es immer so nebenher lief und das besagte Gerät viel Ärger gemacht hat). Und mit fertigen Libs geht es wahrscheinlich noch schneller, wenn man gerne fertige Libs benutzt. An die vorhandenen Busse würde ich aber nicht einmal hörend rangehen (auch wenn es verlockend ist). Selbst wenn man sicher ist, daß man ganz passiv bleibt: sie werden Dich verantwortlich machen, wenn nachher ihr Kram spinnt (und der spinnt heute oft). Und eine Versicherung freut sich immer, wenn sie eine Ausrede findet, nicht zahlen zu müssen. Wie überall: wenn das Haus abbrennt, weil der Stümper von der Elektrofirma Mist gebaut hat, wird die Versicherung nicht zahlen wollen, weil Du an anderer Stelle etwas "gebastelt" hast; und ja gar keine offizielle Ausbildung hast.
Ich stecke in den letzten Jahren Can-Entwicklung nicht drin. Oft sind die Sachen aber so: Theoretisch ganz einfach. Das klappt aber in der Praxis oft auch nur dann, wenn die Komplexität wirklich vorm Anwender verborgen bleibt. Schönes Beispiel ist ein Handy, wo keiner, der telefoniert was über HF-Technik wissen muss. Wenn man aber z.B. fremde Bibliotheken nutzen muss, wenn man herausfinden muss, warum ein Datagramm gerade schief läuft usw., ist man ganz schnell an dem Punkt, wo man ins System hineinschauen muss und dann alle Einzelheiten von CAN kennen muss. Und dann muss man vielleicht auch begreifen, wie die Bibliotheken intern funktionieren. Und wenn man dann tausenden von Quellzeilen irgendwie verstehen muss, gehen schnell mal einigen Wochen bei drauf. Ich kenne das alles zu gut aus dem Linuxbereich, wo man einerseits in 30 Minuten eine Suse installiert hat aber tausende von Stunden damit verbringen kann, alles mögliche so anzupassen, wie man es gerne möchte. Dann muss man nämlich im Detail verstehen, wie die komplexen Dinge miteinander zusammenarbeiten. Das Wissen ist zwar Gold wert auch für weitere Projekte, man muss es aber eben erstmal an Zeit investieren. Es könnte also einfacher sein, sich einen RS485 Wandler zu nehmen und in einer paar Zeilen Code ein eigenes kleines Simpelst-Protokoll zu schreiben. Trotzdem macht es mich neugierig, dass CAN mittlerweile relativ einfach zu handhaben ist, werde ich mir vielleicht in der nächsten Zeit mal anschauen.
Hallo zusammen! Hat sich schon mal jemand die Mühe gemacht und z.B. den MCP2515 auf ne kleine extra Platine designed? Quasi SPI auf CAN? Viele Grüsse Volker
Auch wir haben schon das eine oder andere Gerät an CANOpen oder DeviceNet angebunden, arbeiten ja beide mit CAN ... Und ich kann jedem der dies einmal machen möchte eigentlich fast nur raten keine Kommerzielle Library dazuzukaufen - die Einarbeitung dauert fast genausolange wie eine Vernünftige Einarbeitung in die Spezifikationen ... Wir haben eine kommerzielle Library für unser erstes Projekt gekauft, diese jedoch nie genutzt, da bis das Ganze geliefert wurde (immerhin EINE diskette für knappe 15000 DM) unser Prototyp schon recht gut lief ... ich habe mir das ganze dann mal angeschaut und von einer Portierung auf unser System Abstand genommen. Daraufhin habe ich mir bei Can In Automation alle Spezifikationen gekauft und das ganze komplett selbst programmiert. Das ganze war immer noch schneller fertig wie die komplette Hardwareentwicklung. Für die Master-Seite bleibt die Frage immer offen ... Wir haben auch ein Master-Stack programmiert (zumindest für die durch uns benötigten Funktionen) nur setzte ich wo ich kann entsprechende Hilscher-Interfaces ein ... Bis dann Michael
Hallo zusammen, Ich arbeite beruflich im Automobilbereich viel mit dem CAN . Ich kann nur raten tunlichst die Finger von den einzelnen CAN Netzen im Fahrzeug zu lassen! Selbst beim "nur" mithören können bei einer schlechten Schaltungsauslegung (Terminierung usw.) einige Probleme auftreten, die ev. wichtige Funktionen des Fahrzeugs beeinflussen (ESP/DSC, Motorsteuerung,...). Mit den richtigen Entwicklungstools (z.B. CANoe von Vector) macht es viel Spass seine Projekte umzusetzen. Es gibt auch Tools mit denen beispielsweise Steuergeräte interne Grössen über CAN mess- und applizierbar gemacht werden. Das ist unheimlich sinnvoll bei Abstimmungs- und Enticklungsarbeiten. Die CAN Treiber selbst werden eigentlich nicht mehr selbst programmiert (zumindest im Automobilbereich). Man greift hier auf fertige und vor allem erprobte Komponenten unterschiedlicher Hersteller zurück. Leider sind diese CAN Treiber auch ziemlich mächtig und umfangreich, sodass bei den meisten Projekten bei uns mindestens ein Mann für die Betreuung und die Konfiguration des CAN zuständig ist. Für Heimanwendungen halte ich den CAN für sehr brauchbar. Controller und Software sind vorhanden und müssen nur noch in die eigene Anwendung integriert werden. Klar, wer ein HighLevel Protokoll mit Überwachungen, Entprellungen und Fehlerintegralen implementieren möchte, muss natürlich einiges mehr an Grips investieren :-) Glücklich ist, wer seine Schaltung mal eben kurz an CANoe hängen kann und den Restbus einfach mal simmuliert :-) Viele Grüsse Volker
Untersuchung der Signalintegrität in Bussystemen (LIN, CAN, und FlexRay) Die Übertragung von Signalen auf dem Physical Layer von Bussystemen wird von vielen Parametern beeinflusst. Die simulatorische Bestimmung der genauen Einflüsse einzelner Parameter ist ein Forschungsschwerpunkt am Arbeitsgebiet Bordsysteme. Dazu werden verschiedene Parameterkombinationen untersucht, die resultierende Signalintegrität bei der Übertragung automatisiert ausgewertet und allgemeine Regeln zum Aufbau von Bussystemen abgeleitet. Hauptsächlich wird die Untersuchungen VHDL-AMS als Modellierungssprache eingesetzt. Kaum ein modernes Fahrzeug kommt ohne Bussysteme aus. Dieses interaktive Lernprogramm begründet die Vernetzung im Kraftfahrzeug. Es zeigt anhand verschiedener Bussysteme die technischen Alternativen, die Busstrukturen, Übertragungsgeschwindigkeit und die Datentypen. Dabei zeigt es sich, dass es kein "bestes" Bussystem gibt, sondern unterschiedliche Anforderungen je nach den Einsatzbereichen. Anhand einiger typischer Bordnetzstrukturen wird die Aufteilung auf verschiedene Bussysteme beschrieben. Besondere Beachtung verdienen die Gateways, die Übergangsstellen zwischen verschiedenen Bussystemen. Inhalt: - Diagnose Bus - LIN-Bus - CAN-Bus - MOST-Bus - Bluetooth - Die Bussysteme EIA-485, LVDS, D²B, byteflight, Flexray werden kurz charakterisiert.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.