Welchen Einsatzzweck hat euer CAN Interface?

[Translating...]

Hier soll eine kleine Umfrage entstehen, für welchen Einsatzzweck ihr eure CAN Tools am meisten nutzt und welche Features ihr bei eurer Software bisher vermisst habt.

[Translating...]

Ich nutze mein CAN-Interface hauptsächlich um Motoren/Steuergeräte von neueren Fahrzeugen an älteren Fahrzeugen zum laufen zu bekommen. Sprich: Bus-Simulation.

Vermisst habe ich an diesem Interface/Software bisher nichts.

Grüße!

[Translating...]

Ich nutze das Interface USBtin mit dem guten alten Can h a c k e r.
Ein WGSoft Interface hab ich auch noch hier rumliegen, nutze ich aber nur im Auto an schnelleren CANs.

[Translating...]Interaktive Datenerfassung:
===========================
Ich nutzte früher den CAN-Hack-Adapter von Fuchs.
Vorteil: FTDI-Treiber verfügbar für viele Plattformen.
Nachteil: die ASCII-basierte Kommunikation und der FTDI-Treiber.

Nachdem ich bei der Erfassung des Antriebs-CANs unter Android damit nur Ärger hatte (vgl. entspr. Post hier im Forum) habe ich dann zwei PCAN-USB-Adapter von PEAK verwendet. Die kannte ich vom Beruf her schon.
Für Android habe ich mir dafür einen eigenen Treiber entwickelt, so dass ich nun mit dem Handy die Daten visualisieren und aufzeichnen und dann später am PC bearbeiten kann.

Niemals würde mehr ich einen Adapter ASCII-basierter Kommunikation einsetzen (zu hoher Overhead bzgl. Performance und Speicher).


Embedded-Bereich:
=================
Atmel-Controller mit MCP2515 zeigte sich auf dem Drivetrain-CAN deutlich unterdimensioniert, daher würde ich da auch nur noch mit nicht über I²C o.ä. serielle Lokalbusse angeschlossenen CAN-Controllern arbeiten. Da aber derzeit keine neuen Steuergeräte benötigt werden ist an dieser Front erstmal Ruhe...


Tante Edith sagt:
=================
Gerade habe ich gesehen dass wir hier eigentlich im Bereich Software sind.
Daher noch die Anmerkungen, dass ich meine Software selber schreibe. Früher unter C++/MFC für Windows, heute unter C#/WPF für Windows und eben unter Java für Android.
Warum? Weil ich außer Professionellen Tools für zig-tausende an Euros noch nichts gefunden habe was mir von Bedienung und Features zusagt.

Nebenbei entwickle ich Tools rund um Diagnose, Bussysteme, Vernetzung im Kfz und 'Tuning'. So z.B. einen CANdb-Editor, Tracker zum Aufspüren der logischen Verbindungen zwischen den diversen ECUs ebenso wie Editoren für ECU-Images inkl. Kennfelddetektion und -bearbeitung, Tuningsoftware zur Berechnung der Performance aufgrund einer Teilezusammenstellung (Karosserie, Motor, Getriebe), wobei dann anahnd der Parameter der verwendeten Teile z.B. V_max, Drehzahldiagramm etc. berechnet wird.
Ganz altmodisch habe ich auch Diagnosetester für die guten alten K-Line-basierten Protokolle entwickelt.


Gruß,
candev

[Translating...]

Gut, dass die CANhack Hardware RKS+CAN beides implementiert, ASCII Schnittstelle und binär per Windows-Gerätetreiber.

Der Vorteil der ASCII Schnittstelle liegt in der leichten Handhabung (zum Probieren reicht ein beliebiges Terminalprogramm, egal auf welchem Gerät).
Der Geschwindigkeitsnachteil wird zu verschmerzen sein, kein Mensch snifft Busse auf einem schwachbrünstigem Mobiltelefon oder 386er PC...

Neben der Geschwindigkeit bietet die binäre Schnittstelle vor allem Vorteile, bei der Behandlung bzw. Reaktion auf CAN-Nachrichten, wenn man eigene Anwendungen erstellt.

Viele Grüsse, Rainer

[Translating...]

Weitere vom RKS+CAN Interface per LAWICEL-Protkoll unterstützte Software:

https://txsuite.org/download/t7suite/
https://txsuite.org/download/t8-suite/
https://txsuite.org/download/trionic-can-flasher/
https://txsuite.org/download/trionic-can-flasher/

https://github.com/linux-can