Hallo zusammen, ich habe gerade ziemlich lange im Forum gestöbert aber noch nichts passendes gefunden. Ich hoffe ich bin in diesem Forum richtig. Wir haben in unseren Fahrzeugen einen CAN-Bus verbaut, bzw. mehrere. Wir haben ein eigenes Protokoll, das auf dem J1939 Standard aufbaut. Zur Zeit nutzen wir bei der Diagnose die BUSMASTER-Software. Sie ist kostenlos und hat uns im ersten Schritt weitergeholfen. Als Hardware verwenden wir einen Peak-Dongle. Wir möchten diese Thematik nun professioneller angehen und uns ein anderes Tool zulegen, weil wir den Busmaster sehr umständlich finden und wir oft Probleme bei der Auswertung haben. Wozu brauchen wir die Software: - Wir möchten CAN-Botschaften senden/empfangen und grafisch auswerten können - Wir möchten unser eigenes CAN-Protokoll verwenden können (wir haben bisher nur eine .dbc-File) - Gerne möchten wir die Software auch mit eigenen Modulen erweitern können, zum Beispiel Parameter setzen, usw. Im ersten Schritt ist meine Frage zuerst mal: Hat jemand von euch Erfahrungen mit der Diagnose Software von den Herstellern Peak, Vector, Sontheim oder Ixxat? Welche ist eurer Ansicht nach nicht zu schwer zu bedienen? Seht ihr ein Problem bei der Verwendung einer solchen Software mit speziellem Can-Protokoll? Vielen Dank, Bobby
Also ich kann dir für den Low-Budget-Bereich PCAN empfehlen - super einfach - super easy. Das kann jeder. Möglichkeiten mit der Software sind begrenzt (dem Preis entsprechend). Dann kann ich dir noch zu CANoe sagen - bzw. was will man dazu sagen? Das ist halt der Porsche unter den Tools. Das kann alles was du dir erträumst. Damit wirst du sicher glücklich - wen du es bezahlen kannst.
Bupf schrieb: > Also ich kann dir für den Low-Budget-Bereich PCAN empfehlen - > super > einfach - super easy. Das kann jeder. Möglichkeiten mit der Software > sind begrenzt (dem Preis entsprechend). > > Dann kann ich dir noch zu CANoe sagen - bzw. was will man dazu sagen? > Das ist halt der Porsche unter den Tools. Das kann alles was du dir > erträumst. Damit wirst du sicher glücklich - wen du es bezahlen kannst. Ich arbeite auch mit CANoe und bin sehr zufrieden damit. Wer nicht den riesen Funktionsumfang braucht (z.B. auf Simulation verzichten kann), kommt ggf. auch mit dem CANalyzer aus (ist deutlich günstiger).
Boris B. schrieb: > Ich arbeite auch mit CANoe und bin sehr zufrieden damit. Wer nicht den > riesen Funktionsumfang braucht (z.B. auf Simulation verzichten kann), > kommt ggf. auch mit dem CANalyzer aus (ist deutlich günstiger). Ich habe in der Firma PCAN mit J1939 Modul. Geht ganz gut. Vector ist wie gesagt nochmal deutlich umfangreicher, aber auch der CANalyzer kostet schon Faktor 10 mehr als PCAN von Peak.
Hallo, ich arbeite mit den Tools von Vector ( CANalyzer, CANape und CANoe ) und derren Hardware. Zum Flashen benutze ich ebenfalls den Peak. Wenn du genügend Geld zur Verfügung hast würde ich dir zum CANalyzer raten, da musst du aber mit 5k € rechnen. Grundsätzlich kann der Peak aber auch nicht weniger. Ich hab mir ein Python Skript geschrieben, mit dem ich Daten loggen und senden kann. Dinge wie CCP ( Parameter verstellen ) sind dann auch kein Hexenwerk mehr. Noch eine Frage: Was hat ein eigenes CAN Protkoll mit dem dbc File zu tun? Im dbc File steht nur drin, welche Info in welcher Nachricht ist.
Vielen Dank für die Antworten! Ich schaue mir die Tools mal an. Ich bin relativ neu in dieser Thematik, deswegen kann bei mir die eine oder andere Verständnislücke vorhanden sein, aber aus diesem Grund frage ich ja bei euch nach :) Ich habe mir bereits im Vorfeld Tools von Ixxat, Sontheim, Vector und Peak angeschaut. Ich muss sagen, die Vector und Peak scheinen mir atraktiver und geeigneter zu sein, so wie ich das einschätzen kann. Ich erkenne ebenfalls Unterschiede zwischen Vector und Peak, aber könnt ihr mir sagen, ob der Preisunterschied wirklich gerechtfertigt ist? In Sachen Erweiterbarkeit, d.h. Programmierung eigener Module, welches würdet ihr eher nehmen? Eine grundlegenede Frage, die sich hier noch stellt ist: Wir haben momentan eine eigene Software (relativ spartanisch) mit der wir Botschaften schicken und empfangen können. Also vergleichbar mit PCAN-View, nur auf unser Protokoll zugeschnitten. Die Diagnose machen wir wie gesagt mit BUSMASTER. Ursprünglich war hier geplant unsere eigene Software zu erweitern, um eine Komponente mit der man Parameter schreiben kann auf unseren Steuergeräten. Ich frage mich aber gerade ob es nicht sinnvoller wäre ein Tool von Vector oder Peak zu erwerben und dort die Komponente einzubauen. Was meint ihr? So wie ich verstanden habe ist dies ja möglich. Somit hätte man nur ein Tool für alles. Wenn es jedoch heisst, dass ein User mit beschränkten Rechten drauf zugreifen soll, müsste es verschiedene Benutzerkonten geben. Max schrieb: > Noch eine Frage: Was hat ein eigenes CAN Protkoll mit dem dbc File zu > tun? Im dbc File steht nur drin, welche Info in welcher Nachricht ist. Nichts direkt, hab mich falsch ausgedrückt.... Viele Grüsse, Bobby
Noch eine weitere Frage: Hat einer von Euch schonmal mit eigenem Protokoll in so einer Software gearbeitet. Ich versuche ungefähr den Aufwand abzuschätzen, den es benötigt das eigene Protokoll mit dem Diagnose-Tool zu verwenden. Vielen Dank!
Bobbyf24 schrieb: > Ich versuche ungefähr den > Aufwand abzuschätzen, den es benötigt das eigene Protokoll mit dem > Diagnose-Tool zu verwenden. Kannst du das mal genauer erklären? Was genau meinst du mit "eigenem Protokoll"? PS: Du verwendest sehr häufig den Begriff "Diagnose". Möchtest du wirklich Diagnose (OBDII, ODX...) machen, oder meinst du einfach nur eine Busanalyse?
:
Bearbeitet durch User
Boris B. schrieb: > Bobbyf24 schrieb: >> Ich versuche ungefähr den >> Aufwand abzuschätzen, den es benötigt das eigene Protokoll mit dem >> Diagnose-Tool zu verwenden. > > Kannst du das mal genauer erklären? Was genau meinst du mit "eigenem > Protokoll"? Unser Protokoll baut auf J1939 Standard auf, hat jedoch teilweise längere Identifier, d.h. wir nutzen teile der Datenbytes, um die IDs unterzubringen. > > PS: Du verwendest sehr häufig den Begriff "Diagnose". Möchtest du > wirklich Diagnose (OBDII, ODX...) machen, oder meinst du einfach nur > eine Busanalyse? So hier mal was wir möchten: - Botschaften senden/empfangen - Während der Fahrzeugtests möchten wir grafisch udn tabellarisch die Ergebnisse aufzeichenen - Wir möchten Paramter schreiben und auslesen können, evtl. auch Parametersätze (dafür müssen wir ein Modul entwicklen) - Filter für eingehende Messages - Wir möchten vier Busse auswerten können - Wir möchten Messwerte analysieren, indem wir die aktuellen Fahrzeugdaten grafisch angezeigt bekommen - Buslast, Fehler-Analyse Vielen Dank, Bobby
Boris B. schrieb: > Kannst du das mal genauer erklären? Was genau meinst du mit "eigenem > Protokoll"? Das habe ich mich auch gefragt. Mir stellt sich auch die Frage, warum will man ein eigenes CAN Protokoll verwenden? Es gibt doch Protokolle, die auf CAN basieren, siehe J1939 und CANopen. Damit sollte eigentlich alles abgedeckt sein. Vector Tools sind halt sehr mächtig aber die meisten nutzen wahrscheinlich weniger als 50 % der gesamten Funktionen. Den CANalyzer gibt es übrigens mit Erweiterungen für J1939 und CANopen. Vector hat auch eine eigene Scriptsprache ( CAPL ) mit der man viele Dinge automatisieren kann. Ist ganz nett aber mir wäre es lieber man hätte eine Schnittstelle zu Python oder anderen Scriptsprachen. Nervig ist manchmal die Auswertung von Messdaten. Das Plotten von Grafiken ist verbesserungswürdig. Am Besten informierst du dich bei den Firmen direkt. Ich würde dann ein Treffen organisieren und mir die Tools anschauen und mir dabei eine eigene Meinung bilden.
Max schrieb: > Vector hat auch eine eigene Scriptsprache ( CAPL ) mit der man viele > Dinge automatisieren kann. Ist ganz nett aber mir wäre es lieber man > hätte eine Schnittstelle zu Python oder anderen Scriptsprachen. Du kannst auch C#, VB.NET oder Java verwenden. Außerdem gibt es ein COM-Interface, dass man auch leicht mit Python oder VBS ansprechen kann. CAPL ist übrigens keine Scriptsprache, sondern wird tatsächlich kompiliert ;-)
Max schrieb: > Das habe ich mich auch gefragt. Mir stellt sich auch die Frage, warum > will man ein eigenes CAN Protokoll verwenden? Es gibt doch Protokolle, > die auf CAN basieren, siehe J1939 und CANopen. Damit sollte eigentlich > alles abgedeckt sein. Das Protokoll war schon da als ich hier angefangen habe... daran kann ich nichts mehr ändern. Ich habe es auch schon oft in frage gestellt, aber es gab wohl einige Gründe, wie Adressierung, Masse an Steuergeräten usw. Warum, Weshalb ist jetzt egal ... ich muss eine Lösung finden ohne Standard. Max schrieb: > Vector Tools sind halt sehr mächtig aber die meisten nutzen > wahrscheinlich weniger als 50 % der gesamten Funktionen. Den CANalyzer > gibt es übrigens mit Erweiterungen für J1939 und CANopen. > Vector hat auch eine eigene Scriptsprache ( CAPL ) mit der man viele > Dinge automatisieren kann. Ist ganz nett aber mir wäre es lieber man > hätte eine Schnittstelle zu Python oder anderen Scriptsprachen. > Nervig ist manchmal die Auswertung von Messdaten. Das Plotten von > Grafiken ist verbesserungswürdig. > Am Besten informierst du dich bei den Firmen direkt. Ich würde dann ein > Treffen organisieren und mir die Tools anschauen und mir dabei eine > eigene Meinung bilden. Genau das werde ich mal machen. Danke Dir, Bobby
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.