LIN-Bus: LDF File prüfen

Das der Vector LDF Explorer nicht direkt runter ladbar ist verstehe ich auch nicht wirklich, denn CANdb++ steht ja sogar ohne Registrierung direkt als Download zur Verfügung. Ich habe den LDF Explorer dienstlich mit einer CANalyzer Lizenz bekommen, ich kann aber nicht sagen, ob der in einer aktuellen Demo auch mit installiert wird.

Gefunden habe ich gerade das hier: https://intrepidcs.com/products/free-tools/ldf-tool/

Das verifiziert zwar auch LDF, aber der schwer angestaubte Vector LDF Explorer 1.4.56 von 2016 auf den ich jetzt gerade Zugriff habe hält überhaupt nichts davon was das Tool mit der Datei macht die ich einfach nur geöffnet und anderem Namen wieder gespeichert habe - eher Finger weg.

Also ich wüsste auch schon gerne ob es da was brauchbares gibt, und sei es als Shell-Tool oder Python Script or whatnot. Mir würde auch LIN 2.2A reichen, die ISO 17987 brauchte ich bisher nicht und habe entsprechend da auch noch keinen Zugriff drauf gehabt.

Rudolph R. schrieb:

Gefunden habe ich gerade das hier: https://intrepidcs.com/products/free-tools/ldf-tool/

Das verifiziert zwar auch LDF, aber der schwer angestaubte Vector LDF Explorer 1.4.56 von 2016 auf den ich jetzt gerade Zugriff habe hält überhaupt nichts davon was das Tool mit der Datei macht die ich einfach nur geöffnet und anderem Namen wieder gespeichert habe - eher Finger weg.

Genau den habe ich benutzt. Das Ding macht heftige Fehler, z.B. lässt es manchmal die Frame Size in Bytes einfach weg oder schreibt irgendwo in eine Zeile nur ein Gleichheitszeichen rein. Besonders problematisch wird es anscheinend, wenn man mit dem Tool ein vorhandenes LDF einliest und das bearbeitet. Dann vergisst es, die Änderungen an allen notwendigen Stellen zu speichern, z.B. vergisst es, das Encoding neuer Signale zu speichern. Ansonsten aber besser als gar nichts.

Ich beschreibe mein Problem mal noch genauer.

Eigentlich habe ich nur einen Master, der seine Messwerte über LIN sendet, und gar keinen Slave. Ein Diagnosetool liest das mit und protokolliert.

Für das LDF muss ich einen Slave definieren, weil Signals einen Sender und einen Receiver brauchen, selbst wenn der im physikalischen System gar nicht existiert.

Dadurch zwingt mich CanOE dann, Node_attributes für den Slave zu definieren, darunter zwingend ein Signal für response_error und mindestens einen Frame für den Abschnitt configurable_frames.

Spätestens jetzt wird es kompliziert. Was macht CanOE, wenn es gar keinen Frame gibt, der dieses Signal enthält? Irgendwo in diesem Bereich liegt das Problem.

Aber wenn Du CANoe mit LIN hast, dann hast Du doch schon automatisch den LDF Explorer? In den Archiven die man einfach so runterladen kann ist ein Installer mit drin, man muss den nur finden und ausführen. Und "einfach so" laufen nur ältere Versionen.

Vorhin habe ich auch noch "LDF Syntax" für VSCode gefunden, das hat zwar keine Checks, aber Syntax-Highlighting zu haben ist schon mal netter als es nicht zu haben.

Und ja, zwei Nodes braucht man schon mindestens.

Hallo Rudolph,

ich habe jetzt eine Testversion von Vector bekommen und konnte eine CANoe-Testversion installieren, darin ist der Vector LDF Explorer enthalten. Damit konnte ich die Fehler nachvollziehen, das LDF-File wird jetzt ohne Fehler geladen.

Nächstes Problem: Meine Byte Order ist falsch, bei LIN muss das niederwertigste Byte zuerst geschickt werden. Das habe ich übersehen und muss jetzt einen Workaround finden.

Ich habe gesehen, dass der Vector LDF Explorer im Fenster "Edit Signal" (siehe Anhang, unten rechts) eine Einstellmöglichkeit für die Byte Order anbietet, die ist aber bei mir ausgegraut (kann an der Testversion liegen), und ich finde nichts dazu in der Dokumentation. In der LIN-Spezifikation steht nichts darüber, dass man die Byte Order ändern kann.

Da Du das Tool ja hast: Kann man da die Byte Order wirklich einstellen? Was ändert sich im LDF-File, wenn man das tut?

Hallo Rudolph,

hier mal das minimalste LDF-File, das der Vector LDF Explorer akzeptiert, mit nur einem 16-Bit-Signal in NewFrame1. Ist es möglich, für das Signal "Signal16Bit" die Byte Order wie im vorigen Post angesprochen umzukehren?

Es wäre schön, wenn Du das testen könntest, dann das File speichern und mir zurückschicken, damit ich die erforderlichen Änderungen dann manuell in das echte LDF-File einarbeiten kann.

Interessant, da bin ich bisher nicht drüber gestolpert.

Nach kurzer Verwirrung um die ausgegraute Byte Order Option die im LDF Explorer vorhanden ist und auf "Intel" steht, das "Signal_encoding_types" im LDF hat überhaupt keine Byte Order Option.

Und wenn man in den LIN Standard schaut ist das auch so beabsichtigt: "For data entities longer than one byte, the entity LSB is contained in the byte sent first and the entity MSB in the byte sent last (little-endian)."

Hallo Rudolph,

Danke fürs Nachsehen. Ich hatte gehofft, dass CANoe da ein verborgenes Feature hat, das am LDF vorbei die Byte-Order ändern kann. Dann muss ich wohl doch die Firmware anpassen.

Tipp: Vector hat den LDF Explorer als Freeware veröffentlich, den gibt es jetzt im Download Center als Installationspaket zum herunter laden.

Rudolph R. schrieb:

Tipp: Vector hat den LDF Explorer als Freeware veröffentlich, den gibt es jetzt im Download Center als Installationspaket zum herunter laden.

Hallo Rudolph, vielen Dank für diesen Tipp!

War der Thread gestern nicht noch in Fahrzeugelektronik? Auf jeden Fall würde ich den eher da suchen.