Erfahrungen mit CanOpen ?
Hat jemand con euch Erfahrungen mit CanOpen und C#?
Wäre net wenn jemand ein paar Links hätte wo ich Hilfe zu diesem Thema finde.
Was für Hardware und in welchen Umfeld willst du dass denn verwenden?
Je nachdem was für nen Budget du hast, wüsste ich schon ne kommerzielle Möglichkeit, die funktionieren müsste.
Original von cmpxchg
Was macht denn CanOpen?
Schau mal hier
Baka wa shinanakya naoranai.
Mein XING Profil.
Naja was die Hardware angeht wird das ganze recht Lustig 😉 "Bunte Mischung"
Ein PDA mit Bluetooth und WLan soll mit einem Steuergerät welches mit eine Bluetooth CanModul ausgerüstet ist Komunizieren und über Wlan verbindung bestimmte Datensätze zu einem DB-Server übertragen.
Nun möchtest du für deinen PDA ne Software schreiben die die CAN Botschaften über Bluetooth empfängt?
Aber das CAN auch Bluetooth als Übertragungsstrecke benutzen kann find ich interessant, höre ich zum ersten mal.
Hatte eben eher an Steuerung vom PC aus gedacht, für nen PDA fallen meine Ideen leider weg.
Baka wa shinanakya naoranai.
Mein XING Profil.
JA talla so soll es am ende aussehen.
Da du sagst das du es interresant findest hier mal ein link zu dem Bluetoth-CAN-Modul welches ich verwenden werde.
http://www.ixxat.de/index.php?seite=canblue_de
So ist der Link Richtig ups
Eine PC Anwendung wäre für den Anfang auch schon mal nicht schlecht.
Leider hab ich mit CANOpen noch nicht viel zu tun gehabt. Deswegen suche ich hier im Forum etwas Hilfe.
Mit CANopen an sich hab ich auch noch net gearbeitet, aber ist halt auch nur nen Aufsatz auf CAN und damit hab ich schon bissle gemacht. Auch per VB.Net mit ner ECU kommuniziert(Diagnose per KWP2000). Das war mit Hilfe von CANoe. Wirklich tolles Tool, ich muss aber auch betonen das ich für die Firma arbeite, ob für deine Anwendung nen anderes Produkt besser geeignet wäre, kann ich net beurteilen. 😉
Aber mal zu den Fakten. CANoe kann man über COM fernsteuern, zusammen mit deiner Datenbasis hast du die Möglichkeit symbolisch per Botschaftsnamen mit der ECU zu kommunizieren. Was bei CANopen noch dazukommt, kann ich dir aber leider nicht sagen, hab wie gesagt in der Richtung noch nichts gemacht.
Was anderes, was mir eingefallen wäre, wäre direkt mit dem Treiber deiner Hardware zu kommunizieren. Da gibts auch was von Vector 😉 Aber will hier ja keine Werbung machen.
Und wie schon vorher betont, für nen PDA kann ich dir keider keine Ideen anbieten.
Baka wa shinanakya naoranai.
Mein XING Profil.
Original von talla
Das war mit Hilfe von
> . Wirklich tolles Tool, ich muss aber auch betonen das ich für die Firma arbeite, ob für deine Anwendung nen anderes Produkt besser geeignet wäre, kann ich net beurteilen. 😉
Ist ja lustig, dass du bei Vector arbeitest. Unsere Abteilung hat viel mit euch zu tun, wir bauen auch Applikations- und Analyse-Tools (vielleicht sagt dir das Produkt DriveRecorder was...). Hab gerade einen Code-Generator auf Basis von CAN-Beschreibungen (.mdc/.dbc) basteln müssen....
BTW: Das .mdc-Format könnte ein paar DB-Constraints gebrauchen.... 😉
Hab damit zwar nichts zutun, arbeite in anderen Themenbereichen, aber wieso bräuchte des Format Constraints?
Baka wa shinanakya naoranai.
Mein XING Profil.
Leider gibt euer Haus ja keine offizielle Specs für das mdc-Format heraus...
Beispiel: Eine Can-Message hat eine ID. Da wäre es naheliegend irgendwo irgendwelche Unique-Constraints im DB-Schema zu finden (in diesem Fall eher nicht, da eine Can-Message wohl nur innerhalb eines Netzwerkes eine eindeutige ID haben).
Momentan ist das Arbeiten mit mdc eher klassisches "Reverse Engeneering": Man nehme CanDb und versuche damit das Datenmodell abzuleiten. Leider interpretiert da auch Vector sein Datenmodell laufend neu. Ich hatte genau so eine mdc-Datei, die zwei Can-Botschaften mit gleicher ID vergab. Eine ältere Version stürzte daraufhin gnadenlos ab (die offenbar auch davon ausging, dass IDs generell eindeutig sind), die aktuelle packt es. D.h. es gibt diverse implizite Eindeutigkeiten, die aber aus der mdc überhaupt nicht hervorgehen.
Naja, man gewöhnt sich dran, dass Vector so eine Art Microsoft der Automotive-Industrie ist. Quasi-Standard, aber leider kein offenes Format. 😉
Ich nehme das mal als Kompliment 😁
Über die Produktpolitik kann man streiten. Normal ists aber dokumentiert in den entsprechenden Produkten, was sich geändert hat von Version zu Version. Da es zum Format keine öffentliche Doku gibt, werden da auch keine Änderungen freigegeben.
Aber ich sag mal auch so, gerade in dieser Branche muss man sehr drauf achten, wem man wie weit was offenlegt. Kann extrem kostspielig werden wenn interne Informationen bekannt werden.
Wozu du da Constraints brauchst in der Netzwerkbeschreibung verstehe ich aber immer noch net ganz 🤔 Aber muss auch sagen das ich selber noch kaum mitm mdc Format gearbeitet hab.
Wir haben ja auch embedded Produkte 🙂 Das ist meine Welt
Baka wa shinanakya naoranai.
Mein XING Profil.
Wir leben ja auch gut und gerne von den vielen Problemen, die proprietäre Lösungen mit sich bringen. Wenn man nur mal an die vielen Protokolle und Beschreibungsformate für Steuergeräte denkt. Alle zwei Monate meint ein Hersteller das Rad neu erfinden zu müssen, baut herstellerspezifische Erweiterung in "Standardformate" und wir bekommen schönes Geld, das in unseren Produkten zu implementieren. Schlecht für die Wettbewerbsfähigkeit der deutschen Automobilindustrie, gut für die Toolhersteller. 🙂