LIN-Bus: LDF File prüfen

[Günter N. (turtle64)]

Hallo,

ich habe ein Gerät mit LIN-Bus gebaut und in meiner Testumgebung 
erfolgreich in Betrieb genommen.

Damit das jetzt in einer Automotive-Umgebung genutzt werden kann, 
brauche ich ein LDF-File, damit die dort verwendeten Tools sich richtig 
konfigurieren. Das LDF habe ich mit einem Freeware-Tool erstellt, es 
sieht meiner Meinung nach auch so aus, wie es nach den 
LIN-Spezifikationen sein soll.

Trotzdem meldet CanOE beim Laden Fehler in dem Bereich, wo 
diagnostic_frames spezifiziert werden. Leider ist die Fehlermeldung so 
aussagekräftig wie "Error".

Kennt jemand eine Möglichkeit, LDF-Files genauer zu analysieren? Gibt es 
evtl. eine standalone nutzbare Version des Vector LDF Explorer? Ich 
finde nur das gesamte CanOE-Paket, das ich für diesen einen Zweck nicht 
kaufen will.

[Rudolph R. (rudolph)]

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.

[Günter N. (turtle64)]

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.

[Rudolph R. (rudolph)]

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.

[Günter N. (turtle64)]

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?

[Günter N. (turtle64)]

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.

[Rudolph R. (rudolph)]

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)."

[Günter N. (turtle64)]

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.