Car-PC.info

cPOS - Lichtsystem für cPOS?
LEDproject - Mi 19 Sep, 2007 23:27
Titel: Lichtsystem für cPOS?
Hallo zusammen

Ich habe für den Eigengebrauch und für ein paar kleine Projekte von bekannten ein Lichtsystem entwickelt, welches sich für ausgefallene Auto-Ausbauten besonders eignen würd.

Da ich schon seit einiger Zeit cPOS verwende und total begeistert von bin, will ich jetzt das Lichtsystem per cPOS steuern können.

Falls sich Leute finden, die interssiert an diesem System sind, würd ich das gerne direkt in CPOS integrieren womit eine komfortable Bedienung möglich wäre.

Hier eine kurze Erklärung des Systems:
Das gesamte System besteht aus mehreren Units, welche per CAN-Bus untereinander kommunizieren:
- Output-Unit: bis zu 24 PWM Ausgänge welche über den CAN-Bus angesteuert werden köenne. Zusammen mit RGB-LEDs sind Farbverläufe und jeder erdenkliche Farbton möglich. Falls die 24 Kanäle nicht genügen, können fast beliebig viele weitere Output-Units an den Bus angeschlossen werden. Auch die Ansteuerung von Relais ist möglich.
- RS232-Unit: Verbindung vom Bus zum Computer. Somit könnte spziell mit cPos zB. die Output Unit angesteuert werden. Somit wäre zum Beispiel die Auswahl der Farbe für die Untenbodenbeleuchtung über den CAR-PC möglich. Ebenfalls lassen sich verschiedene Farbprogramme starten.
- Control Unit: Eingangseinheit zum bedienen des Systems per Taster
- weitere Einheiten... wie LCD-Unit, Central-Unit..

Falls intresse dafür besteht, poste ich gerne noch genauere Informationen und stell das System genauer vor.

Um einen Eindruck zu bekommen gibts unter www.ledproject.ch --> Album einige Bilder.

Gruss Marc
Johnny - Mi 19 Sep, 2007 23:44
Titel:
ich werd mir morgen mal die page anschauen..
aber ich sag einfach mal ich würde gerne genauere infos haben ;O
MR Action - Mi 19 Sep, 2007 23:57
Titel:
Dieser Post wurde vom User entfernt
FMode - Do 20 Sep, 2007 08:01
Titel:
ja an den "I/O Platinen" mit Controller(Atmel,PIC?)+MCP2515(?) und CAN Treiber auf einer Platine besteht Interesse... wenn dann noch ein Bootloader dabei wäre dann wäre das der Himmel auf Erden.
Ich habe nämlich das selbe/ähnliche Problem...
Und bräuchte für Motoren, Geber und Schalter in allen 5 Türen und den beiden Vordersitzen mindestens 7 Stück.


BonusCAN ? Was ist den das nun wieder ? Think
Sebastian - Do 20 Sep, 2007 08:23
Titel:
boah wow respekt steckt bestimmt ne menge arbeit drin alles zu verkabeln und so wie hastn du in die schalter und so die rgb leds reingequetscht, ich habe das auch mal versucht in den heckscheibenheizungsschalter 2 stk einzubauen (wenns geklappt hätte hätt ichs mit dem rest der beleuchtung auch gemacht) aber das hat ja vorne und hinten net gepasst wegen viel zu klein und so...

würd wohl mal gerne bilder von der verkabelung und des steuergerätes sehen wollen...
MR Action - Do 20 Sep, 2007 08:32
Titel:
Dieser Post wurde vom User entfernt
FMode - Do 20 Sep, 2007 08:52
Titel:
MR Action hat folgendes geschrieben:
Der BonusCAN ist der Gedanke an einen weiteren CAN im Auto (ob das nun der erste ist - wie bei Phil - oder der vierte - wie bei mir - ist ja egal...)... Um halt eigene Steuergeräte im Auto unterzubringen und mit einander kommunizieren zu lassen...


ah ihr habt das BonusCAN gennannt...

MR Action hat folgendes geschrieben:

Damit du das eine oder andere Signal halt nicht zu jedem Steuergerät wieder hinlegen musst... Und der CAN soll auch irgendwann mal am PC landen... mcfloppy ist da derzeit an dem Adapter am bauen... Nur Aufgrund


mcfloppy braucht keinen Adapter zu bauen... gibt jede Menge "Lawicel-kompatibele" (Fuchs von CANHack, Volker von OBD-Shop, mictronics.de ,....)

