peliCAN - CAN sniffer fuer Linux/Windows

[Michael H. (itzlbritzl)]

Hallo zusammen,

ich moechte hier mein Projekt vorstellen, das urspruenglich nur als 
kleines Tool fuer mich gedacht war, dann aber doch groesser geworden ist 
als erwartet :)

Es ist ein Programm fuer Linux und Windows basierend auf der Qt library 
und Qwt zum Darstellen von CAN Botschaften ueber SocketCAN oder ueber 
ein ASCII-Protokoll. (siehe hier: 
http://www.can232.com/docs/can232_v3.pdf)

Bisher ist implementiert:
- SocketCAN und ASCII Protokoll
- Filterung von Daten ueber eine XML Definition nach ID, EID, SID, DLC, 
RTR und Dateninhalt
- Umrechnung der Daten in numerische Datentypen (int16, int32, int64, 
float)
- Darstellung als Hex
- Berechnung der Daten durch Scripte in der XML Definition
- Darstellung als Baum
- Darstellung als Graph mit verschiedenen Achsen
- Logging und Aufbereitung der Daten ins lesbare Format

Was noch fehlt:
- Editor zur Festlegung der Signale
- Senden von Signalen

Das Tool ist unter der GPL v3 veroeffentlicht. Es ist so gehalten, dass 
man die Klasse fuer die Kommunikation einfach vererben kann und ein 
eigenes Protokoll einfach implementieren kann, wenn man moechte.

Eine genaue Beschreibung und der Link zu den Quellen/Win32 bins auf 
http://www.hans-dampf.org

Als Beispielgraphen haelt ein Testboard von einer IMU her.

Bitte um eure Meinung

Schoenen Gruss
Mike

[Thomas F. (igel)]

So ein Programm suche ich noch. Nach dem Weichnachtstrubel werde ich das 
dann gleich mal ausprobieren..

Welche CAN-RS232 Adapter verwendest du?
Ich bin noch dabei die Firmware für meinen selbst gebauten Adapter mit 
MCP2515 und AtMega zu schreiben. Ein Punkt des Lawicel-Protokolls ist 
mir dabei nicht ganz klar:

Wie sieht die Bytefolge aus, wenn der CAN-Adapter eine empfangene 
Botschaft an den PC sendet (Auto-Modus, kein polling)?
Ist das dann auch tiiildd...CR?

[Michael H. (itzlbritzl)]

Thomas Forster schrieb:
> So ein Programm suche ich noch. Nach dem Weichnachtstrubel werde ich das
> dann gleich mal ausprobieren..

Wenn Du das Programm ausprobiert hast, sag mir doch bitte kurz Bescheid 
obs geht und welches System Du verwendest.

> Welche CAN-RS232 Adapter verwendest du?
> Ich bin noch dabei die Firmware für meinen selbst gebauten Adapter mit
> MCP2515 und AtMega zu schreiben. Ein Punkt des Lawicel-Protokolls ist
> mir dabei nicht ganz klar:

Selbstbau mit einem PIC18F26K80, FTDI und einem CAN-Transceiver. 
Controller koennte kleiner sein, aber der lag da grad rum :)

> Wie sieht die Bytefolge aus, wenn der CAN-Adapter eine empfangene
> Botschaft an den PC sendet (Auto-Modus, kein polling)?
> Ist das dann auch tiiildd...CR?

Das habe ich bei meinem Selbstbau-Adapter so implementiert und mit 
slcand (SocketCAN) und Wireshark getestet, funktioniert. Bei 29bit IDs 
dementsprechend das grosse T vorne.


Schoene Weihnachten noch :)

[Thomas F. (igel)]

Auf deiner Homepage stimmt der Link zu den beiden pngs nicht:

signal_group.png und graph_view_example.png zeigen auf:
http://192.168.11.78/wordpress/wp-content/uploads/2014/12/graph_view_example.png


Im Connect-Dialog im Programm muss man bei LAWICEL den COM-Port händisch 
eintippen. Das Drop-Down Feld ist leer. Ist das Absicht?

