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.
Objetivos de la especificación de archivo de registro NI-XNET:
El archivo de registro creado con la especificación NI-XNET Logfile no se puede utilizar con una aplicación diseñada para las especificaciones NI-CAN Logfile.
Los archivos de registro NI-CAN se pueden utilizar con aplicaciones diseñadas para la especificación de archivo de registro NI-XNET.
La extensión de archivo utilizada por los archivos de registro NI-XNET es:
.ncl.ncl
Todos los productos de red embebidos de NI 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-XNET. Si incorpora el código fuente a su aplicación sin cambios, puede seguir usando la extensión .ncl para los archivos utilizados por esa aplicación.
Si cambia la codificación de los archivos de registro NI-XNET, 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 redes embebidas.
La especificación utiliza los siguientes tipos para cada elemento:
U8 8 bit entero sin signo
U16 Número entero sin signo de 16 bits, alineado en desplazamiento de 16 bits en el archivo
U32 32 bits entero sin signo, alineado en el desplazamiento de 32 bits en el archivo
U64 64 bits entero sin signo, alineado en desplazamiento de 64 bits en el archivo
Dentro de la cabecera, los elementos de tipo U16, U32 o U64 usan el orden de bytes endian grande (el byte más significativo primero). Dentro de cada Evento (trama), los elementos de varios bytes utilizan el orden de bytes especificado por el elemento EventIsLittleEndian del encabezado.
En el texto siguiente, el término API se refiere al software de National Instruments que utiliza para acceder al hardware de redes incrustadas. Estos son los nodos NI-XNET, NI-CAN o LabVIEW FPGA CAN.
Dentro del formato de tramas sin procesar NI-XNET, los elementos de U16, U32 o U64 siempre utilizan el orden de bytes nativo. Dado que ese orden de bytes nativo puede diferir del elemento EventIsLittleEndian en un archivo de registro, esta es la única diferencia entre el formato NI-XNET y el formato de archivo de registro.
El encabezado es la primera secuencia de elementos del archivo de registro. Solo existe un encabezado por archivo de registro.
| Elemento | Tipo | Descripción |
| Firma | U16 | Un valor fijo para todos los archivos de registro NI-XNET, 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. |
| 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 del archivo. Esto indica un cambio que rompe la compatibilidad con la versión anterior. |
| EventUpgradeVersion | U8 | Versión de actualización para todos los eventos del archivo. Esto indica un cambio que conserva la compatibilidad con la versión 0 de actualización. |
| EventIsLittleEndian | U8 | Si este elemento es 0, todos los elementos de varios bytes (tipo U16, U32 o U64) en el evento usan el orden de bytes big-endian (el byte más significativo primero). Si este elemento es 1, todos los elementos de varios bytes en el Evento usan un orden de bytes little-endian (primero el byte menos significativo). Para un rendimiento óptimo, se recomienda utilizar el orden de bytes que es nativo de su plataforma de computación. Esto es típicamente little-endian para Windows y PXI LabVIEW Real-Time, y big-endian para CompactRIO. Para la mejor portabilidad de los archivos de registro de una plataforma de computación a otra, se recomienda usar el orden de bytes big-endian. En el código de ejemplo, la función Abrir archivo de registro toma un parámetro de entrada que se utiliza para especificar el orden de bytes deseado: nativo o big-endian. Después de esa función Abrir, todo el intercambio de bytes se gestiona automáticamente. Su aplicación puede leer/escribir fotogramas usando la API e intercambiarlos con las funciones de archivo de registro de lectura/escritura, sin necesidad de intercambiar códigos de bytes especiales entre ellos. |
| (reservado) | 3 U8 | Los tres bytes deben ser cero. Estos bytes rellenan la cabecera de tal manera que permanece un múltiplo de 4 bytes de tamaño. |
Para esta especificación, el encabezado debe consistir siempre en la siguiente secuencia de bytes en hexadecimal:
4E 49 00 03 01 01 02 00 XX 00 00 00
XX es EventIsLittleEndian, que es 0 (big-endian) o 1 (little-endian).
La actualización del encabezado de 1.0 a 1.1 se debió a la adición del elemento EventIsLittleEndian. Si el código de ejemplo NI-XNET lee el encabezado 1.0 (HeaderSize 2), asume big-endian para el evento.
La actualización del evento de 1.0 a 2.0 se debió a la adición de tipos de eventos para FlexRay. A diferencia de los marcos CAN anteriores, los marcos FlexRay pueden variar de tamaño. La actualización también refleja la posibilidad de elementos little-endian (1.0 siempre fue big-endian). Si el código de ejemplo NI-XNET lee el evento 1.0, asume que todos los eventos son tramas CAN de 24 bytes, con todos los elementos big-endian.
Después del encabezado, el archivo de registro NI-XNET contendrá cero o más eventos. Cada evento normalmente representa una sola trama, pero también puede codificar otra información como errores o desencadenantes.
Cada evento en el archivo de registro comienza con la siguiente unidad base de 24 bytes. La unidad base es seguida por cero o más unidades de carga útil de 8 bytes. Las unidades de carga útil adicionales son necesarias para las tramas FlexRay, que pueden contener hasta 254 bytes de carga útil total.
| Elemento | Tipo | Descripción |
| Timestamp | 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 NI-XNET, el formato de sello de tiempo es siempre absoluto. Para el desarrollo en LabVIEW, la marca de tiempo dentro de los marcos NI-XNET es el tipo de marca de tiempo LabVIEW, que el código de ejemplo convierte a U64 como parte de la E/S del archivo. Para el desarrollo en C/C++, la marca de tiempo dentro de las tramas NI-XNET es U64 (igual que este elemento). Para NI-CAN, el formato de marca de tiempo predeterminado es absoluto, pero puede configurar el tiempo relativo si lo desea. Para el desarrollo en LabVIEW, la marca de tiempo dentro de los marcos NI-CAN es de coma flotante (DBL) segundos, que el código de ejemplo convierte a U64 como parte de la E/S del archivo. Para el desarrollo NI-CAN en C/C++, la marca de tiempo dentro de las tramas NI-CAN es de dos elementos U32 en orden little-endian. Para el desarrollo de FPGA LabVIEW, el formato de marca de tiempo es siempre relativo. La marca de tiempo es de dos elementos U32 en orden little-endian. |
| Identificador | U32 | Identificador del marco. Cuando Type especifica una trama CAN, el bit 29 (hexadecimal 20000000) indica el formato del identificador CAN: set for extended, clear for standard. Si el bit 29 está claro, los 11 bits inferiores (0-10) contienen el identificador de trama CAN. Si se establece el bit 29, los 29 bits inferiores (0-28) contienen el identificador de trama CAN. Cuando Type especifica una trama FlexRay, los 16 bits inferiores contienen el número de ranura. Todos los bits no usados son cero. |
| Tipo | U8 | Tipo de evento (marco). Este elemento especifica el tipo fundamental del marco. La interpretación de los elementos Identificador, Banderas e Info es diferente para cada tipo. Para el desarrollo NI-XNET, esto corresponde al elemento Type en las tramas CAN y FlexRay. Para el desarrollo NI-CAN en LabVIEW, esto corresponde al elemento IsRemote en las tramas CAN y LIN. Para el desarrollo NI-CAN en C/C++ (u otros lenguajes), esto corresponde al elemento FrameType en las tramas CAN y LIN. Para el desarrollo FPGA LabVIEW, esto corresponde al elemento Type en el marco CAN. Los 4 bits superiores de este elemento especifican el protocolo (hexadecimal):
Los 4 bits inferiores de este elemento son del tipo específico. Los tipos más comunes en hexadecimal son 00 (cuadro de datos CAN), 01 (cuadro remoto CAN), 12 (cuadro completo LIN), 20 (cuadro de datos FlexRay) y 21 (cuadro nulo FlexRay). Consulte la documentación de su API para otros tipos. La categoría Personalizada (F en 4 bits superiores) está diseñada específicamente para su uso en archivos de registro. Además de usar este formato de archivo de registro para marcos de red incrustados, es posible que deba codificar otros datos, como mediciones analógicas o digitales, o el tiempo que se presiona un botón del panel frontal. Cuando cree eventos personalizados de este tipo, debe saber que las versiones futuras de la API no devolverán ese tipo desde la función Leer. Además, es posible que desee que la función API Write ignore estos eventos personalizados. Aunque todos los tipos de 00 a EF hex están reservados para su uso por los productos NI, los tipos F0 a FF están disponibles para usted como tipos personalizados. Cuando utiliza uno de estos tipos personalizados, los productos NI ignoran el evento. La definición del identificador, banderas, información y carga útil depende de usted. Si tiene la intención de intercambiar archivos de registro con otras empresas, recomendamos utilizar una extensión de archivo diferente a .ncl (o una firma diferente), para evitar conflictos entre las diferentes definiciones de tipos personalizados. Aparte del Tipo de fotograma personalizado y los 2 bits superiores del elemento Info, debe asumir que todos los demás bits del evento están reservados para su uso futuro por los productos NI. Para los bits que no se utilizan actualmente (es decir, los bits 30 y 31 de Identifier), la función API Read siempre devolverá 0, y siempre debe usar 0 para los fotogramas pasados a API Write. |
| Banderas | U8 | Ocho banderas booleanas que califican el Tipo de marco. Este elemento existe en NI-XNET. Se utiliza para CAN y FlexRay (consulte la documentación NI-XNET para más detalles). Este elemento no existe en los marcos NI-CAN. Este elemento existe en LabVIEW FPGA CAN frames (InfoA), pero actualmente no se utiliza (reservado para el futuro). |
| Info | U8 | Información que califica el Tipo de fotograma. Este elemento existe en NI-XNET. No se utiliza para CAN. Para fotogramas FlexRay, proporciona el recuento de ciclos para el fotograma (0 a 63). Este elemento no existe en los marcos NI-CAN. Este elemento existe en LabVIEW FPGA CAN frames (InfoB), pero actualmente no se utiliza (reservado para el futuro). Los 2 bits superiores de este elemento están dedicados al uso personalizado, al igual que el rango personalizado para el elemento Tipo. Estos 2 bits personalizados le permiten agregar información a los marcos CAN, LIN y FlexRay (tipos en el rango NI). La API Read siempre devolverá los 2 bits personalizados como 0, pero puede O en sus propios bits antes de escribir en el archivo de registro. Si desea leer fotogramas de un archivo de registro y pasarlos a la función API Write, la API ignorará cualquier valor en estos 2 bits personalizados. |
| Longitud de carga | U8 | La longitud de la carga útil indica el número de bytes de datos válidos en la carga útil. Para todas las tramas CAN y LIN, PayloadLength no puede exceder de 8. Dado que esta unidad base siempre incluye 8 bytes de datos de carga útil, toda la trama CAN/LIN está contenida en la unidad base y no existen unidades de carga útil adicionales. Para tramas FlexRay, PayloadLength varía de 0 a 254 bytes. Si PayloadLength es 0 a 8, solo existe la unidad base. Si PayloadLength es 9 o mayor, una o más unidades de carga útil siguen a la unidad base. Se proporcionan unidades de carga útil adicionales en incrementos de 8 bytes, para optimizar la eficiencia de las transferencias de DMA. Por ejemplo, si PayloadLength es 9, los bytes 0-7 están en la carga útil de la unidad base, el byte 8 está en el primer byte de la siguiente unidad de carga útil y se ignoran los últimos siete bytes de la siguiente unidad de carga útil. En otras palabras, cada fotograma en los datos sin procesar puede variar en longitud. El tamaño (en bytes) de cada trama se puede calcular utilizando el pseudocódigo: U16 FrameSize; // máximo 272 para el cuadro FlexRay más grande La última línea en el pseudocódigo resta uno, y trunca al múltiplo de 8 más cercano (usando AND bit a bit). Esto agrega bytes para unidades de carga útil adicionales. Por ejemplo, PayloadLength de 9 a 16 requiere una unidad de carga adicional de 8 bytes. El código de ejemplo maneja los detalles de esta codificación de trama de longitud variable en su nombre. |
| Carga útil | 8 U8 | Este elemento siempre utiliza 8 bytes en el archivo de registro, pero el número de bytes válidos se determina por PayloadLength. |
El número de unidades de carga útil adicionales (0 a 31) viene determinado por el elemento Longitud de carga útil de la unidad base.
| Elemento | Tipo | Descripción |
| Carga útil | 8 U8 | Este elemento siempre utiliza 8 bytes en el archivo de registro, pero el número de bytes válidos se determina por PayloadLength. |
Las especificaciones NI-XNET Logfile también se instalan con NI-XNET (normalmente en C:\Archivos de programa\National Instruments\NI-XNET\Documentación)