MR Action hat folgendes geschrieben:
der Tatsache, das es halt ein CAN ist und man in der groben Theorie mit dem Adapter auch auf die WerksCANs gehen könnte und da senden statt


mit dem vorhandenen I/O System in cPOS kann ich jederzeit z.b. einen Tempomaten (VDO Tempostat) steuern

MR Action hat folgendes geschrieben:
nur auf dem eigenen, sträuben sich unsere lieben cPOS Coder derzeit ein wenig das einzubinden... Wink


*erhobenerzeigefingermodus*
nicht deren Problem... deren Problem wäre VB6 eine vernünftige Schnittstelle für Plugins beizubiegen...


Ihr macht wahrscheinlich in Atmel BASCOM rum ?
Hier auf dem Tisch steht ein Atmega16 und MCP2515...
Ich habe im Auto mittlerweile 9 "tote" (ohne Anschluss) Motoren... und deswegen ist ein CAN I/O System jetzt Prio 1 für mich erstmal...
Wo sind den die ganzen BonusCAN Leute (ausser Phil) zum Mitmachen ? Wo/wann trifft man sich ?
MR Action - Do 20 Sep, 2007 09:31
Titel:
Dieser Post wurde vom User entfernt
philipp_c - Do 20 Sep, 2007 09:40
Titel:
Hab den Thread hier auch gerade mal entdeckt Smile
Jo FMode im Prinzip sind die CAN "BonusCAN" Leute im IRC sogar einer der nichtmal aus dem Forum ist.
Und wie gesagt ein Bootloader existiert bereits allerdings ist er noch nicht soweit, dass man ihn einbauen kann. Auf dem Schreibtisch habe ich allerdings schon Module damit geflasht.

Gruß Philipp
FMode - Do 20 Sep, 2007 10:28
Titel:
MR Action hat folgendes geschrieben:
Er tut es aber, um den Jungs von cPOS eine Art erkennung des Adapters zu präsentieren um nur auf dem Adapter das schreiben zu ermöglichen und die Geschwindigkeit im Adapter selbst festzusetzen - zumindest war das letztens mal angedacht... Ob es wirklich so kommt und obs der eigentliche Grund dafür ist, ka... Wink


Was will das Frontend von den CAN Geraffel ? Ich nehme an Sitz verstellen, Lichter einschalten, Heizung(sklappen) regeln,...
Dann ist das die Schnittstelle nach unten. darunter dann eine isolierte Schicht (DLL, ...) mit Umsetzung auf CAN Nachrichten mit dem Lawicel Protkoll.

Also: Frontend <-> Plugin <-> DLL <-> Lawicel Adapter

MR Action hat folgendes geschrieben:

Du meinst jetzt aber nur die "Tasten" vom Tempomat über PC drücken - oder!? Weil wie du mit den paar Relaiskarten wirklich die Geschwindigkeit regeln willst ist mir noch ein Rätzel...


ich meinte das als Beispiel "wer A sagt muss auch B sagen"

wenn der TÜV Prüfer mir erzählen würde das ich mein Unterbodenbeleuchtung-Handbremsunterbrecherkontakt nach der Prüfung auch überbrücken könnte dann sag ich ihm das er seinen Kofferraum zuschweissen muss - schliesslich könnte er ja 20 Zementsäcke oder Bleiplatten einladen (und damit sein Auto überladen)

MR Action hat folgendes geschrieben:

Sie machen es aber zu ihrem Problem... :'(


ein Tritt hilft da manchmal ... sorry...
Die C-64 Einzelkämpferzeiten sind vorbei ! wo ein "Gott" ein kommerzielles Spiel entwickelt hat inkl. Grafik und Sound...

MR Action hat folgendes geschrieben:
Wir springen eigentlich alle im IRC rum...


Wann genau ? das man mal koordiniert... ich will nix unnötig machen und ja mir isses mittlerweile egal ob Avr Studio (gcc) oder Bascom....
Ich hasse beides und vermisse den Microsoft-Visual-Studio-Komfort.
MR Action - Do 20 Sep, 2007 11:08
Titel:
Dieser Post wurde vom User entfernt
LEDproject - Do 20 Sep, 2007 20:03
Titel:
Wow...da ist ja was gelaufen Wink

