NI-XNETログファイル仕様

この要素が0の場合、イベント内のすべてのマルチバイト要素 (タイプU16、U32、またはU64) はビッグエンディアンバイト順序 (最上位バイト順) を使用します。この要素が1の場合、イベント内のすべてのマルチバイト要素はリトルエンディアンバイト順序を使用します (最下位バイトが先)。

最適なパフォーマンスを得るには、コンピューティングプラットフォームにネイティブなバイト順序を使用することをお勧めします。これは通常、WindowsおよびPXI LabVIEW Real-Timeではリトルエンディアン、CompactRIOではビッグエンディアンです。

あるコンピューティングプラットフォームから別のコンピューティングプラットフォームへのログファイルの移植性を最大限に高めるには、ビッグエンディアンバイト順序を使用することをお勧めします。

サンプルコードでは、「ログファイルを開く」関数は、必要なバイト順序 (ネイティブまたはビッグエンディアン) を指定するのに使用する入力パラメータを使用します。「開く」関数の後に、すべてのバイトスワップが自動的に処理されます。アプリケーションは、APIを使用してフレームの読み取り/書き込みを行い、「ログファイルの読み取り/書き込み」関数との間で特別なバイトスワップコードなしでフレームを交換することができます。

100ナノ秒間隔の64ビットタイムスタンプです。タイムスタンプ形式は、絶対（日付/時間）または相対（ゼロベース）です。

NI-XNETでは、タイムスタンプ形式は常に絶対形式です。LabVIEWでの開発では、NI-XNETフレーム内のタイムスタンプはLabVIEWタイムスタンプタイプで、サンプルコードはファイルI/Oの一部としてU64に変換します。C/C++での開発では、NI-XNETフレーム内のタイムスタンプはU64です（この要素と同じ）。

NI-CANでは、デフォルトのタイムスタンプ形式は絶対形式ですが、必要に応じて相対時間を構成できます。LabVIEWでの開発では、NI-CANフレーム内のタイムスタンプは浮動小数点（DBL）秒です。サンプルコードは、このタイムスタンプをファイルI/Oの一部としてU64に変換します。C/C++ での NI-CAN 開発では、NI-CAN フレーム内のタイムスタンプは、リトルエンディアン順の 2 つの U32 要素です。

LabVIEW FPGA開発では、タイムスタンプ形式は常に相対的です。タイムスタンプは、リトルエンディアン順序の2つのU32要素です。

フレームの識別子です。

タイプがCANフレームを指定する場合、ビット29 (16進数で20000000) はCAN識別子の形式 (拡張の場合はset、標準の場合はclear) を示します。ビット29がクリアの場合、下位11ビット（0～10）にCANフレーム識別子が含まれます。ビット29が設定されている場合、下位29ビット（0～28）にCANフレーム識別子が含まれます。

タイプがFlexRayフレームを指定する場合、下位16ビットにはスロット番号が含まれます。

未使用ビットはすべてゼロです。

イベント（フレーム）のタイプです。

この要素はフレームの基本タイプを指定します。Identifier、Flags、およびInfo要素の解釈は、各タイプで異なります。

NI-XNET開発では、これはCANおよびFlexRayフレームのタイプ要素に対応します。

LabVIEW での NI-CAN 開発では、これは CAN および LIN フレームの IsRemote 要素に対応します。

C/C++（または他の言語）でのNI-CAN開発では、これはCANおよびLINフレームのFrameType要素に対応します。

LabVIEW FPGA開発では、これはCANフレームのタイプ要素に対応します。

この要素の上位4ビットはプロトコル (16進数) を指定します。

• 0 CAN
• 1 LIN
• 2 FlexRay
• 3D予約済み (未使用)
• E なし (プロトコルとは無関係)
• Fカスタム (ログファイルのユーザ固有のタイプのみ)

この要素の下位4ビットは特定のタイプです。

16進数で最も一般的なタイプは、00（CANデータフレーム）、01（CANリモートフレーム）、12（LINフルフレーム）、20（FlexRayデータフレーム）、21（FlexRayヌルフレーム）です。その他のタイプについては、APIドキュメントを参照してください。

