NCL 로그파일 형식은 호환성을 위해 지원되지만, TDMS 로그파일 형식이 새로운 어플리케이션에 권장됩니다. 자세한 내용은 TDMS의 임베디드 네트워크 데이터를 참조하십시오.
NI-XNET 로그파일 스펙으로 생성된 로그파일은 NI-CAN 로그파일 스펙을 위해 설계된 어플리케이션과 함께 사용할 수 없습니다.
NI-CAN 로그파일은 NI-XNET 로그파일 스펙에 따라 설계된 어플리케이션과 함께 사용할 수 있습니다.
NI-CAN Logfile Specification은 다음과 같은 특성을 충족하도록 설계되었습니다.
모든 NI-CAN 로그파일이 사용하는 파일 확장자는 다음과 같습니다.
.ncl
모든 NI-CAN 제품은 이 확장자를 가진 모든 파일이 이 스펙을 완전히 준수한다고 가정합니다.
NI는 NI-CAN 로그파일에 대한 액세스를 위한 소스 코드를 제공합니다. 변경 없이 소스 코드를 어플리케이션에 통합하는 경우, 해당 어플리케이션에서 사용하는 파일에 대해 계속해서 .ncl 확장자를 사용할 수 있습니다.
NI-CAN 로그파일의 코드를 호환되는 방식으로라도 변경하는 경우, .ncl 파일 확장자를 다른 확장자로 변경해야 합니다. 이 새 파일 확장자는 파일이 사용자 고유의 스펙을 준수하는 것으로 식별되도록 하므로, CAN용 NI 소프트웨어 제품이 파일을 잘못 해석하지 않습니다.
이 스펙은 각 필드에 대해 다음 타입을 사용합니다.
U8 8비트 부호 없는 정수
U16 16비트 부호 없는 정수, 빅 엔디언, 파일의 16비트 오프셋에 정렬
U32 32비트 부호 없는 정수, 빅 엔디언, 파일의 32비트 오프셋에 정렬
U64 64비트 부호 없는 정수, 빅 엔디언, 파일의 64비트 오프셋에 정렬
헤더는 로그파일의 첫 번째 필드 시퀀스입니다. 로그파일당 하나의 헤더만 존재합니다.
| 필드 | 타입 | 설명 |
| 서명 | U16 | 파일의 2진 인코딩이 이 스펙을 준수하는지 확인하는 데 사용되는 모든 NI-CAN 로그파일의 고정 값. 값은 16진수 4E49 (ASCII에서 "NI")입니다. |
| 헤더 크기 | U16 | Signature 및 HeaderSize를 포함하여 u32의 배수 (4바이트 단위)로 표시되는 헤더의 크기. NI-CAN 로그파일은 u32 배열로 파싱을 지원하도록 설계되었습니다. |
| 헤더주요버전 | U8 | 헤더의 주요 버전 (예: 1.5에서 1). 이는 이전 버전과의 호환성을 끊는 변경을 나타냅니다. |
| 헤더업그레이드버전 | U8 | 헤더의 업그레이드 버전 (예: 1.5에서 5). 이는 업그레이드 버전 0과 호환성이 유지된 변경을 나타냅니다. |
| 이벤트주요버전 | U8 | 파일 내 모든 이벤트의 주요 버전. 이는 이전 버전과의 호환성을 끊는 변경을 나타냅니다. |
| 이벤트업그레이드버전 | U8 | 파일 내 모든 이벤트의 업그레이드 버전. 이는 업그레이드 버전 0과 호환성이 유지된 변경을 나타냅니다. |
표 1: NI-CAN 로그파일 헤더 정보
이 스펙의 경우, 헤더는 항상 16진수로 표시되는 다음 바이트 시퀀스로 구성되어야 합니다.
4E 49 00 02 01 00 01 00
헤더 다음에 NI-CAN 로그파일에는 0개 이상의 이벤트가 포함됩니다. 일반적으로 각 이벤트는 하나의 CAN 프레임을 나타내지만, 오류 또는 트리거와 같은 다른 정보를 인코딩할 수도 있습니다.
이 스펙 버전에서 로그파일의 각 이벤트 크기는 동일합니다. 이 고정 크기는 다음 표와 같이 24바이트입니다. 헤더의 크기와 각 이벤트의 크기가 고정되어 있으므로, 파일 크기에서 이벤트 개수를 결정할 수 있는 경우가 많습니다.
이후 텍스트에서 [네트워크 인터페이스 읽기] 함수는 네트워크 인터페이스에 대한 [NI-CAN 프레임 API 읽기] 함수의 참조를 의미합니다. 사용 중인 어플리케이션 개발 환경에 따라 NI-CAN 하드웨어 및 소프트웨어 매뉴얼에서 다음 중 하나에서 찾을 수 있습니다.
로그파일의 첫 번째 프레임은 NI-CAN 시작 트리거 프레임 (타입 4)으로 구성하는 것이 강력히 권장됩니다. 시작 트리거는 CAN 측정 시작에 대한 절대 타임스탬프 (날짜/시간)와 이후 CAN 프레임 (절대 또는 상대)에 대한 타임스탬프 형식을 나타냅니다. 로그파일에 시작 트리거가 없는 경우, CAN 측정의 시작은 첫 번째 CAN 프레임의 타임스탬프와 동일하다고 간주합니다. 시작 트리거 프레임에 대한 자세한 내용은 [네트워크 인터페이스 읽기] 함수를 참조하십시오.
필드 | 타입 | 설명 |
타임스탬프 | U64 | 100나노초 증분의 64비트 타임스탬프. 타임스탬프 형식은 절대 (날짜/시간) 또는 상대 (제로 기반)일 수 있습니다. LabVIEW에서 NI-CAN 개발 시, NI-CAN 프레임 내 타임스탬프는 배정밀도 부동소수점 (DBL) 초입니다. 로그파일 접근을 위해서는 이 부동소수점 타임스탬프를 두 개의 U32 필드로 변환해야 합니다 (예제 참조). LabVIEW의 2진 파일 I/O 함수는 빅 엔디언을 사용하므로, 최상위 U32와 그 뒤의 최하위 U32에 바로 접근할 수 있습니다. C/C++ (또는 다른 언어)에서 NI-CAN 개발 시, NI-CAN 프레임 내의 타임스탬프는 두 개의 U32 필드입니다. NI-CAN의 각 U32는 리틀 엔디언 (최하위 바이트 우선)으로 저장되므로, 로그파일에 접근하기 전에 바이트 순서를 변경해야 합니다. LabVIEW FPGA 개발의 경우, 타임스탬프는 두 개의 U32 필드입니다. LabVIEW의 2진 파일 I/O 함수는 빅 엔디언을 사용하므로, 최상위 U32와 그 뒤의 최하위 U32에 바로 접근할 수 있습니다. |
식별자 | U32 | CAN 프레임의 식별자. 비트 29 (16진수 0x20000000)는 CAN 식별자의 형식을 나타냅니다: 확장형이면 설정, 표준이면 해제. 바이트 교환 규약은 타임스탬프의 각 U32 부분에 대해 설명된 기법과 일치합니다. |
유형 | U8 | 이벤트 타입 (프레임). 이 필드는 CAN 데이터 프레임을 나타낼 때 0, CAN 원격 프레임을 나타낼 때 1입니다. NI-CAN은 추가적인 값을 지원합니다. LabVIEW에서 NI-CAN 개발 시, 이는 CAN 프레임의 IsRemote 필드에 해당합니다. CAN 프레임 이외의 타입에 대한 정보는 Net Interface Read 함수를 참조하십시오. C/C++ (또는 다른 언어)에서 NI-CAN 개발 시, 이는 CAN 프레임의 FrameType 필드에 해당합니다. CAN 프레임 이외의 타입에 대한 정보는 Net Interface Read 함수를 참조하십시오. LabVIEW FPGA 개발의 경우, 이는 CAN 프레임의 Type 필드에 해당합니다. LabVIEW FPGA는 CAN 데이터 프레임과 CAN 원격 프레임만 지원합니다. |
정보A | U8 | 타입을 규정하는 정보. 이 정보는 NI-CAN에는 존재하지 않습니다. 이 정보는 LabVIEW FPGA에 존재하지만 현재 사용되지 않습니다 (향후 예약됨). 로그파일을 읽을 때에는 이 필드를 무시해야 합니다. 로그파일을 작성할 때 반드시 이 필드를 0으로 설정해야 합니다. |
정보B | U8 | 타입을 규정하는 정보. 이 필드는 InfoA (무시)와 동일하게 해석해야 합니다. |
데이터 길이 | U8 | CAN 데이터 프레임의 경우, DataLength는 데이터의 유효한 바이트 수를 나타냅니다. CAN 원격 프레임의 경우, DataLength는 데이터의 유효한 바이트 수가 아니라 요청된 바이트 수를 나타냅니다. 다른 모든 프레임 타입 값의 경우, DataLength는 데이터의 유효한 바이트 수를 나타냅니다. |
데이터 | U8 | 이 필드는 항상 로그파일에 8바이트를 포함하지만, 유효한 바이트 수는 데이터 길이로 결정되는 경우가 많습니다. |
표 2: NI-CAN 로그파일 이벤트 정보