Also...ich werde das ganze voraussichtlich nicht mehr auf einen anderen Bus anpassen, weil in der Entwicklung des Protokolls steckt schon einiges an Zeit und Überlegung...also denk ich mal Wink... Das protokoll ist so offen wie möglich definiert, sodass mir jede erdenkbare erweiterung ermöglicht wird...
Die ID besteht aus den drei Komponenten: Absenderadresse, Senderadresse, MessageTyp...womit jede Message klar definiert ist.
Als MessageTyp sind schon einige definiert, wie zB:
-SystemRegisterAccess: womit der Zugriff auf das Systemregister dass jedes Modul hat ermöglicht wird
-EventMessage: Zum Beispiel für die Controll Unit zum Melden eines Tastendruckes
-SetRGB Message: Zum setzen eines Farbwertes an der Output-Unit
...
...
...

Zum allgemeinen Aufbau der bereits vorhandenen Module:
Allgemein sind alle Module mit einem Atmel AVR 8Bit Controller ausgestattet welcher per MCP2515 am CAN hängt. Die Hardware ist auch so aufgebaut, dass sich der Mikrokontroller in den Sleepmode setzen kann und erst durch eine Aktion (Interrupts) wider geweckt wird, womit ein sehr geringer Stromverbrauch ermöglicht wird.

Mögliche Systemzusammenstellungen:
- Steuerung Komplett per CAR-PC:
Einzelne Kommandos wie zB. Innenbeleuchtung Blau, Klima an usw... werden direkt über die RS232 Unit an die Ausganseinheit gesendet. Ebenfalls könnte über die Eingangseinheit zB. Türkontakte auf dem Bildschirm angezeigt werden, oder cPos über externe Tasten bedient werden.

-eigenständiges System:
die gesamte Kontrolle wird von dem Modul Central-Unit übernommen. Der CarPC dient 'nur' zur Bedinung der Central-Unit. So sagt der Car-PC z.B der Central-Unit sie soll das Fadeprogramm für die LED's starten und die Output-Units werden dann von der Central-Unit angesteuert. Somit kann das System auch bei ausgeschaltetem CarPC funktionieren und zB. die Innenbeleuchtung einschalten wenn die Tür geöffnet wird.

Hoffe das Konzept konnte einigermassen rübergebracht werden...

Werde Später noch die einzelnen Module dies bereits gibt vorstellen, wenn ihr wollt...

Ich würde die Module für einen günstigen Preis abgeben (Bausatz, Feritg bestückt?), wenn interesse daran besteht.

Fragt bitte wenn was unklar ist...

Gruss Marc
philipp_c - Do 20 Sep, 2007 20:19
Titel:
Schade, so wie Du das Protokoll beschreibst passt es nicht zu dem "BonusCAN" an dem hier von mehreren gearbeitet wird, naja aber das war ja auch nie Dein Ziel.

Verwendest du 11 oder 29bit IDs? Vielleicht kann man es ja wenigstens so machen, dass man sich auf einem Bus nicht stört.

Gruß Philipp
LEDproject - Do 20 Sep, 2007 20:23
Titel:
Sind 29bit....

Na wo finde ich denn was darüber..hast mir mal n link wo offiziell über den bus diskutiert wird....unter "bonusCan" konnt ich ma nix rechtes finden...
würd mich da gern mal schlau machen drüber...

gruss marc
philipp_c - Do 20 Sep, 2007 20:30
Titel:
So richtig dokumentiert ist das ganze nicht. Wir wollten uns endlich mal auf IDs einigen, aber bisher ist das alles nur gerede im IRC. Das bedeutet allerdings nicht, dass alles nur gerede ist. Bei einigen von uns läuft bereits so ein Bus im Auto. Unter anderem bei mir. Zur Zeit sind es 6 Module die bei über den CAN verbunden sind.

Ich kann ja kurz erzählen wie es bei mir ist, das sollte sich von den anderen nicht groß unterscheiden.
Erstmal gibt es ein CAN Interface, das sendet die CAN Nachrichten die der PC schickt 1:1 in den Bus und umgekehrt. Eine Anpassung dieses Interfaces ist also bei neuen Modulen oder so nicht erforderlich, weil der PC vollen Zugriff auf den Bus hat.

Die Nachrichten sind alle Event basiert und es wird sich an den CAN Standard gehalten. Es können also Nachrichten mit einer RTR Nachricht angefordert werden usw. Und es gibt auch jeweils nur ein Modul, was mit einer ID sendet. Weiterhin wurde kein weiteres Protokoll dazwischengelegt (also keine Absenderadressen oder soetwas). Bei mir im Auto ist zB die ID 1000 für die Zentralverriegelung zuständig und im 1. Byte ist der Status abgelegt. Diese Nachricht kann entweder per RTR angefordert werden oder sie kommt ohnehin automatisch bei einer Änderung des Zustandes. (zudem wird diese Nachricht bei mir zyklisch wiederholt, falls ein Modul mal verpennt schlafen zu gehen).