System: Win7

[STMler (Gast)]

Michael Hoffacker schrieb:
> Was noch fehlt:
> - Editor zur Festlegung der Signale
> - Senden von Signalen

Hast du vor das Senden von Signalen zukünftig noch zu implementieren? 
Die Software sieht schick aus aber ohne Senden fehlt zumindest mir der 
Reiz diese zu nutzen.

[Thomas F. (igel)]

Hallo Michael,

ich habe jetzt mal getestet, leider wird nur immer eine einzige 
Botschaft angezeigt und auch nicht aktualisiert. Ich vermiute den Fehler 
aber eher in der RS232 Bytefolge, welche ich an den PC schicke. Ich habe 
mich dabei an die LAWICEL-Doku gehalten, also 
tiiildddd(timestamp_4Byte)[CR].

Ich habe mal ein Log mit den eingehenden Daten angehängt. Vielleicht 
siehst du ja hier einen Fehler.

Gesendet werden die IDs 200, 201, 202, 203 und 300 im 1s-Raster.

[Michael H. (itzlbritzl)]

STMler schrieb:
> Michael Hoffacker schrieb:
>> Was noch fehlt:
>> - Editor zur Festlegung der Signale
>> - Senden von Signalen
>
> Hast du vor das Senden von Signalen zukünftig noch zu implementieren?
> Die Software sieht schick aus aber ohne Senden fehlt zumindest mir der
> Reiz diese zu nutzen.

Bin ich gerade dabei.

Thomas Forster schrieb:
> Im Connect-Dialog im Programm muss man bei LAWICEL den COM-Port händisch
> eintippen. Das Drop-Down Feld ist leer. Ist das Absicht?
>
> System: Win7
Die Port-Enumerierung ist noch nicht drinnen, folgt aber noch.

Thomas Forster schrieb:
> Hallo Michael,
>
> ich habe jetzt mal getestet, leider wird nur immer eine einzige
> Botschaft angezeigt und auch nicht aktualisiert. Ich vermiute den Fehler
> aber eher in der RS232 Bytefolge, welche ich an den PC schicke. Ich habe
> mich dabei an die LAWICEL-Doku gehalten, also
> tiiildddd(timestamp_4Byte)[CR].
>
> Ich habe mal ein Log mit den eingehenden Daten angehängt. Vielleicht
> siehst du ja hier einen Fehler.
>
> Gesendet werden die IDs 200, 201, 202, 203 und 300 im 1s-Raster.
Die Botschaften sehen gut aus, ich denke eher, dass das Programm 
irgendwo in einen Timeout reinlaeuft. Werde das ausprobieren.

[Thomas F. (igel)]

Michael Hoffacker schrieb:
>> Gesendet werden die IDs 200, 201, 202, 203 und 300 im 1s-Raster.
> Die Botschaften sehen gut aus, ich denke eher, dass das Programm
> irgendwo in einen Timeout reinlaeuft.

Hab den Fehler behoben bekommen, indem ich meine RS232-Routine etwas 
umgeschrieben habe. Woran es genau lag weiß ich allerdings nicht.
Jedenfalls funktioniert der Empfang, auch mit meinem langsamen 
1s-Raster.

Gleich noch ein kleiner Bug: Beim Beenden von peliCAN meldet Win7 
jedesmal Programmabsturz:

Problemsignatur:
  Problemereignisname:  APPCRASH
  Anwendungsname:  peliCAN.exe
  Anwendungsversion:  0.0.0.0
  Anwendungszeitstempel:  00000000
  Fehlermodulname:  ntdll.dll
  Fehlermodulversion:  6.1.7601.18247
  Fehlermodulzeitstempel:  521ea91c
  Ausnahmecode:  c0000005
  Ausnahmeoffset:  00055f99
  Betriebsystemversion:  6.1.7601.2.1.0.256.48
  Gebietsschema-ID:  1031
  Zusatzinformation 1:  0a9e
  Zusatzinformation 2:  0a9e372d3b4ad19135b953a78882e789
  Zusatzinformation 3:  0a9e
  Zusatzinformation 4:  0a9e372d3b4ad19135b953a78882e789

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie 
unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt

