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.
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.
Les Spécifications du fichier journal NI-CAN ont été conçues pour répondre aux caractéristiques suivantes :
L'extension de fichier utilisée par tous les fichiers journaux NI-CAN est:
.ncl.ncl
Tous les produits NI-CAN supposent que tout fichier avec cette extension est entièrement conforme à cette spécification.
NI fournit le code source pour l'accès aux fichiers journaux NI-CAN. 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 changez le code des fichiers journaux NI-CAN, 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 CAN.
La spécification utilise les types suivants pour chaque champ :
U8 8 bits entier non signé
U16 16 bits entier non signé, big endian, aligné à offset 16 bits dans le fichier
U32 32 bits entier non signé, big endian, aligné à offset 32 bits dans le fichier
U64 64 bits entier non signé, big-endian, aligné à offset 64 bits dans le fichier
L'en-tête est la première séquence de champs du fichier journal. Un seul en-tête existe par fichier journal.
| Champ | Type | Description |
| Signature | U16 | Valeur fixe pour tous les fichiers journaux NI-CAN, 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), Signature et HeaderSize comprises. Le fichier journal NI-CAN est conçu pour supporter l'analyse avec des tableaux de u32. |
| 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. |
| VersionSuppressionEn-tête | U8 | Version de mise à niveau pour l'en-tête (par exemple 5 en 1.5). Ceci indique un changement qui reste compatible 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. |
| VersionSurclassementÉvénement | U8 | Version de mise à niveau pour tous les événements du fichier. Ceci indique un changement qui reste compatible avec la version de mise à niveau 0. |
Table 1 : Informations d'en-tête de fichier journal NI-CAN
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 02 01 00 01 00
Après l'en-tête, le fichier journal NI-CAN contiendra zéro événement ou plus. Chaque événement représente généralement une seule trame CAN, mais il peut aussi encoder d'autres informations telles que des erreurs ou des déclenchements.
Pour cette version de la spécification, la taille de chaque événement du fichier journal est la même. Cette taille fixe est de 24 octets (comme indiqué dans le tableau suivant). Étant donné que la taille de l’en-tête et celle de chaque événement sont fixes, vous pouvez souvent déterminer le nombre d’événements à partir de la taille du fichier.
Dans le texte qui suit, l ' expression < < fonction Net Interface Read > > fait référence à la fonction NI-CAN Frame API Read pour l ' interface réseau. Selon l ' environnement de développement d ' applications que vous utilisez, vous pouvez le trouver dans le Manuel du matériel et des logiciels NI-CAN dans l ' un des documents suivants :
Il est vivement recommandé que la première étape du fichier journal consiste en une étape de déclenchement de démarrage NI-CAN (type 4). Le déclenchement de démarrage contient un horodatage absolu (date/heure) pour le démarrage de la mesure CAN, ainsi qu'une indication du format d'horodatage pour les trames CAN suivantes (absolues ou relatives). Si le déclenchement de démarrage est absent d'un fichier journal, le début de la mesure CAN est supposé être le même que l'horodatage de la première trame CAN. Pour en savoir plus sur la trame de déclenchement de démarrage, reportez-vous à la fonction Lire une interface réseau.
Champ | 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 le développement NI-CAN dans LabVIEW, l'horodatage dans les trames NI-CAN est en virgule flottante (DBL) secondes. Pour accéder au fichier journal, vous devez convertir cet horodatage flottant en deux champs U32 (voir exemples). Les fonctions d’E/S sur fichiers binaires de LabVIEW utilisent big-endian, vous pouvez donc accéder simplement au U32 de poids fort suivi du U32 de poids faible. Pour le développement NI-CAN en C/C++ (ou d'autres langages), l'horodatage dans les trames NI-CAN est de deux champs U32. Comme chaque U32 de NI-CAN est stocké comme little-endian (octet de poids faible en premier), vous devez permuter l'ordre des octets avant d'accéder au fichier journal. Pour le développement LabVIEW FPGA, l'horodatage est de deux champs U32. Les fonctions d’E/S sur fichiers binaires de LabVIEW utilisent big-endian, vous pouvez donc accéder simplement au U32 de poids fort suivi du U32 de poids faible. |
Identificateur | U32 | Identificateur de la trame CAN. Le bit 29 (hex 0x20000000 ) indique le format de l'identificateur CAN : défini pour étendu, clair pour standard. Les conventions de permutation d'octets correspondent à la technique décrite pour chaque partie U32 de l'Horodatage. |
Type | U8 | Type d'événement (trame). Ce champ est 0 pour indiquer une trame de données CAN et 1 pour indiquer une trame distante CAN. NI-CAN supporte des valeurs supplémentaires. Pour le développement NI-CAN dans LabVIEW, cela correspond au champ IsRemote de la trame CAN. Pour obtenir des informations sur les types autres que les trames CAN, reportez-vous à la fonction Lire une interface réseau. Pour le développement NI-CAN en C/C++ (ou d'autres langages), cela correspond au champ FrameType de la trame CAN. Pour obtenir des informations sur les types autres que les trames CAN, reportez-vous à la fonction Lire une interface réseau. Pour le développement LabVIEW FPGA, cela correspond au champ Type dans la trame CAN. LabVIEW FPGA ne supporte que les trames de données CAN et les trames distantes CAN. |
InfoA | U8 | Informations qui qualifient le Type. NI-CAN n'a pas accès à cette information. Ces informations existent pour LabVIEW FPGA, mais actuellement elles ne sont pas utilisées (réservées pour l'avenir). Lors de la lecture du fichier journal, vous devriez ignorer ce champ. Lors de l'écriture du fichier journal, vous devez définir ce champ à zéro. |
InfoB | U8 | Informations qui qualifient le Type. Vous devez interpréter ce champ comme InfoA (ignorer). |
LongDonnées | U8 | Pour les trames de données CAN, DataLength indique le nombre d'octets valides dans Data. Pour les trames distantes CAN, DataLength indique les octets demandés, et non le nombre d'octets valides dans Data. Pour toutes les autres valeurs de Type de trame, la LongueurDonnées indique le nombre d'octets valides dans Données. |
Données | U8 | Ce champ contient toujours 8 octets dans le fichier journal, mais le nombre d'octets valides est souvent déterminé par DataLength. |
Tableau 2 : Informations sur l'événement Fichier journal NI-CAN