SLSS CANopen Analyser

• Entwicklungsstand: in Entwicklung (letzte Aktualisierung: 08.12.2022)
• Veröffentlichungen: (Python-Offline veröffentlicht / C# Live Analyser ausstehend)

 

Vorgeschichte

Mit meiner CAN Bus-Software SLSS CANAnalyser* schein ich doch bei so einigen CAN Interessierten einen Nerv getroffen zu haben.
Durch den kostenlosen Download und den „cheap’n’open hardware“ Ansatz habe ich mittlerweile einige nette Kontakte knüpfen können (sogar weltweit was ich immer noch Wahnsinn finde).

Da meine beruflichen „Wurzeln“ bis Anfang letzten Jahres eigentlich immer fest im Automotive Sektor verankert waren, war für mich bis dahin das Multi-Master-Prinzip und die unabhängige Botschaftszuordnung stets das was den CAN Bus ausmachte und wofür ich Ihn einsetzte. Diese grundsätzliche Auslegung findet man zum Beispiel auch in den Beschreibungen der CAN Übertragungsverfahren*, wie hier zum Beispiel auf Wikipedia!

Im Zuge eines Jobwechsels wurde ich dann im ersten Projekt jedoch gleich mit dem Thema CANopen* konfrontiert.
Das Wort „CANopen“ war mir zwar bekannt und bis dahin auch schon einige Male an diversen Stellen „untergekommen“, doch war ich immer weit genug entfernt um mich nicht tiefer mit dem Thema beschäftigen und auseinandersetzen zu müssen!
Da mein neuer Projektleiter jedoch eher die Einstellung „learning by doing“ vertritt (was ich sehr an Ihm mag) und in unserer Abteilung noch kein Wissen hinsichtlich CANopen vorhanden war, wurde ich gleich ins kalte Wasser geworfen und musste mich mit den „Eigenheiten“ des CANopen Protokolls vertraut machen.
Schnell stellte ich fest, dass der CAN Bus selbst und der Aufbau der darauf versendeten Botschaften (CAN Frames) immer noch dasselbe war, doch altbekannte Dinge wie das Multi-Master-Prinzip mittendrinnen obsolet und durch mir bis dahin unbekannte Sachen wie Guarding, Heart-Beat, Node-IDs, SDOs, PDOs oder das ominöse Objektverzeichnis (object dictionary) ersetzt worden waren! So musste ich selbst erst einmal lernen was CANopen überhaupt ausmacht, welche Vorteile und evtl. auch Nachteile der Einsatz von CANopen mit sich bringt und wie die Daten auf dem Bus zu interpretieren sind.

 

Trace-Datei Analyse vorhandener CAN Daten

Nachdem ich die Grundlagen soweit verstanden hatte, nahm ich mir eine CAN Aufzeichnung und versuchte aus dieser die CANopen Informationen heraus zu generieren und für mich sichtbar zu machen. Da die Trace-Datei als *.csv Datei gespeichert worden war, nahm ich dafür Excel und „unterfütterte“ es für die Analyse mit ein paar VBA Funktionen. Dies funktionierte initial recht gut und man konnte schon erste Zusammenhänge erkennen, was beim weiteren Verstehen der Buskommunikation sehr hilfreich war („learning by doing“ halt, ganz wie gewünscht)! Da im beruflichen Umfeld dann aber wieder die beim SLSS CANAnalyser* angesprochenen teuren Softwaretools zum Einsatz kamen, war ein weiteres Ausbauen dieses Analyseverfahrens nicht nötig, wodurch für mich die Sache erst einmal beendet war.

  

 

Komischerweise dauerte es nur wenige Monate, bis auf einmal zwei Anfragen im Zuge meiner nebenberuflichen Selbstständigkeit auftauchten, in welchen es ebenso wie im Haupt-Job um die CANopen Thematik ging. Hier hatte ich nun jedoch das Problem, dass ich eben nicht auf die teuren Tools zurückgreifen konnte, sondern gern meine eigenen Tools, sprich den SLSS CANAnalyser* benutzen wollte.

Um für die Projekte gerüstet zu sein, griff ich die Idee der Trace-Analyse wieder auf und suchte im Internet nach einer CANopen Trace-Datei, welche ich vorab Analysieren und „Übersetzen“ kann. Dies gestaltete sich jedoch schwieriger als gedacht, mit etwas Mühe fand ich dann aber doch in einem Beitrag auf Mikrocontroller.net* eine Datei, welche ich zum Testen meiner Analysefunktionen nutzen konnte.

 

Analyse per Excel-Makro auf Dauer zu unperformant

Anfangs versuchte ich noch den gleichen Weg wie in der Arbeit und erstellte einige Excel-Makros zur Analyse der heruntergeladenen Trace-Datei. Ich merkte jedoch recht schnell, das Excel bei größeren Datenmengen (ich habe die Trace-Datei so konvertiert, dass ich sie im SLSS CANAnalyser* laden und dann mehrfach senden konnte) an seine Performancegrenzen kam und einfror, oder lange Zeit zur Analyse der Daten benötigte.

Aus diesem Grund entschied ich mich die Analyse außerhalb von Excel zu machen um anschließend die analysierten und ergänzten Daten zu speichern und bereits fertig in Excel öffnen zu können. Da ich mit Python bei der Messdatenanalyse schon einiges an Erfahrungen sammeln konnte, fiel die Entscheidung zu diesem Zeitpunkt recht zügig auf den Einsatz dieser Programmiersprache.   

 

Analyse per Python-Script und erstellter Bibliotheksfunktionen

Um also für kommende CANopen Analysen gerüstet zu sein, erstellte ich per Python ein paar Scripte, welche aufgezeichnete CAN Daten einlesen und um die Standard CANopen Informationen erweitern können. Das hat den Vorteil, dass man dann recht einfach nachvollziehen kann, was überhaupt auf dem Bus hinsichtlich CANopen passiert.

Da die aufgezeichnete Trace-Datei aus dem Beitrag auf Mikrocontroller.net anscheinend im PCAN-Trace-Format* erstellt wurden ist, ich aber die Möglichkeit haben wollte mehrere Trace-Varianten (PCAN, SLSS CANAnalyser, etc…) zu analysieren, setzte ich von Anfang an auf eine gewisse Modularität und kapselte Datenimport und CANopen Analyse in eigene Pythondateien. Die Hauptroutine innerhalb der Hauptdatei „CAN_trace_to_CANopen.py“ besteht dabei lediglich aus wenigen Zeilen Code und lässt sich somit zügig auf den aktuellen Einsatzzweck abändern.

Im ersten Schritt muss vor dem Ausführen des Scriptes innerhalb der Hauptroutine die Quellsoftware der Trace-Datei über die Variable „s_CAN_source“ angegeben werden. Danach wird beim Ausführen des Scrites mittels tkinter ein Dateiauswahldialog geöffnet, über welchen die zu analysierende Trace-Datei ausgewählt werden kann. Damit ist die Arbeit für den Anwender schon getan und die Analyse des CAN Traces wird gestartet.

 

# SELECT CAN trace source 
s_CAN_source = "PCAN"
# s_CAN_source = "SLSS_CANAnalyser"

root = tk.Tk()
root.withdraw()

file_path = filedialog.askopenfilename()
convert_can_trace_to_canopen(file_path, s_CAN_source)

 

Aufgrund der Quelltoolangabe wird innerhalb der Konvertierfunktion die richtige Datenimportroutine ausgewählt und die CAN Daten innerhalb dieser Zeilenweise verarbeitet.

 

    # check if file exists then open and parse
    if os.path.exists(s_trace_file_path):
        with open(s_trace_file_path, "r") as trace_file:

            l_can_data = []  # create list to hold rows of data as dictionary
            l_csv_header_values = []  # create list to store all needed csv header values

            # create dict list by PCAN trace file
            if s_trace_source == "PCAN":
                l_can_data = copen_file_import.extract_data_PCAN(trace_file)  # get list with dictionaries of data

            # create dict list by SLSS CANAnalyser trace file
            if s_trace_source == "SLSS_CANAnalyser":
                l_can_data = copen_file_import.extract_data_SLSS_CANAnalyser(trace_file)  # get list with dictionaries of data

            #
            # add more device file implementations here
            #

 

Die von der jeweilig ausgewählten Importfunktion zurückgelieferte Liste an Daten ist dabei immer gleich formatiert, womit die weitere Analyse unabhängig der Formatierung der Eingangsdaten aus den Quelldateien erfolgt. Dadurch ist es möglich Trace-Dateien unterschiedlicher CAN Tools durch die gleiche Analysemethode verarbeiten zu lassen. Kommt ein neues Trace-Format hinzu, erstellt man einfach eine neue Importfunktion und achtet darauf, dass die Daten in folgendem Format als eine Liste von Dictionaries zurückgegeben werden:

Key	Value
COB_ID_DEC (String)	COB ID (Integer)
COB_ID_HEX (String)	COB ID (Hex-String mit führender 0x)
DATA_DEC (String)	CAN Nutzdaten (Liste von Integerwerten)
DATA_HEX (String)

 

{'COB_ID_DEC': 1411, 'COB_ID_HEX': '0x583', 'DATA_DEC': [112, 16, 16, 17], 'DATA_HEX': ['0x70', '0x10', '0x10', '0x11']}

Diese zeilenweise erstellten Dictionaries werden anschließend durch die Analysefunktion um die CANopen Daten erweitert und wachsen damit um einige Key-Value Paare an. Die Analysefunktion erstellte ich anhand der Spezifikationen der von CiA* (CAN in Automation) bereitgestellten Richtlinien und Datenblätter und kapselte diese in mehrere Funktionen innerhalb einer eigenen Funktionsbibliothek. Damit wäre es theoretisch auch möglich nur eine NMT oder SDO Analyse durchzuführen und die anderen Funktionen zu ignorieren. 

Zum Schluss wird die so erweiterte Dictionary-Liste dann als Character-Separated-File (*.csv) mit dem gleichen Namen wie die Ursprungsdatei und dem Zusatz „_CANopen“ im Dateinamen gespeichert, womit der Analysevorgang abgeschlossen ist und die *.csv Datei in Excel geöffnet und analysiert werden kann. Integriert man dort die geladenen Daten in eine Tabelle, so kann man sogar nach bestimmten Botschaftsmerkmalen, Node-Ids, Cob-IDs, etc. filtern, womit auch eine erleichterte Navigation in größeren Trace-Dateien möglich ist.     

Mit dieser Funktion wäre es dem Themenersteller auf Mikrocontroller.net recht einfach möglich gewesen die von Ihm gesuchten CANopen Objekte aus den Trace-Daten herauszufiltern und die gesuchten Werte auszulesen.

 

 

Live-Anzeige eingehender CANopen Botschaften

Nachdem die Trace-Analyse so gut funktionierte fiel mir jedoch auf, dass es bei der Fülle an Daten schwierig werden könnte ein CANopen System ohne die nötigen Datenblätter zu analysieren. Möchte man zum Beispiel bestimmte Funktionen eines CANopen HID* ermitteln, so sollte man die Möglichkeit haben die direkte Reaktion auf die ausgeführte Eingabe beobachten zu können. Eine nachträgliche Auswertung der Daten ist hierbei schwierig, da man keinerlei Indikatoren innerhalb des Traces dafür hat.

Aus diesem Grund startete ich den Versuch eine Live-Analyse mittels der erstellten Python Bibliothek umzusetzen. Um die Daten aus dem SLSS CANAnalyser* ohne große Verzögerung zum Python-Script gesendet zu bekommen, spendierte ich dem SLSS CANAnalyser* ein TCP/IP Interface, welches die empfangenen CAN Daten an andere Programme weitergeben kann. Pythonseitig implementierte ich einen TCP/IP Server, welcher auf die eingehende Verbindungen des CANAnalyser wartet und anschließend die eingehenden Daten verarbeitet. Da die Anzeige innerhalb der Konsole / Eingabeaufforderung nicht so komfortabel ist und ich mir auch einige Einstell- und Steuermöglichkeiten in Form von Eingabeelementen vorstellte, erstellte ich mittels tkinter eine grafische Oberfläche in welcher die Daten angezeigt werden können.

   

 

Nach dem ersten Erfolg stellte ich jedoch recht zügig fest, dass die Daten in der Python GUI etwa 1-2 Sekunden später angezeigt wurden als im CANAnalyser empfangen. Das das Verarbeiten der Daten Zeit benötigen würde war mir natürlich bewusst, dass es dann aber doch so lang dauert, hat mich trotzdem überrascht! Damit ergibt sich das gleiche Problem wie bei der Offline-Analyse der Messdaten, nämlich das eine Zuordnung der Nutzeraktion zu den CANopen Daten aufgrund der Verzögerung erschwert werden würde. 

Ich versuchte daraufhin das Problem mit Parallelisierung des Codes, Multi-Threading, Codeoptimierung und sogar den Einsatz eines schnelleren Python JIT Compilers zu lösen und konnte auch eine Besserung erreichen, doch leider war ich mit der Lösung nicht 100%ig zufrieden, ganz abgesehen von der für Laien ungewöhnlich komplizierten Installation der Python-Umgebung und etwaiger side-packages.

Aus diesem Grund verwarf ich nach einigen Tagen die Idee eine Live-Anzeige in Python umzusetzen und wechselte zur Erstellung der GUI auf C#, mit welchem ich bereits den CANAnalyser erstellt hatte!

 

SLSS CANopen Analyser – C# Version

Um ganz auf Nummer sicher zu gehen, dass das Problem mit der Verzögerung nicht auch bei der Verwendung von C# auftritt, habe ich zuerst ein kleines Testprogramm geschrieben, mit welchem ich den Empfang und die Verarbeitung der Daten ausprobieren konnte. Da die Tests damit sehr vielversprechend verliefen, konvertierte ich meine in Python erstellte CANopen Bibliothek zu C# und erstellte ein GUI mit welcher ich die wichtigsten Funktionen bedienen kann.

 

 

Das Design der C#-GUI hat sich, wie man im Vergleich mit der Python-Variante gut erkennen kann, nicht großartig geändert. Aufgrund der Fülle an möglichen Informationen dominiert die Tabelle für eingehende Daten das Hauptfenster der Anwendung. Darunter habe ich die Steuerelemente für die Serververbindung und ein paar Filterfunktionen implementiert. Unter Zuhilfenahme dieser Filter kann man die eingehende „Datenflut“ auf die  gewünschten / benötigten Werte begrenzen, wodurch eine Messung oder Aufzeichnung um einiges übersichtlicher wird.

Die Elemente für die Filterung werden dabei dynamisch anhand der eingehenden Daten befüllt, weshalb die GUI im oben zu sehenden Ausgangszustand noch recht leer ausschaut. Dies ändert sich, sobald man die TCP/IP Verbindung zum SLSS CANAnalyser* hergestellt hat und dort CAN Daten eingehen.

  

 

Um zum Pausieren der eingehenden Daten nicht jedes Mal in den CANAnalyser wechseln zu müssen, habe ich im CANopen Analyser ebenfalls einen Pause-Button eingefügt. So kann man sich, nachdem die Verbindung zwischen beiden Programmen steht, voll und ganz auf das Fenster des CANopen Analyser konzentrieren und muss nicht zwischen den beiden Fenstern hin und her springen. 

 

Tag-Row zur besseren Orientierung bei der Nachauswertung

Die Tag-Row Funktion habe ich eingeführt, damit man die Möglichkeit hat sich innerhalb des Trace-Files Bezugsmarken zur besseren Orientierung setzen zu können. Da ich das Tool ursprünglich für das „Herausfinden“ der von Benutzereingaben (z.B. Tastendruck) ausgelösten CANopen Botschaften konzipiert habe, kann man mit der Tag-Funktion die Bereiche in der die einzelnen Eingaben stattgefunden haben unterteilen. Filtert man dann weiter nach Node-ID und weiteren bekannten Merkmalen, kann man hoffentlich die Signale soweit eingrenzen, dass man die ausgelöste Bus-Botschaft isolieren kann. Soweit die Theorie zumindest!

 

 

Da die neu eingehenden Daten immer von oben in die Tabelle geschoben werden, die Auswertung umgekehrt, also mit den ältesten Daten am Anfang aber intuitiver und somit auch leichter ist, kann man mit einem Klick auf das Pfeil-Icon ganz rechts die komplette List invertieren. Somit befindet sich der Start-Tag dann oben und der End-Tag unten.

   

 

Download SLSS CANopen Analyser (nur Python-Version)

Leider hatte ich noch keine Möglichkeit die C# Version des SLSS CANopen Analyser an einem Bus zu testen, auf welchem auch das CANopen Protokoll verwendet wird. Außerdem möchte ich gern weitere Komfort- und Simulationsfunktionen integrieren, welche ich aber nur mit Hilfe eines oder mehrerer CANopen Geräte umsetzen kann. Aus diesem Grund veröffentliche ich hier vorerst nur die in Python erstellte Nachanalyse von aufgezeichneten CANopen Daten und nicht die C# Version des SLSS CANopen Analyser. 

Mit der Python-Version lassen sich natürlich auch wie oben beschrieben Trace-Dateien anderer CAN Tools auswerten. Zum Testen habe ich die „Start.trc“ im Verzeichnis „Traces“ mit abgelegt und die Source-Auswahl auf PCAN gestellt. Zum Starten einfach das Python-Script ausführen und die Datei auswählen. 
Falls jemand beim Laden oder auch Erweitern der Python-Funktionen Hilfe benötigen sollte, so kann er sich natürlich gern unter info@langer-sebastian.de mit mir in Verbindung setzen.

 

Download “SLSS CANopen Analyser (Zip-Archiv)”

SLSS-CANopen-Analyser-python-offline.zip – 70-mal heruntergeladen – 81,50 kB

Download “SLSS CANopen Analyser (7-Zip-Archiv)”

SLSS-CANopen-Analyser-python-offline.7z – 22-mal heruntergeladen – 52,37 kB

 

Haftungsausschluss:

Die hier veröffentlichte Software wurde auf mehreren Systemen fehlerfrei getestet. Dennoch kann für evtl. Beschädigungen, Instabilitäten oder sonstige Beeinträchtigungen, welche unmittelbar durch die Installation, Nutzung, oder in sonstiger Weise in Zusammenhang stehend mit der hier zum Download angebotenen Software auftreten keinerlei Haftung übernommen werden. Der Download, die Installation und Nutzung geschehen auf eigenes Risiko! Bei Problemen wenden sie sich bitte an info@langer-sebastian.de!

 

Videos vom SLSS CANAnalyser Projekt