[Thomas F. (igel)]

Nochmal ich mit ein paar Anmerkungen:

- Liest man in das laufende Programm die Signaldefinition.xml nochmals 
ein, wird im Signal View jedesmal eine weitere Y-Achse hinzugefügt. Erst 
wenn das Programm neu gestartet wird, sind die alten Achsen wieder 
verschwunden.

Ich habe mal versucht eine eigene xml-Datei zu bauen und habe diese 
angehängt. Es sollen die IDs 200 und 300 ausgewertet werden. Dabei steht 
jedes Byte in den Botschaften für einen uint8-wert.
- Beim ersten Byte wird für beide Botschaften "Out of Range" angezeigt, 
obwohl diese zwischen 0E und 3F liegen. Byte 2 wird dann richtig 
angezeigt.
- Stellt man <dislay type="Hex"... anstelle uint16 ein (siehe meine 
xml), dann stürzt das Programm beim Laden der Signaldefintion ab.

[Michael H. (itzlbritzl)]

Thomas Forster schrieb:
> Nochmal ich mit ein paar Anmerkungen:
>
> - Liest man in das laufende Programm die Signaldefinition.xml nochmals
> ein, wird im Signal View jedesmal eine weitere Y-Achse hinzugefügt. Erst
> wenn das Programm neu gestartet wird, sind die alten Achsen wieder
> verschwunden.
Hab ich auch gemerkt, kommt raus...


> Ich habe mal versucht eine eigene xml-Datei zu bauen und habe diese
> angehängt. Es sollen die IDs 200 und 300 ausgewertet werden. Dabei steht
> jedes Byte in den Botschaften für einen uint8-wert.
> - Beim ersten Byte wird für beide Botschaften "Out of Range" angezeigt,
> obwohl diese zwischen 0E und 3F liegen. Byte 2 wird dann richtig
> angezeigt.
Ja, habs gefunden, wird geaendert...

> - Stellt man <dislay type="Hex"... anstelle uint16 ein (siehe meine
> xml), dann stürzt das Programm beim Laden der Signaldefintion ab.

Huch, das ist ein kleiner Bug... Die Typendefinition ist case-sensitive, 
es muss hex und nicht Hex heissen, darum laeuft das da in einen 
Fehler... Ich aender das zur naechsten Version...

[Michael H. (itzlbritzl)]

STMler schrieb:
> Michael Hoffacker schrieb:
>> Was noch fehlt:
>> - Editor zur Festlegung der Signale
>> - Senden von Signalen
>
> Hast du vor das Senden von Signalen zukünftig noch zu implementieren?
> Die Software sieht schick aus aber ohne Senden fehlt zumindest mir der
> Reiz diese zu nutzen.

Ist jetzt implementiert. Ausserdem sind die von Thomas Fischer bisher 
gefundenen Bugs behoben.

Aktuelle Version hier: https://github.com/mhoffacker/peliCAN/releases 
mit Beschreibung hier: http://www.hans-dampf.org

Neu ist auch die Unterstuetzung fuer den Loopback Mode bei dem LAWICE 
Protokoll.

[Thomas F. (igel)]

Hallo Michael,
Danke für die schnellen Änderungen. Für die Hex-Darstellung hatte ich 
die Schreibweisen "HEX" und "Hex" ausprobiert und dann aufgehört. War 
wohl eins zu wenig.

Gerade habe ich die neue Version geladen und ausprobiert:

Im Signal View wird die erste Botschaft richtig dargestellt. bei den 
folgenden Botschaften springen die angezeigten Werte immer zwischen den 
korrekten Werten und den Werten aus der 1. Botschaft hin und her. Siehe 
mein Bild: Botschaft zwei zeigt gerade den richtigen Wert, springt 
demnächst wieder um. Botschaft drei zeigt die Werte aus Botschaft 1. 
Treffen neue Botschaften ein (habe noch immer das 1s-Raster), springen 
die Werte um.