Gruß Philipp
Lord_EMEREY - Do 20 Sep, 2007 20:41
Titel:
Ohh es wird interessant ..

Da ich beruflich CAN um genauer zu sein CANopen programmiere würde ich gerne helfen, da man damit ein an universalität kaum übertreffbares system schaffen kann.

z.B. über ID's muss man nicht diskutieren, einfach per dip's an den modulen umstellbar gestallten, damit können auch "endlos" gleiche module eingebaut werden

Wichtiger wäre sich zu einigen welches Protokoll, Identifier, usw. man einsetzen möchte.

Baudrate ist eigentlich klar aus den Spezifikationen zu erlesen.
Meine Erfahrung sagt bei Fahrzeugsteuerungen das man 125kbit/s (max. 500m / real ca. 300m) oder max. 250kbit/s (max. 250m / real ca. 100m) nutzen sollte, wobei die Länge der Leitung nicht das problem im eigentlichen sinne ist aber wohl eher das die sogenannten Stichleitungen max. 30cm lang sein dürfen.
Desweiteren treten Fehler auf wenn der BUS langsamer ist, dann gibt es Probs mit der Buslast und PWM und schneller ist nicht ausfallsicher genug.

In diesem Sinne



Gott bin ich langsam beim tippen nebenbei 3 neue einträge *grml*
philipp_c - Do 20 Sep, 2007 20:59
Titel:
Bei mir im Auto läuft der Bus mit 125kbit/s.

Von den DIP Schaltern halte ich nicht soviel. Ich bin eher dafür sich auf IDs für möglichst Abstrakte events zu einigen. Denn die Software in meinen anderen Modulen weiß nicht wie die Dip Schalter an dem einen Modul gesetzt sind.
Um nochmal auf die ZV Message zurückzukommen. Diese Message geht bei mir einfach in den Bus wenn ich abschließe, ohne Empfängeradresse usw, einfach ganz simples CAN ohne CANopen drauf usw. Dadurch muss meine ZV Steuerung gar nix wissen. Die sendet einfach munter einen neuen Status, sobald ich auf die FB drücke. Die Türmodule empfangen das und schließen dementsprechend auf/ab oder machen das Fenster zu. Genauso das Dachmodul usw. Bei diesen ganzen Aktionen muss das Modul was diese 1000er Nachricht sendet nicht wissen wieviel Türen ich habe und es muss auch nicht wissen ob dadurch jetzt das Dach zugehen soll usw. Es muss nur wissen, wenn einer auf die FB drückt sag ich bescheid.
Diese flexibilität verliert man, wenn man sich nicht auf IDs einigt und die per DIP einstellbar macht, dann muss danach wieder an jedem Modul geändert werden usw.

Die IDs auf dem Bus sind quasi die von FMode immer so geprädigte API zwischen den Modulen.

Gruß Philipp
Lord_EMEREY - Do 20 Sep, 2007 21:20
Titel:
Unter CANopen kannst du auch Messages an alle ID's (z.b. Dachsteuerung)oder an ID-Bereiche (z.B. alle Türen) schicken, welche aber wenn einfach so an alle Slaves geschickt werden unnütz BUS-Last verursachen, da die Message im Normalfall solange aufm dem BUS liegt, bis die Message verfällt (zeitlich bedingt) oder vom BUS "gelöscht" wird. Bei ID's empfängt der definierte Slave die Nachricht und "löscht" dies vom BUS.
Mit den ID's wird es eindeutiger und erleichtert ungemein die Fehlersuche.
Desweiteren ist eine Realisierung und spätere Erweiterung sogar einfacher, da ein klar definierte BUS besteht.
philipp_c - Do 20 Sep, 2007 21:32
Titel:
@Lord_EMERY deinen letzen Post habe ich nicht verstanden.

Wir verwenden ja kein CANopen. Das heißt es wird einfach eine Message mit ID xy geschickt und den Daten hinten dran. Da muss ich nicht sagen an alle Türen, weil die Nachricht sowieso an jedem Steuergerät landet. (Das meinte ich oben mit der flexibilität, ich muss nicht wissen wer was mit der Information anfängt, ich gebe sie einfach nur weiter).
Ausserdem darf laut CAN Spec jede ID ja nur von einem Sender auf den Bus gegeben werden, so ist es kein Problem am CAN Monitor zu sehen wer was gesendet hat und es lässt sich auch direkt aufschlüsseln.

