Obwohl das NCL-Protokolldateiformat aus Kompatibilitätsgründen unterstützt wird, wird das TDMS-Protokolldateiformat für neue Anwendungen empfohlen. Weitere Informationen finden Sie unter Embedded Network Data in TDMS.
Eine mit der NI-XNET Logfile Specification erstellte Protokolldatei kann nicht mit einer für die NI-CAN Logfile Specification entwickelten Anwendung verwendet werden.
NI-CAN Protokolldateien können mit Anwendungen verwendet werden, die mit der NI-XNET Protokolldateispezifikation entwickelt wurden.
Die NI-CAN-Protokolldateispezifikation erfüllt folgende Merkmale:
Die von allen NI-CAN-Protokolldateien verwendete Dateierweiterung lautet:
.ncl*.ncl
Alle NI-CAN Produkte gehen davon aus, dass jede Datei mit dieser Erweiterung dieser Spezifikation entspricht.
NI bietet Quellcode für den Zugriff auf NI-CAN Protokolldateien. Wenn Sie den Quellcode unverändert in Ihre Anwendung integrieren, können Sie die Erweiterung .ncl weiterhin für Dateien verwenden, die von dieser Anwendung verwendet werden.
Wenn Sie den Code für NI-CAN Protokolldateien ändern, auch wenn dies scheinbar kompatibel ist, müssen Sie die Dateierweiterung von .ncl in eine andere ändern. Diese neue Dateierweiterung kennzeichnet Ihre Dateien als Beschwerde gemäß Ihren eigenen Spezifikationen und stellt somit sicher, dass die Datei nicht von NI-Softwareprodukten für CAN falsch interpretiert wird.
Die Spezifikation verwendet für jedes Feld die folgenden Typen:
U8 8-Bit-Integer ohne Vorzeichen
U16 16-Bit-Integer ohne Vorzeichen, Big-Endian, ausgerichtet am 16-Bit-Offset in Datei
U32 32-Bit-Integer ohne Vorzeichen, Big-Endian, ausgerichtet am 32-Bit-Offset in Datei
U64 64-Bit-Integer ohne Vorzeichen, Big-Endian, ausgerichtet am 64-Bit-Offset in Datei
Der Header ist die erste Folge von Feldern in der Protokolldatei. Pro Protokolldatei existiert nur ein Header.
| Feld | Typ | Beschreibung |
| Signatur | U16 | Ein fester Wert für alle NI-CAN Protokolldateien, mit dem überprüft wird, ob die Binärkodierung der Datei dieser Spezifikation entspricht. Der Wert lautet hexadezimal 4E49 („NI“ in ASCII). |
| HeaderGröße | U16 | Größe des Headers in Vielfachen von u32 (4 Byte-Inkremente), einschließlich Signatur und HeaderSize. Die NI-CAN Protokolldatei unterstützt das Parsen mit Arrays aus u32. |
| HeaderHauptversion | U8 | Hauptversion für den Header (also 1 zu 1,5). Dies deutet auf eine Änderung hin, die die Kompatibilität mit der vorherigen Version beeinträchtigt. |
| HeaderUpgradeVersion | U8 | Upgrade-Version für den Header (d. h. 5 in 1,5). Dies deutet auf eine Änderung hin, die die Kompatibilität mit der Upgrade-Version 0 beibehält. |
| HauptversionEreignis | U8 | Hauptversion für alle Ereignisse in der Datei. Dies deutet auf eine Änderung hin, die die Kompatibilität mit der vorherigen Version beeinträchtigt. |
| EreignisUpgradeVersion | U8 | Upgrade-Version für alle Ereignisse in der Datei. Dies deutet auf eine Änderung hin, die die Kompatibilität mit der Upgrade-Version 0 beibehält. |
Tabelle 1: NI-CAN Logfile - Header-Informationen
Für diese Spezifikation muss der Header immer aus der folgenden Byte-Folge im Hexadezimalformat bestehen:
4E 49 00 02 01 00 01 00
Nach dem Header enthält die NI-CAN Protokolldatei null oder mehr Ereignisse. Jedes Ereignis steht in der Regel für einen einzelnen CAN-Frame, kann aber auch andere Informationen wie Fehler oder Trigger kodieren.
Für diese Version der Spezifikation ist die Größe jedes Ereignisses in der Protokolldatei gleich. Diese feste Größe beträgt 24 Byte (siehe nachfolgende Tabelle). Da die Größe des Headers und die Größe jedes Ereignisses fest sind, können Sie die Anzahl der Ereignisse oft anhand der Größe der Datei bestimmen.
Im Folgenden bezieht sich die Phrase "Net Interface Read" auf die Referenz auf die Funktion "NI-CAN Frame API Read" für die Netzwerkschnittstelle. Je nachdem, welche Entwicklungsumgebung Sie verwenden, finden Sie diese im NI-CAN Hardware and Software Manual unter:
Es wird dringend empfohlen, dass der erste Frame in der Protokolldatei aus einem NI-CAN Start-Trigger-Frame (Typ 4) besteht. Der Start-Trigger enthält einen absoluten Zeitstempel (Datum/Zeit) für den Start der CAN-Messung sowie eine Angabe des Zeitstempelformats für nachfolgende CAN-Frames (absolut oder relativ). Wenn der Start-Trigger in einer Protokolldatei fehlt, wird angenommen, dass der Start der CAN-Messung mit dem Zeitstempel des ersten CAN-Frames übereinstimmt. Weitere Informationen zum Start-Trigger-Frame finden Sie in der Funktion Netzschnittstelle lesen.
Feld | Typ | Beschreibung |
Zeitstempel | U64 | 64-Bit-Zeitstempel in Schritten von 100 Nanosekunden. Das Zeitstempelformat kann absolut (Datum/Zeit) oder relativ (nullbasiert) sein. Bei der Entwicklung von NI-CAN in LabVIEW ist der Zeitstempel in NI-CAN Frames Fließkomma (DBL) Sekunden. Für den Zugriff auf Protokolldateien müssen Sie diesen Zeitstempel in zwei U32-Felder umwandeln (siehe Beispiele). Die Binärdatei-I/O-Funktionen von LabVIEW arbeiten mit Big-Endian, so dass Sie einfach auf den höchstwertigen U32 gefolgt vom niedrigstwertigen U32 zugreifen können. Bei der Entwicklung von NI-CAN in C/C++ (oder anderen Sprachen) lautet der Zeitstempel in NI-CAN Frames zwei U32-Felder. Da jedes U32 in NI-CAN als Little-Endian gespeichert wird (niedrigstwertiges Byte zuerst), müssen Sie die Byte-Reihenfolge vor dem Zugriff auf die Protokolldatei vertauschen. Bei der Entwicklung von LabVIEW FPGA besteht der Zeitstempel aus zwei U32-Feldern. Die Binärdatei-I/O-Funktionen von LabVIEW arbeiten mit Big-Endian, so dass Sie einfach auf den höchstwertigen U32 gefolgt vom niedrigstwertigen U32 zugreifen können. |
Bezeichner | U32 | Kennung des CAN-Frames. Bit 29 (Hex 0x20000000 ) gibt das Format der CAN-Kennung an: Erweitert, Standard löschen. Die Konventionen für den Austausch von Bytes entsprechen der für jeden U32-Teil des Zeitstempels beschriebenen Methode. |
Typ | U8 | Art des Ereignisses (Frame). Dieses Feld ist 0 für einen CAN-Daten-Frame und 1 für einen CAN-Remote-Frame. NI-CAN unterstützt zusätzliche Werte. Bei der Entwicklung von NI-CAN in LabVIEW entspricht dies dem Feld IsRemote im CAN-Frame. Informationen zu anderen Typen als CAN-Frames finden Sie in der Funktion Netzschnittstelle lesen. Bei der Entwicklung von NI-CAN in C/C++ (oder anderen Sprachen) entspricht dies dem Feld FrameType im CAN-Frame. Informationen zu anderen Typen als CAN-Frames finden Sie in der Funktion Netzschnittstelle lesen. Bei der Entwicklung von LabVIEW FPGA entspricht dies dem Feld Type im CAN-Frame. LabVIEW FPGA unterstützt nur CAN-Daten-Frames und CAN-Remote-Frames. |
InfoA | U8 | Angaben, die den Typ qualifizieren. Für NI-CAN existieren diese Angaben nicht. Diese Informationen existieren für LabVIEW FPGA, werden aber derzeit nicht verwendet (für zukünftige Versionen reserviert). Beim Lesen der Protokolldatei sollten Sie dieses Feld ignorieren. Beim Schreiben der Protokolldatei muss dieses Feld auf 0 gesetzt werden. |
InfoB | U8 | Angaben, die den Typ qualifizieren. Sie sollten dieses Feld genauso interpretieren wie InfoA (ignorieren). |
Datenlänge | U8 | Bei CAN-Daten-Frames gibt die Datenlänge die Anzahl gültiger Bytes in Daten an. Bei CAN-Netzwerk-Frames gibt die Datenlänge die angeforderten Bytes an, nicht die Anzahl gültiger Bytes in Daten. Für alle anderen Rahmentypwerte gibt die Datenlänge die Anzahl gültiger Bytes in Daten an. |
Daten | U8 | Dieses Feld enthält immer 8 Bytes in der Protokolldatei. Die Anzahl gültiger Bytes richtet sich jedoch oft nach DataLength. |
Tabelle 2: NI-CAN Logfile - Ereignisinformationen