Noch eine Frage:
Innerhalb eines Data-Bytes einer meiner Botschaften stellt jedes Bit den 
Zustand eines Aktors oder eines Digital IO dar. Gerne würde ich nun Bits 
extrahieren und einzeln darstellen, z.B. Bit_7   [Value] 1
Allerdings habe ich die Script-Funktion nicht richtig verstanden, um 
dies umzusetzen:

<signal_group name="Status">
   <signal name="Brenner">
      <filter eid="false" sid="true" id_mask="0x203" dlc_mask="0xFF"
        rtr_mask="0x0" data_mask="0xFFFFFFFFFFFFFFFF"/>
         <display type="script" unit="" 
display_mask="0xFF00000000000000" >
  function disp(203, 0, 0, 0, 2, data)
  {
  return ( data[1] AND 0x01);
  }
         </display>
        </signal>
    </signal_group>

Wie muss ich das schreiben, um z.B. aus ID 203 im 1.Byte das Bit 0 zu 
extrahieren?

[Mathias O. (m-obi)]

Interessant. Ich hab auch meinen CAN-LAN-Adapter Ende November 
fertiggestellt. Empfangen und senden klappt. Und Qt nutz ich auch für 
meine Software.

[Michael H. (itzlbritzl)]

Thomas Forster schrieb:
> Im Signal View wird die erste Botschaft richtig dargestellt. bei den
> folgenden Botschaften springen die angezeigten Werte immer zwischen den
> korrekten Werten und den Werten aus der 1. Botschaft hin und her. Siehe
> mein Bild: Botschaft zwei zeigt gerade den richtigen Wert, springt
> demnächst wieder um. Botschaft drei zeigt die Werte aus Botschaft 1.
> Treffen neue Botschaften ein (habe noch immer das 1s-Raster), springen
> die Werte um.
Das ist so gewollt... Die ID wird bitweise verglichen. 0x300 & 0x200 == 
0x200, daher wird die Nachricht angezeigt. Bei genauerem Nachdenken ist 
das aber Bloedsinn so, drum werd ich das aendern, dass die ID genau 
passen muss.


> Noch eine Frage:
> Innerhalb eines Data-Bytes einer meiner Botschaften stellt jedes Bit den
> Zustand eines Aktors oder eines Digital IO dar. Gerne würde ich nun Bits
> extrahieren und einzeln darstellen, z.B. Bit_7   [Value] 1
> Allerdings habe ich die Script-Funktion nicht richtig verstanden, um
> dies umzusetzen:
>
> <signal_group name="Status">
>    <signal name="Brenner">
>       <filter eid="false" sid="true" id_mask="0x203" dlc_mask="0xFF"
>         rtr_mask="0x0" data_mask="0xFFFFFFFFFFFFFFFF"/>
>          <display type="script" unit=""
> display_mask="0xFF00000000000000" >
>   function disp(203, 0, 0, 0, 2, data)
>   {
>   return ( data[1] AND 0x01);
>   }
>          </display>
>         </signal>
>     </signal_group>
>
> Wie muss ich das schreiben, um z.B. aus ID 203 im 1.Byte das Bit 0 zu
> extrahieren?
Die Funktion wird nach dem passenden Filter aufgerufen. Die Parameter 
id, ext, .... brauchst Du eigentlich nur, wenn Du den Filter auf 
0xFFFFFF... setzt um dann innerhalb der Funktion unterscheiden zu 
koennen. ISt der Filter richtig gesetzt, wird die Funktion nur dann 
aufgerufen, wenn eine Nachrict mit der ID 0x203 ankommt.

function disp(id, ext, err, rtr, dlc, data)
{
  return ( data[1] &amp; 0x01 );
}

Eigentlich ist es data[1] & 0x01, aber XML interpretiert ein & als den 
Beginn einer Escape Sequenz. Wenn der Editor fertig ist wird das besser 
:)