Tool zur Timing-Analyse eines CAN-trace (asc) gesucht

[Tobi (Gast)]

Hallo zusammen,

ich würde bei meinem Projekt gerne eine Timing-Analyse meiner 
CAN-Botschaften durchführen.
Die Daten erhalte ich mit Zeitstempel als Ascii-Trace.
Jetzt interessieren mich:
- Min/Mittel/Max-Zykluszeiten der Botschaften
- Botschaftsausfälle

Und das am besten Abschnittsweise und über den gesamten Trace.

Ziel ist im Prinzip den Controller so lange Daten auf den Bus legen zu 
lassen und die Zykluszeiten immer kürzer zu stellen, bis sich ein großer 
Jitter oder Controllerausfall zeigt. Nadelöhr ist auch der Controller 
(AVR) und nicht der Bus (500k).

Für kleine Traces geht das in Excel, aber ich würde das gerne auf einen 
sehr langen Zeitraum anwenden - da ist bei Excel Schluss.

Gibt es für so etwas ein ordentliches Tool oder eine Library zur 
Verarbeitung von CAN-Traces in Phyton/C++ o.ä.?

Linux wäre toll, Windows tut es aber auch.


Gruß

Tobi

[Thomas (kosmos)]

Als gute Triggermöglichkeit nutze ich immer das End of Frame da das 7 
Bits lange ist und kein Stuffing bit hat, stelle am Oszi also die 
Pulsdauer auf > 5 Bits ein. Bei Rigol kann man ja die Oszi per PC 
Software Steuert denke das man hier mit einem Script die Telegram Zeit 
sehr gut auswerten kann.

Bist du dir sicher mit dem AVR als Nadelöhr da dieser 120 Bytes 
CAN-Buffer hat.

Kannst du mal so ein ASCII-Trace posten.

Was soll den eigentlich die Zykluszeit verkürzen, eigentlich ist das ja 
nur ein höhere Traffic durch mehr Teilnehmer oder im geringem Umfang 
längere Nachrichten durch die Stuffing bits die ja erst bei einer großen 
Datenlänge und dem 29 bit Identifier ins Gewicht fallen würden.

Für so genaue Analysen wäre vielleicht ein Vector Tool und CAN Adapter 
zu empfehlen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobi schrieb:
> Für kleine Traces geht das in Excel, aber ich würde das gerne auf einen
> sehr langen Zeitraum anwenden - da ist bei Excel Schluss.

 Wieso ?

 1,048,576 Rows und 16,384 Columns pro Sheet reichen nicht ?

 Wenn man pro Botschaft 16 Spalten nimmt, ergibt das über eine
 Milliarde ausgewertete Botschaften.

 Immer noch zu wenig ?

 Kein Problem, Anzahl der Sheets ist nur durch vorhandene Memory
 begrenzt.

 Wird wohl eher mit deinen (Un)Möglichkeiten zusammenhängen, ein
 paar Zeilen in VBA zusammenzunageln...

[Rudolph R. (rudolph)]

Tobi schrieb:
> Ziel ist im Prinzip den Controller so lange Daten auf den Bus legen zu
> lassen und die Zykluszeiten immer kürzer zu stellen, bis sich ein großer
> Jitter oder Controllerausfall zeigt. Nadelöhr ist auch der Controller
> (AVR) und nicht der Bus (500k).

Hmm, das hatten wir doch gerade erst?
Also den Bus möglichst voll zu stopfen mit aufeinanderfolgenden 
Botschaften.

Ein AVR ist da ganz sicher kein Nadelöhr bei den Laufzeiten von 
CAN-Botschaften, das sind so 128...250µs.
Unter geschickter Ausnutzung der Botschafts-Prioritäten und mit mehreren 
Message-Boxen bekommt man den CAN zu >99% voll - wofür auch immer das 
gut sein soll.

Woher die Daten kommen sollen ist nicht Teil der Frage-Stellung, ebenso 
wenig was der Controller vielleicht sonst noch so machen soll, das 
austestbare Limit ist in der Praxis also eher weniger relevant.