カスタムカテゴリ (上位4ビットのF) は、ログファイルで使用するように設計されています。組込ネットワークフレームにこのログファイル形式を使用する他に、アナログまたはデジタル測定、フロントパネルのボタンが押された時間などの他のデータをエンコードする必要がある場合があります。このようなカスタムイベントを作成する場合、APIの今後のバージョンでは「読み取り」関数からそのタイプが返されないことに注意してください。また、「API書き込み」関数でこれらのカスタムイベントを無視することもできます。00～EFの16進数タイプはすべてNI製品用に予約されていますが、F0～FFタイプはカスタムタイプとして使用できます。これらのカスタムタイプの1つを使用する場合、NI製品はイベントを無視します。識別子、フラグ、情報、およびペイロードの定義はユーザ次第です。他社とログファイルを交換する場合は、カスタムタイプの異なる定義間の競合を避けるため、.ncl (または異なる署名) とは異なるファイル拡張子を使用することをお勧めします。

カスタムフレームタイプと情報要素の上位2ビット以外は、イベントのその他のすべてのビットはNI製品が将来使用できるように予約されていると想定する必要があります。現在使用されていないビット（識別子のビット30と31）では、「API読み取り」関数は常に0を返し、「API書き込み」に渡されるフレームには常に0を使用する必要があります。

フレームのタイプを指定する8つのブールフラグです。

この要素はNI-XNETに存在します。CANおよびFlexRayで使用されます（詳細については、NI-XNETのドキュメントを参照してください）。

この要素はNI-CANフレームに存在しません。

この要素はLabVIEW FPGA CANフレーム（InfoA）に存在しますが、現在は使用されていません（将来のために予約されています）。

フレームのタイプを限定する情報です。

この要素はNI-XNETに存在します。CANには使用されません。FlexRayフレームでは、フレームのサイクルカウント（0～63）を提供します。

この要素はNI-CANフレームに存在しません。

この要素はLabVIEW FPGA CANフレーム（InfoB）に存在しますが、現在は使用されていません（将来のために予約されています）。

この要素の上位2ビットは、タイプ要素のカスタム範囲と同様に、カスタム専用です。この2つのカスタムビットにより、CAN、LIN、およびFlexRayフレーム（NI範囲内のタイプ）に情報を追加できます。API読み取りは常に2つのカスタムビットを0として返しますが、ログファイルに書き込む前に独自のビットでORを実行することもできます。ログファイルからフレームを読み取り、「API書き込み」関数に渡す場合、APIはこれら2つのカスタムビットの値を無視します。

ペイロードの長さは、ペイロードの有効なデータバイト数を示します。

すべてのCANおよびLINフレームで、ペイロード長は8を超えることはできません。このベースユニットには常に8バイトのペイロードデータが含まれているため、CAN/LINフレーム全体がベースユニットに含まれ、追加のペイロードユニットは存在しません。

FlexRayフレームでは、ペイロードの長さの範囲は0～254バイトです。PayloadLengthが0～8の場合、基本単位のみが存在します。PayloadLengthが9以上の場合、1つ以上のペイロード単位が基本単位に従います。追加のペイロードユニットは、DMA転送の効率を最適化するために8バイト単位で提供されます。たとえば、PayloadLengthが9の場合、バイト0～7はベースユニットのペイロード内にあり、バイト8は次のペイロードユニットの最初のバイトにあり、次のペイロードユニットの最後の7バイトは無視されます。

つまり、生データの各フレームの長さは異なる場合があります。各フレームのサイズ（バイト単位）は、擬似コードを使用して計算できます。

U16 FrameSize; // 最大のFlexRayフレームに対して最大272
  FrameSize = 24; // 24バイト基本単位
  if (ペイロードの長さ > 8)
    FrameSize = FrameSize +
      (U16)(ペイロード長 - 1) AND 0xFFF8;

擬似コードの最後の行は1を減算し、最も近い8の倍数に切り捨てます（ビット単位のANDを使用）。これにより、追加のペイロードユニットのバイトが追加されます。たとえば、PayloadLengthが9～16の場合、8バイトのペイロード単位が1つ必要になります。

サンプルコードは、この可変長フレームエンコーディングの詳細をユーザに代わって処理します。