Aunque el formato de archivo de registro NCL es compatible para la compatibilidad, el formato de archivo de registro TDMS se recomienda para nuevas aplicaciones. Para obtener más información, consulte Datos de red incrustados en TDMS.
El archivo de registro creado con la especificación NI-XNET Logfile no se puede utilizar con una aplicación diseñada para la especificación NI-CAN Logfile.
Los archivos de registro de NI-CAN se pueden utilizar con aplicaciones diseñadas para la especificación de archivo de registro NI-XNET.
La especificación de archivo de registro NI-CAN fue diseñada para cumplir con las siguientes características:
La extensión de archivo utilizada por todos los archivos de registro NI-CAN es:
.ncl
Todos los productos de NI-CAN asumen que cualquier archivo con esta extensión cumple completamente con esta especificación.
NI proporciona código fuente para acceder a los archivos de registro NI-CAN. Si incorpora el código fuente a su aplicación sin cambios, puede seguir utilizando la extensión .ncl para los archivos utilizados por esa aplicación.
Si cambia el código de los archivos de registro NI-CAN, incluso de una manera aparentemente compatible, debe cambiar la extensión de archivo de .ncl a alguna otra extensión. Esta nueva extensión de archivo identifica sus archivos como conformes a su propia especificación y, por lo tanto, garantiza que el archivo no será malinterpretado por los productos de software de NI para CAN.
La especificación utiliza los siguientes tipos para cada campo:
U8 8 bit entero sin signo
U16 Número entero sin signo de 16 bits, big-endian, alineado en desplazamiento de 16 bits en el archivo
U32 32 bits entero sin signo, big-endian, alineado en 32 bits offset en el archivo
U64 64 bits entero sin signo, big-endian, alineado en desplazamiento de 64 bits en el archivo
El encabezado es la primera secuencia de campos en el archivo de registro. Solo existe un encabezado por archivo de registro.
| Campo | Tipo | Descripción |
| Firma | U16 | Un valor fijo para todos los archivos de registro NI-CAN, utilizado para validar que la codificación binaria del archivo cumple con esta especificación. El valor es hexadecimal 4E49 (“NI” en ASCII). |
| HeaderSize | U16 | Tamaño del encabezado en múltiplos de u32 (incrementos de 4 bytes), incluyendo Signature y HeaderSize. El archivo de registro NI-CAN está diseñado para admitir el análisis con matrices de u32. |
| HeaderMajorVersión | U8 | Versión principal para el encabezado (es decir, 1 en 1.5). Esto indica un cambio que rompe la compatibilidad con la versión anterior. |
| HeaderUpgradeVersión | U8 | Versión de actualización para el encabezado (es decir, 5 en 1.5). Esto indica un cambio que conserva la compatibilidad con la versión 0 de actualización. |
| EventMajorVersión | U8 | Versión principal para todos los eventos en el archivo. Esto indica un cambio que rompe la compatibilidad con la versión anterior. |
| EventUpgradeVersión | U8 | Actualizar la versión para todos los eventos del archivo. Esto indica un cambio que conserva la compatibilidad con la versión 0 de actualización. |
Tabla 1: NI-CAN Logfile Información de cabecera
Para esta especificación, el encabezado debe consistir siempre en la siguiente secuencia de bytes en hexadecimal:
4E 49 00 02 01 00 01 00
Después del encabezado, el archivo de registro NI-CAN contendrá cero o más eventos. Cada evento normalmente representa una sola trama CAN, pero también puede codificar otra información como errores o desencadenantes.
Para esta versión de la especificación, el tamaño de cada evento en el archivo de registro es el mismo. Este tamaño fijo es de 24 bytes (como se muestra en la tabla siguiente). Dado que el tamaño del encabezado y el tamaño de cada evento son fijos, a menudo puede determinar el número de eventos a partir del tamaño del archivo.
En el texto siguiente, la frase función Net Interface Read hace referencia a la función NI-CAN Frame API Read para la interfaz de red. Dependiendo del entorno de desarrollo de aplicaciones que utilice, esto se puede encontrar en el Manual de hardware y software NI-CAN en:
Se recomienda encarecidamente que el primer fotograma del archivo de registro consista en un fotograma desencadenante de inicio NI-CAN (tipo 4). El disparador de inicio contiene una marca de tiempo absoluta (fecha/hora) para el inicio de la medición CAN, así como una indicación del formato de marca de tiempo para las tramas CAN posteriores (absolutas o relativas). Si falta el desencadenante de inicio en un archivo de registro, se supone que el inicio de la medición CAN es el mismo que la marca de tiempo de la primera trama CAN. Para obtener más información sobre el marco de activación de inicio, consulte la función Net Interface Read.
Campo | Tipo | Descripción |
Marca de tiempo | U64 | Marca de tiempo de 64 bits en incrementos de 100 nanosegundos. El formato de marca de tiempo puede ser absoluto (fecha/hora) o relativo (base cero). Para el desarrollo NI-CAN en LabVIEW, la marca de tiempo dentro de las tramas NI-CAN es de coma flotante (DBL) segundos. Para acceder a los archivos de registro, debe convertir esta marca de tiempo flotante a/desde dos campos U32 (consulte los ejemplos). Las funciones de E/S de archivos binarios de LabVIEW utilizan big-endian, por lo que simplemente puede acceder al U32 más significativo seguido del U32 menos significativo. Para el desarrollo NI-CAN en C/C++ (u otros lenguajes), la marca de tiempo dentro de las tramas NI-CAN es de dos campos U32. Dado que cada U32 en NI-CAN se almacena como little-endian (byte menos significativo primero), debe intercambiar el orden de bytes antes de acceder al archivo de registro. Para el desarrollo FPGA LabVIEW, la marca de tiempo es de dos campos U32. Las funciones de E/S de archivos binarios de LabVIEW utilizan big-endian, por lo que simplemente puede acceder al U32 más significativo seguido del U32 menos significativo. |
Identificador | U32 | Identificador de la trama CAN. El bit 29 (hexadecimal 0x20000000 ) indica el formato del identificador CAN: set for extended, clear for standard. Las convenciones para el intercambio de bytes coinciden con la técnica descrita para cada porción U32 de la marca de tiempo. |
Tipo | U8 | Tipo de evento (frame). Este campo es 0 para indicar una trama de datos CAN y 1 para indicar una trama remota CAN. NI-CAN admite valores adicionales. Para el desarrollo NI-CAN en LabVIEW, esto corresponde al campo IsRemote en el marco CAN. Para obtener información sobre tipos distintos de marcos CAN, consulte la función Net Interface Read. Para el desarrollo NI-CAN en C/C++ (u otros lenguajes), esto corresponde al campo FrameType en la trama CAN. Para obtener información sobre tipos distintos de marcos CAN, consulte la función Net Interface Read. Para el desarrollo de FPGA LabVIEW, esto corresponde al campo Tipo en el marco CAN. LabVIEW FPGA admite solo tramas de datos CAN y tramas remotas CAN. |
InfoA | U8 | Información que califica el Tipo. Esta información no existe para NI-CAN. Esta información existe para LabVIEW FPGA, pero actualmente no se utiliza (reservada para el futuro). Al leer el archivo de registro, debe ignorar este campo. Al escribir el archivo de registro debe establecer este campo en cero. |
InfoB | U8 | Información que califica el Tipo. Debe interpretar este campo igual que InfoA (ignorar). |
Longitud de datos | U8 | Para las tramas de datos CAN, DataLength indica el número de bytes válidos en Data. Para las tramas remotas CAN, DataLength indica los bytes solicitados, no el número de bytes válidos en Data. Para todos los demás valores de Tipo de trama, DataLength indica el número de bytes válidos en Data. |
Datos | U8 | Este campo siempre contiene 8 bytes en el archivo de registro, pero el número de bytes válidos a menudo está determinado por DataLength. |
Tabla 2: NI-CAN Logfile Información del evento