Gruß Philipp
Lord_EMEREY - Do 20 Sep, 2007 21:50
Titel:
Also deinem letzten Post entnehme ich (bitte berichtigen falls falsch), daß Ihr eine Message an eine ID schickt oder meinst du die absender ID ?
Zitat:
es wird einfach eine Message mit ID xy geschickt


desweiteren soll diese Nachricht an allen Geräten ankommen, aber wer nimmt dann diese Message vom BUS ?

Vieleicht könnte man deinen BUS einfach mal analysieren? Smile
Wieviele Geräte hast du derzeit am BUS hängen? Kannst du mit deinem CAN Monitor auch die BUS-Last harausbekommen? Um langfristig ausfallsicher zu sein darf die BUS-Last nicht über 25% steigen, zumindest wenn du auch Kritische Sachen über CAN steuern möchtest.



Fragen über Fragen ... und vieleicht auch ein paar Antworten ...
Ich glaube solche Diskusionen sind im IRC oder @ real Life sinnvoller Smile
philipp_c - Do 20 Sep, 2007 21:53
Titel:
Also wir (die meisten die damit basteln) sind jetzt gerade im carpc channel

Mit der ID meine ich die Message ID mit der jede CAN Nachricht beginnt. Also die ganz unten low level gesendet wird ohne irgendwelches CANopen Zeug darüber. Die Nachricht wird auch nur solange gesendet bis ein anderer Knoten das ACK Flag setzt. Die Buslast ist momentan weit unter 25%

Gruß Philipp
MR Action - Do 20 Sep, 2007 21:53
Titel:
Dieser Post wurde vom User entfernt
Lord_EMEREY - Do 20 Sep, 2007 21:56
Titel:
Wohin ins IRC ? Channel need Smile
MR Action - Do 20 Sep, 2007 21:57
Titel:
Dieser Post wurde vom User entfernt
Lord_EMEREY - Do 20 Sep, 2007 21:59
Titel:
Wer lesen kann ist halt doch im Vorteil .. ich halt heute nicht mehr Smile
LEDproject - Do 20 Sep, 2007 23:00
Titel:
@philipp_c
Ich hatte euern ansatz auch schon mal angefangen umzusetzen....bin dann aber wider davon abgekommen.
Es ist mir klar, dass auf eure Art die CAN-Eigenschaften voll ausgenützt werden können und sehe auch die Vorteile. Aber meiner Ansicht nach ist das Konzept für ein offenes System einfach zu ungeeignet... Angenommen einer einer will jetzt sein Blaulicht aufm Dach noch steuern...was so wohl kein anderer hat...dann muss eine ID dafür reserviert werden, nur für das Blaulicht? Okee, ist jetzt vllt n dummes Beispiel, aber ist mir grad nichts anderes eingefalln... Hoffe man versteht worum es geht, und ich habe das richtig verstanden...?

Bitte versteht das nicht so...dass ich jetzt einfach meine Arbeit durchboxen will...ich bin echt auch dafür was einheitliches zu entwickeln und passe mich gerne an...
Hoffe wir bringen da was schlause zu stande...

Gruss Marc
philipp_c - Do 20 Sep, 2007 23:08
Titel:
Du hast schon recht. Für solche Sachen wie zB das einschalten des Lichtes auf dem Dach ist unser System eh schlecht geeignet. Im Prinzip ist es nur wirklich gut geeignet um events zu übertragen. Mir fällt aber kein gutes Event ein, was das Blaulicht auslösen könnte Wink. Aber man könnte zB eine Schaltafel machen (egal ob in Hardware oder in Form eines Menüs auf dem Toch) das bei Änderung seiner Tasten den Zustand auf den Bus schickt. Da hat man ja pro ID 64Bit und wir verwenden bisher nur 11bit IDs und selbst da ist ja Platz für über 2000 IDs also da einem Schalter einfach eine ID zu verpassen sollte kein Problem sein.

Vielleicht kann man es ja so machen, dass Dein System sich nicht daran stört wenn IDs in dem 11bit Raum ankommen und es auch nichts sendet in diesem Raum. Dann könnte man beide Systeme parallel auf einem Draht laufen lassen.

Gruß Philipp
MR Action - Do 20 Sep, 2007 23:26
Titel:
Dieser Post wurde vom User entfernt
Alle Zeiten sind GMT + 1 Stunde
Powered by phpBB2 Plus and Kostenloses Forum based on phpBB