Bien que le format de fichier journal NCL soit supporté pour la compatibilité, le format de fichier journal TDMS est recommandé pour les nouvelles applications. Pour en savoir plus, reportez-vous à Embedded Network Data in TDMS.
Objectif de la spécification du fichier journal NI-XNET :
Le fichier journal créé avec les Spécifications du fichier journal NI-XNET ne peut pas être utilisé avec une application conçue pour les Spécifications du fichier journal NI-CAN.
Les fichiers journaux NI-CAN peuvent être utilisés avec des applications conçues pour avec la spécification de fichier journal NI-XNET.
L'extension de fichier utilisée par les fichiers journaux NI-XNET est:
.ncl.ncl
Tous les produits de réseau embarqué NI supposent que tout fichier avec cette extension est entièrement conforme à cette spécification.
NI fournit le code source pour accéder aux fichiers journaux NI-XNET. Si vous incorporez le code source dans votre application sans modification, vous pouvez continuer à utiliser l'extension .ncl pour les fichiers utilisés par cette application.
Si vous modifiez l'encodage des fichiers journaux NI-XNET, même d'une manière apparemment compatible, vous devez changer l'extension de fichier de .ncl à une autre extension. Cette nouvelle extension de fichier identifie vos fichiers comme une plainte selon vos propres spécifications et garantit donc que le fichier ne sera pas mal interprété par les produits logiciels NI pour les réseaux embarqués.
La spécification utilise les types suivants pour chaque élément :
est un entier 8 bits non signé U8
Entier U16 16 bits non signé, aligné à offset 16 bits dans le fichier
U32 32 bits entier non signé, aligné à offset 32 bits dans le fichier
Entier non signé U64 64 bits, aligné à offset 64 bits dans le fichier
Dans l'En-tête, les éléments de type U16, U32 ou U64 utilisent l'ordre des octets Big Endian (octet de poids fort en premier). Dans chaque événement (trame), les éléments multi-octets utilisent l'ordre des octets spécifié par l'élément EventIsLittleEndian de l'en-tête.
Dans le texte qui suit, le terme API désigne le logiciel National Instruments que vous utilisez pour accéder au matériel des réseaux embarqués. Ceci est des nœuds CAN NI-XNET, NI-CAN ou LabVIEW FPGA.
Dans le format de trame brute NI-XNET, les éléments de U16, U32 ou U64 utilisent toujours l'ordre des octets natif. Comme cet ordre natif des octets peut différer de l'élément EventIsLittleEndian d'un fichier journal, c'est la seule différence entre le format NI-XNET et le format du fichier journal.
L'en-tête est la première séquence d'éléments du fichier journal. Un seul en-tête existe par fichier journal.
| Élément | Type | Description |
| Signature | U16 | Valeur fixe pour tous les fichiers journaux NI-XNET, utilisée pour valider que l’encodage binaire du fichier est conforme à cette spécification. La valeur est hexadécimale 4E49 (« NI » en ASCII). |
| TailleEn-tête | U16 | Taille de l'en-tête en multiples de U32 (incréments de 4 octets), y compris Signature et HeaderSize. |
| En-têteVersionMajeure | U8 | Version majeure pour l'en-tête (par exemple 1 sur 1.5). Ceci indique un changement qui rompt la compatibilité avec la version précédente. |
| VersionSurclassementEn-tête | U8 | Version de mise à niveau pour l'en-tête (par exemple 5 en 1.5). Ceci indique un changement qui conserve la compatibilité avec la version de mise à niveau 0. |
| ÉvénementVersionMajeure | U8 | Version majeure pour tous les événements du fichier. Ceci indique un changement qui rompt la compatibilité avec la version précédente. |
| VersionMiseÀJourÉvénement | U8 | Version de mise à niveau pour tous les événements du fichier. Ceci indique un changement qui conserve la compatibilité avec la version de mise à niveau 0. |
| ÉvénementLittleEndian | U8 | Si cet élément est 0, tous les éléments multi-octets (type U16, U32 ou U64) de l'événement utilisent l'ordre des octets big endian (octet de poids fort en premier). Si cet élément est 1, tous les éléments multi-octets de l'événement utilisent l'ordre des octets de Little Endian (octet de poids faible en premier). Pour des performances optimales, il est recommandé d'utiliser l'ordre des octets qui est natif à votre plate-forme de calcul. Ceci est généralement little-endian pour Windows et PXI LabVIEW Real-Time, et big-endian pour CompactRIO. Pour une meilleure portabilité des fichiers journaux d'une plate-forme informatique à une autre, il est recommandé d'utiliser l'ordre des octets Big Endian. Dans l'exemple de code, la fonction Ouvrir un fichier journal prend un paramètre d'entrée que vous utilisez pour spécifier l'ordre des octets désiré : natif ou big-endian. Après cette fonction Ouvrir, toutes les permutations d'octets sont gérées automatiquement pour vous. Votre application peut lire/écrire des trames à l'aide de l'API et les échanger avec les fonctions Lire/Écrire dans un fichier journal, sans échange spécial d'octets de code entre les deux. |
| (Réservé) | 3 U8 | Les trois octets doivent être 0. Ces octets remplissent l'en-tête de sorte qu'il reste un multiple de 4 octets. |
Pour cette spécification, l'en-tête doit toujours être composé de la séquence d'octets suivante en hexadécimal :
4E 49 00 03 01 01 02 00 XX 00 00 00
XX est EventIsLittleEndian, qui est 0 (big-endian) ou 1 (little-endian).
La mise à niveau de l'en-tête de 1.0 à 1.1 est due à l'ajout de l'élément EventIsLittleEndian. Si l'exemple de code NI-XNET lit l'en-tête 1.0 (HeaderSize 2), il suppose big-endian pour l'événement.
La mise à niveau de l'événement de 1.0 à 2.0 était due à l'ajout de types d'événements pour FlexRay. Contrairement aux trames CAN précédentes, les trames FlexRay peuvent varier en taille. La mise à niveau reflète également la possibilité d'éléments Little Endian (1.0 était toujours Big Endian). Si l'exemple de code NI-XNET lit l'événement 1.0, il suppose que tous les événements sont des trames CAN de 24 octets, avec tous les éléments big-endian.
Après l'en-tête, le fichier journal NI-XNET contiendra zéro événement ou plus. Chaque événement représente généralement une seule étape, mais il peut aussi encoder d'autres informations telles que des erreurs ou des déclenchements.
Chaque événement du fichier journal commence par l'unité de base de 24 octets suivante. L'unité de base est suivie de zéro ou plusieurs unités de charge de 8 octets. Les unités de charge supplémentaires sont requises pour les trames FlexRay, qui peuvent contenir jusqu'à 254 octets de charge totale.
| Élément | Type | Description |
| Horodatage | U64 | Horodatage 64 bits par incréments de 100 nanosecondes. Le format d'horodatage peut être absolu (date/heure) ou relatif (basé sur zéro). Pour NI-XNET, le format d'horodatage est toujours absolu. Pour le développement dans LabVIEW, l'horodatage dans les trames NI-XNET est de type horodatage LabVIEW, que l'exemple de code convertit en U64 dans le cadre des E/S sur fichiers. Pour le développement en C/C++, l'horodatage dans les trames NI-XNET est U64 (identique à cet élément). Pour NI-CAN, le format d'horodatage par défaut est absolu, mais vous pouvez configurer le temps relatif si vous le souhaitez. Pour le développement dans LabVIEW, l'horodatage dans les trames NI-CAN est en secondes à virgule flottante (DBL), que l'exemple de code convertit en U64 dans le cadre des E/S sur fichiers. Pour le développement NI-CAN en C/C++, l'horodatage dans les trames NI-CAN est de deux éléments U32 dans l'ordre Little Endian. Pour le développement LabVIEW FPGA, le format d'horodatage est toujours relatif. L'horodatage est deux éléments U32 dans l'ordre Little Endian. |
| Identificateur | U32 | Identificateur de la trame. Lorsque Type spécifie une trame CAN, le bit 29 (hex 20000000) indique le format de l'identificateur CAN : défini pour étendu, clair pour standard. Si le bit 29 est effacé, les 11 bits inférieurs (0-10) contiennent l'identificateur de trame CAN. Si le bit 29 est défini, les 29 bits inférieurs (0-28) contiennent l'identificateur de trame CAN. Quand Type spécifie une trame FlexRay, les 16 bits inférieurs contiennent le numéro de l'emplacement. Tous les bits inutilisés sont zéro. |
| Type | U8 | Type d'événement (trame). Cet élément spécifie le type fondamental de l'étape. L'interprétation des éléments Identificateur, Marqueurs et Info est différente pour chaque type. Pour le développement NI-XNET, cela correspond à l'élément Type des trames CAN et FlexRay. Pour le développement NI-CAN dans LabVIEW, cela correspond à l'élément IsRemote des trames CAN et LIN. Pour le développement NI-CAN en C/C++ (ou d'autres langages), cela correspond à l'élément FrameType des trames CAN et LIN. Pour le développement LabVIEW FPGA, cela correspond à l'élément Type de la trame CAN. Les 4 bits supérieurs de cet élément spécifient le protocole (hexadécimal) :
Les 4 bits inférieurs de cet élément sont du type spécifique. Les types les plus courants en hexadécimal sont 00 (trame de données CAN), 01 (trame distante CAN), 12 (trame complète LIN), 20 (trame de données FlexRay) et 21 (trame nulle FlexRay). Reportez-vous à la documentation de votre API pour d'autres types. La catégorie Personnalisée (F en 4 bits supérieur) est spécialement conçue pour être utilisée dans les fichiers journaux. En plus d'utiliser ce format de fichier journal pour les trames réseau embarquées, vous devrez peut-être encoder d'autres données, telles que des mesures analogiques ou numériques, ou le moment où vous appuyez sur un bouton de la face-avant. Lorsque vous créez de tels événements personnalisés, vous devez savoir que les futures versions de l'API ne renverront pas ce type à partir de la fonction Lire. De plus, vous voudrez peut-être que la fonction API Write ignore ces événements personnalisés. Bien que tous les types de 00 à EF hex soient réservés à l'utilisation par les produits NI, les types F0 à FF sont disponibles comme types personnalisés. Lorsque vous utilisez l'un de ces types personnalisés, les produits NI ignorent l'événement. La définition de l'identificateur, des marqueurs, des infos et de la charge utile dépend de vous. Si vous avez l'intention d'échanger des fichiers journaux avec d'autres sociétés, nous vous recommandons d'utiliser une extension de fichier différente de .ncl (ou une autre Signature), afin d'éviter les conflits entre différentes définitions de types personnalisés. En dehors du Type de trame personnalisé et des 2 bits supérieurs de l'élément Info, vous devez supposer que tous les autres bits de l'événement sont réservés pour une utilisation future par les produits NI. Pour les bits actuellement inutilisés (par exemple, les bits 30 et 31 de l'Identificateur), la fonction API Lire renverra toujours 0, et vous devez toujours utiliser 0 pour les trames passées à l'API Écrire. |
| Flags | U8 | Huit marqueurs booléens qui qualifient le Type de trame. NI-XNET contient cet élément. Il est utilisé pour CAN et FlexRay (voir la documentation NI-XNET pour plus de détails). Cet élément n'existe pas dans les trames NI-CAN. Cet élément existe dans les trames LabVIEW FPGA CAN (InfoA), mais actuellement il n'est pas utilisé (réservé pour l'avenir). |
| Info | U8 | Informations qui qualifient le Type de trame. NI-XNET contient cet élément. Il n'est pas utilisé pour CAN. Pour les trames FlexRay, il fournit le nombre de périodes pour la trame (0 à 63). Cet élément n'existe pas dans les trames NI-CAN. Cet élément existe dans les trames LabVIEW FPGA CAN (InfoB), mais actuellement il n'est pas utilisé (réservé pour l'avenir). Les 2 bits supérieurs de cet élément sont dédiés à une utilisation personnalisée, un peu comme la gamme Personnalisée pour l'élément Type. Ces 2 bits personnalisés vous permettent d'ajouter des informations aux trames CAN, LIN et FlexRay (types de la gamme NI). L'API Lire renverra toujours les 2 bits personnalisés comme 0, mais vous pouvez OU dans vos propres bits avant d'écrire dans le fichier journal. Si vous voulez lire des trames d'un fichier journal et les passer à la fonction API Write, l'API ignorera toute valeur de ces 2 bits personnalisés. |
| PayloadLength | U8 | La valeur PayloadLength indique le nombre d'octets de données valides dans Payload. Pour toutes les trames CAN et LIN, PayloadLength ne peut pas dépasser 8. Comme cette unité de base inclut toujours 8 octets de données de charge, toute la trame CAN/LIN est contenue dans l'unité de base et il n'existe pas d'unités de charge supplémentaires. Pour les trames FlexRay, PayloadLength va de 0 à 254 octets. Si PayloadLength est compris entre 0 et 8, seule l'unité de base existe. Si PayloadLength est supérieur ou égal à 9, une ou plusieurs unités de charge suivent l'unité de base. Des unités de charge supplémentaires sont fournies par incréments de 8 octets, pour optimiser l’efficacité des transferts DMA. Par exemple, si PayloadLength est 9, les octets 0-7 sont dans la charge de l'unité de base, l'octet 8 est dans le premier octet de l'unité de charge suivante et les sept derniers octets de l'unité de charge suivante sont ignorés. En d'autres termes, chaque étape des données brutes peut varier en longueur. La taille (en octets) de chaque trame peut être calculée en utilisant le pseudo-code : U16 FrameSize; // maximum 272 pour la plus grande trame FlexRay La dernière ligne du pseudo-code soustrait 1 et tronque au multiple de 8 le plus proche (en utilisant ET bit à bit). Cela ajoute des octets pour des unités de charge supplémentaires. Par exemple, PayloadLength de 9 à 16 nécessite une unité de charge supplémentaire de 8 octets. L'exemple de code gère les détails de cet encodage de trame de longueur variable en votre nom. |
| Charge utile | 8 U8 | Cet élément utilise toujours 8 octets dans le fichier journal, mais le nombre d'octets valides est déterminé par PayloadLength. |
Le nombre d'unités de charge supplémentaires (0 à 31) est déterminé par l'élément PayloadLength de l'unité de base.
| Élément | Type | Description |
| Charge utile | 8 U8 | Cet élément utilise toujours 8 octets dans le fichier journal, mais le nombre d'octets valides est déterminé par PayloadLength. |
Les spécifications du fichier journal NI-XNET sont également installées avec NI-XNET (généralement à C:\Program Files\National Instruments\NI-XNET\Documentation)