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
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.
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Bitte 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.