GPIB 에러 코드 및 일반적인 해결책

에러 조건: 드라이버 에러.

설명: GPIB 하드웨어가 올바르게 구성되지 않거나, 인터페이스 이름 또는 ibfind 함수에 전달된 디바이스 이름이 올바르지 않으면 EDVR이 반환됩니다.

예상되는 원인: 보드의 인터페이스 이름이나 인스트루먼트의 디바이스 이름을 잘못 쓸 때 EDVR 에러가 발생하는 경우가 많습니다. 예를 들어, NI 보드의 기본 인터페이스 이름은 GPIB0이지만, GPIBO(0이 아닌 "oh")로 잘못 작성할 수 있습니다. ibdev 함수에 전달된 보드 인덱스가 올바르지 않은 경우에도 이 에러가 발생할 수 있습니다. 보드 인덱스는 GPIB 보드의 인터페이스 이름의 숫자 부분이지만, 많은 사람들이 보드의 주요 주소라고 잘못 가정합니다. 예를 들어, PCI-GPIB 보드를 컴퓨터에 설치하고 2의 주요 주소를 제공할 수도 있습니다. 보드의 기본 인터페이스 이름은 GPIB0이기 때문에 보드 인덱스는 0이 아니라 2입니다.

해결책:

• GPIB 설정 유틸리티에서 GPIB 하드웨어에 대한 기본 설정을 사용합니다(예: 인터페이스 이름은 GPIB0이고 기본 주소는 0).
• ibfind 함수 대신 ibdev 함수를 사용하여 인스트루먼트와의 통신을 열 수 있습니다(디바이스 이름 사용을 피하려면).
• 인스트루먼트에 디바이스 이름을 사용해야 하는 경우, GPIB 구성 유틸리티의 디바이스 템플릿에서 디바이스 이름이 올바르게 구성되었는지 확인하십시오(자세한 내용은 NI-488.2 사용자 매뉴얼을 참조하십시오).
• 다음 NI-488 함수에서 ibdev 또는 ibfind에서 반환된 단위 설명자를 첫번째 파라미터로 사용합니다. 실패하는 함수 전에 변수를 확인하여 그 값이 손상되지 않았는지 확인합니다.

에러 조건: 함수는 GPIB 보드가 CIC (Controller-In-Charge)이어야 합니다.

설명: 특정 함수의 경우 GPIB 보드가 CIC이어야 합니다. 이러한 함수는 NI-488.2 함수 참조 매뉴얼(아래 관련 링크 참조)에 설명되어 있습니다. 기본으로, GPIB 보드는 시스템 컨트롤러가 되지만, 이는 담당 컨트롤러와는 다릅니다. 시스템 컨트롤러는 언제든지 CIC가 될 수 있습니다(주어진 범용 인터페이스 버스에 하나의 시스템 컨트롤러가 있을 수 있습니다).

예상되는 원인: GPIB 보드가 CIC인지 확인하기 위해 프로그램을 시작할 때 인터페이스를 지우지 않아도 ECIC 에러가 발생하는 경우가 자주 있습니다.

해결책:

• GPIB 보드가 시스템 컨트롤러인 경우, ibrsc 1을 사용하여 GPIB 보드를 시스템 컨트롤러로 구성하십시오.
• GPIB 보드가 System Controller인 경우, ibsic 함수(또는 SendIFC 함수)를 사용하여 인터페이스 지우기를 보냅니다. 이렇게 하면 GPIB 보드가 CIC(버스에서 GPIB 통신을 리셋)가 됩니다.
• GPIB 보드가 버스에 있는 여러 컨트롤러 중 하나인 경우, GPIB 보드가 CIC 상태가 되도록 요구하는 함수 호출을 시도하기 전에 항상 상태 단어의 CIC 비트(ibsta)를 확인하십시오. 보이지 않는 경우, 컨트롤이 GPIB 보드에 전달될 때까지 추가 처리를 지연시키기 위해 ibwait 함수를 호출할 수 있습니다(CIC 비트에 대기 마스크를 설정).

에러 조건: 함수가 리스너를 감지하지 않았습니다.

설명: GPIB 통신에는 하나의 토커(데이터 메시지 쓰기)와 하나 이상의 리스너(데이터 메시지 읽기)가 필요합니다. 일반적으로 ENOL은 쓰기 작업이 시도되었지만, 지정된 주소에 리스너가 없거나 리스너가 없을 때 발생합니다. 디바이스 쓰기에서 ENOL은 통신하려는 GPIB 주소가 버스에 연결된 디바이스의 GPIB 주소와 일치하지 않음을 나타냅니다.

예상되는 원인: 통신하려는 인스트루먼트가 예상되는 주요 주소에 있지 않거나, 인스트루먼트의 전원이 켜져 있지 않거나, 인스트루먼트의 케이블이 연결이 끊겼거나 깨졌습니다.

해결책:

• 디바이스의 GPIB 주소가 데이터를 쓰려는 디바이스의 GPIB 주소와 일치하는지 확인합니다.
• 케이블이 인스트루먼트에 올바르게 연결되어 있는지 확인합니다. 케이블을 스위칭하여 케이블이 깨지지 않은지 확인합니다.
• 디바이스의 2/3 이상의 전원이 켜져 있는지 확인합니다.
• 보드 레벨 통신의 경우, ibcmd 함수에서 적절한 16진 코드를 사용하여 디바이스를 리스너로 지정합니다.
• 필요한 경우 ibpad 함수(또는 ibsad)를 호출하여 디바이스의 기본 주소를 설정합니다. ibpad 함수는 디바이스의 이전 설정을 반환하고 설정된 주소가 디바이스의 실제 주소와 일치하는지 확인할 수 있습니다.

에러 조건: GPIB 보드(GPIB0 또는 GPIB1)의 주소가 올바르지 않습니다.

설명: EADR은 GPIB 보드가 CIC (Controller-In-Charge)이고 읽기 및 쓰기 함수를 읽기 전에 적절하게 주소를 지정하지 않을 때 발생합니다. 또한 쉐도우 핸드쉐이크 기능이 요청되고 GPIB ATN 라인이 이미 지정되지 않은 경우 함수 ibgts에 의해 EADR이 반환됩니다. 이 경우, 쉐도우 핸드쉐이크는 가능하지 않으며 에러가 반환되어 이를 알려줍니다.

예상되는 원인: GPIB 보드는 통신하려는 인스트루먼트와 같은 주요 주소로 설정되어 있습니다.

해결책:

• GPIB 보드를 디바이스와 같은 주소로 설정하지 마십시오. GPIB 보드를 기본 주소 0으로 설정하고 보조 주소를 설정하지 않은 상태로 두어야 합니다. 프로그램 시작 시 ibpad 0 및 ibsad 0에 전화하여 보드 주소를 올바르게 구성합니다.
• ibrd, ibwrt, RcvRespMsg, 또는 SendDataBytes를 호출하기 전에 GPIB 보드의 주소가 올바른지 확인하십시오.
• ibcmd 호출 직후를 제외하고는 ibgts를 호출하지 마십시오. ibcmd 함수는 ATN 라인을 지정하도록 하며, 이는 인스트루먼트가 데이터 메시지 대신 명령 메시지를 기대하도록 합니다.

에러 조건: 함수 호출에 유효하지 않은 인수.

설명: 유효하지 않은 인수가 함수 호출에 전달되면 EARG 결과가 발생합니다.

예상되는 원인: 다음은 몇 가지 예입니다: 0에서 17 사이의 범위가 아닌 값으로 ibtmo를 호출합니다(가능한 타임아웃 값은 0에서 17 사이의 값의 테이블에 대응하며, 기본값은 13이며, 이는 10초 타임아웃을 나타냅니다); 두 번째 파라미터의 높은 바이트에 설정된 의미없는 비트로 ibeos를 호출하거나, 유효하지 않은 주소로 ibpad (또는 ibsad)를 호출합니다.

해결책:

• 파라미터가 유효한지 확인하려면 NI-488.2 함수 참조 매뉴얼(아래 관련 링크 참조)을 참조하십시오.
• 보드 레벨 함수에서는 디바이스 설명자를 사용하거나 디바이스 레벨 함수에서는 보드 설명자를 사용하지 마십시오.

에러 조건: GPIB 보드는 필요에 따라 시스템 컨트롤러가 아닙니다.

설명: GPIB 보드에 시스템 컨트롤러 기능이 없는 경우, ESAC 결과는 ibsic, ibsre, SendIFC, 또는 EnableRemote가 호출될 때 발생합니다.

예상되는 원인: GPIB 보드가 시스템 컨트롤러가 되도록 설정되어 있지 않습니다.

해결책:

• ibrsc 1을 호출하거나 GPIB Configuration Utility를 사용하여 GPIB 보드 시스템 컨트롤러 기능을 제공합니다.

에러 조건: I/O 작동 강제 종료.

설명: EABO는 어떤 이유로 인해 I/O 작업이 취소되었음을 나타냅니다.

예상되는 원인: EABO 오류는 일반적으로 읽기 또는 쓰기 작업 중 타임아웃의 결과이지만, I/O 작업이 진행 중일 때 ibstop 함수, ibclr 함수 또는 유사한 함수를 호출하여 발생할 수도 있습니다. PCI 버스 마스터링(사용자 컴퓨터의 BIOS 있는 옵션)이 활성화되어 있지 않은 경우, PCI-GPIB 보드를 사용하여 쓰기 작업 중에 타임아웃을 받을 수 있습니다. 읽는 인스트루먼트가 이전 명령을 이해하지 못하여 사용자에게 쓸 내용이 없는 경우 읽기 작업 중 타임아웃을 받을 수 있습니다. 인스트루먼트가 사용할 수 없는 이유는 다음과 같습니다.

• 인스트루먼트에 대한 메시지가 잘못된 문자열이 될 수 있습니다. 예를 들어, "*IDN?"은 IEEE 488.2 호환 인스트루먼트에 대한 일반적인 식별 쿼리입니다. 이 메시지는 인스트루먼트가 이해하지 못하는 "*IND?"로 잘못 쓰기 쉽기 때문에 인스트루먼트에서 읽을 메시지 문자열을 생성하지 않습니다.
• 인스트루먼트에 보내는 메시지에 인스트루먼트가 이해하지 못하는 명령이 포함될 수 있습니다. 예를 들어, 위의 예에서 "*IDN?" 메시지는 IEEE 488.2 호환 인스트루먼트에서만 이해할 수 있습니다. 인스트루먼트가 이전 버전의 디바이스인 경우, "*IDN?"을(를) 이해하지 못하므로 인스트루먼트에서 읽을 메시지 문자열을 생성하지 않습니다.
• 인스트루먼트는 종료 방법으로 특정 EOS (문자열 끝) 문자를 사용할 수 있지만, 이 종료 문자를 메시지에 추가하는 것을 잊을 수 있습니다. 예를 들어, 인스트루먼트가 EOS 문자로 라인 피드를 예상하는 경우, "ID?"는 작동하지 않습니다. "ID?"는 작동하지 않습니다.\n" (여기서 \n 은 IBIC)에서 라인 피드를 나타냅니다.
• 종료 방법으로 EOI(끝 또는 식별, 5개 버스 관리 라인 중 하나)를 볼 수 있지만, 인스트루먼트가 메시지 전송을 마칠 때 EOI 라인을 설정하지 않는 경우, 수행하는 모든 읽기 작업은 타임아웃됩니다.

해결책:

• 메시지는 인스트루먼트가 이해하는 명령으로 구성되어 있는지 확인합니다. 사용하는 디바이스의 사용자 매뉴얼에서 가능한 명령 리스트를 확인합니다.
• 사용자 매뉴얼을 확인하여 인스트루먼트가 GPIB 리스너가 되려면 GPIB 모드 또는 488.2 모드여야 하는지 확인합니다.  종종 인스트루먼트는 표준 명령을 이 모드에 놓은 후에만 응답하며, 그렇지 않은 경우 유효한 명령이 전송되더라도 에러가 발생합니다.
• 인스트루먼트에 올바른 종료 방법을 사용하고 있는지 확인합니다. 바이트 카운트(메시지에서 특정한 바이트 수를 받을 것으로 예상되는 경우)는 항상 사용되지만, 일부 인스트루먼트는 EOS와 바이트 카운트를 사용하고, 일부는 EOI와 바이트 카운트를 사용하고, 일부는 바이트 카운트만을 사용합니다. 디바이스의 사용자 매뉴얼을 확인하여 인스트루먼트와 함께 사용할 종료 방법을 확인하십시오.
• EOS가 종료 방법인 경우, 종료 문자를 메시지의 끝에 추가해야 합니다. GPIB 구성 유틸리티에서 종단 문자를 지정할 수 있지만, NI-488.2 드라이버는 자동으로 이를 추가하지 않습니다!
• ibtmo 명령을 사용하여 I/O 작업의 타임아웃 기간을 연장합니다.
• 모든 데이터를 수신하고 EABO 에러가 발생한 경우, 특정한 문자열 끝 문자를 찾습니다(예: 라인 피드 또는 캐리지 리턴) 그리고 ibeos 함수를 사용하여 해당 문자의 읽기를 종료하도록 GPIB 보드를 구성합니다.

에러 조건: 존재하지 않는 GPIB 보드.

설명: ENEB는 GPIB 설정 유틸리티에서 지정한 I/O 주소에 GPIB 보드가 존재하지 않을 때 발생합니다. 이 문제는 보드가 시스템에 물리적으로 연결되어 있지 않거나, 설정 중 지정된 I/O 주소가 실제 보드 셋팅과 일치하지 않거나, 기본 I/O 주소와 시스템이 충돌하거나, 보드의 인터페이스 이름이 디바이스와 연관된 보드의 인터페이스 이름과 다를 때 발생합니다.

해결책:

• GPIB 설정 유틸리티에서 보드의 기본 I/O 주소를 확인합니다. 시스템의 리소스 관리자에서 다른 보드가 이 주소 범위의 일부 또는 전체를 사용하려고 하는지 확인합니다. 디바이스가 통신하도록 설정된 보드의 인터페이스 이름과 보드의 인터페이스 이름이 같아야 합니다.
• 레거시 보드의 경우, 보드의 점퍼와 다이프 스위치가 GPIB 설정 유틸리티가 사용하고 있다고 생각하는 것과 같은 리소스 셋팅으로 설정되도록 합니다.
• 컴퓨터의 전원을 끄고 보드가 슬롯에 잘 고정되어 있는지 확인합니다.

에러 조건: 데이터 전송을 위해 DMA를 사용할 때 에러가 발생합니다.

설명: EDMA는 NI-488.2 드라이버가 DMA를 사용하여 GPIB를 통해 데이터의 전송을 시도할 때 시스템 DMA 에러가 발생하는 경우 발생합니다.

해결책:

• 하드웨어의 EDMA 문제는 GPIB 구성 유틸리티를 사용하여 GPIB 보드가 DMA 리소스를 사용하지 않도록 재구성함으로써 해결할 수 있습니다.
• 소프트웨어의 EDMA 문제는 ibdma 함수를 사용하여 DMA를 비활성화함으로써 해결할 수 있습니다.

에러 조건: 비동기 I/O가 진행 중일 때 함수를 사용할 수 없습니다.

설명: EOIP는 비동기 I/O 작업이 끝나지 않았는데 다른 GPIB 호출이 이루어진 경우 발생합니다. 비동기 I/O 작업이 진행 중일 때에는 ibstop, ibnotify, ibwait 또는 ibonl 함수만 사용할 수 있습니다. 다른 GPIB 호출이 시도될 경우 EOIP가 반환됩니다.

예상되는 원인: 비동기 I/O가 진행 중일 때 지원되지 않는 GPIB 함수 호출이 이루어졌습니다.

솔루션:

• 추가로 GPIB 호출을 생성하기 전에 드라이버와 어플리케이션을 재동기화하십시오. 다음 함수 중 하나를 사용하여 재동기화가 이루어집니다: ibnotify ( ibnotify 콜백에 전달된 ibsta 값이 CMPL을 포함하는 경우 드라이버와 어플리케이션이 재동기화), ibwait (반환된 ibsta가 CMPL을 포함하는 경우 드라이버와 어플리케이션이 재동기화), ibstop (이것은 비동기화 I/O 작업을 취소하여 드라이버와 어플리케이션이 즉시 재동기화되도록 합니다), 또는 ibonl (이것은 비동기화 I/O 작업을 취소하고 인터페이스가 리셋되어 드라이버와 어플리케이션이 즉시 재동기화됩니다).

에러 조건: 작업을 실행할 수 없음.

설명: ECAP는 GPIB 보드에서 작업을 실행할 수 없거나 소프트웨어에서 특정 기능이 비활성화되었는데 해당 기능이 필요한 호출이 이루어진 경우 발생합니다.

솔루션:

• 호출의 유효성을 확인하거나 GPIB 인터페이스 보드와 드라이버에 필요한 기능이 있는지 확인하십시오.

에러 조건: 파일 시스템 오류입니다.

설명: EFSO는 ibrdf 또는 ibwrtf 호출이 파일 작업을 수행하는 중에 문제가 발생한 경우입니다. 구체적으로, 이 에러는 함수가 액세스 중인 파일을 열거나 만들거나 찾거나 쓰거나 닫을 수 없음을 나타냅니다. 이 조건의 구체적인 운영 체제 에러 코드는 ibcntl에 포함되어 있습니다.

해결책:

• 지정한 파일 이름, 경로 및 드라이버가 올바른지 확인하십시오.
• 파일의 액세스 모드가 올바른지 확인하십시오. 예를 들어, 읽기 전용 파일에 대해 쓰기를 시도하지 않습니다.
• 드라이버에 파일을 보관할 공간이 충분한지 확인하십시오.

에러 조건: 명령 바이트 전송 에러입니다.

설명: EBUS는 디바이스 함수 실행 중에 특정 GPIB 버스 에러가 발생하는 경우 발생합니다. 모든 디바이스 함수는 주소 지정 및 기타 버스 관리 작업을 수행하기 위해 명령 바이트를 보냅니다. 디바이스는 기본 구성 또는 ibtmo 함수에 지정된 제한 시간 내에 이러한 명령 바이트를 받습니다. EBUS는 이러한 명령 바이트를 보낼 때 시간 초과가 발생한 경우 발생합니다.

예상되는 원인: GPIB 디바이스가 GPIB 컨트롤러에 연결되어 있지 않습니다. 모든 계측기가 꺼져 있거나, 계측기 중 하나에서 에러가 발생하여 핸드쉐이킹 라인을 지정하고 있거나, 보드에서 GPIB 케이블이 분리되었거나, GPIB 케이블이 손상되었을 수 있습니다.

해결책:

• 모든 계측기가 올바르게 작동하고 있고 통신하려는 계측기에 전원이 켜져 있는지 확인하십시오.
• 모든 계측기를 분리한 다음 하나씩 연결하면서 어느 계측기가 문제의 원인이 되는지 확인하십시오.
• 느슨하게 연결되었거나 결함이 있는 케이블이 없는지 확인하고, 계측기의 2/3 이상에서 전원이 켜져 있는지 확인하십시오(IEEE 488 사양의 요구 사항).
• 드라이버가 명령 바이트를 보내기에 타임아웃 기간이 너무 짧은 경우, 타임아웃 기간을 늘리십시오.

에러 조건: 시리얼 폴 상태 바이트가 손실되었습니다.

설명: ESTB는 ibrsp 함수에 의해서만 보고됩니다. ESTB는 자동 직렬 폴에서 수신된 하나 이상의 직렬 폴 상태 바이트가 저장 공간 부족으로 인해 버려졌음을 나타냅니다. 몇 개의 이전 상태 바이트는 남아 있지만, 가장 오래된 바이트는 ibrsp 호출에 의해 반환되고 있습니다.

예상되는 원인: 인스트루먼트가 반복적으로 SRQ 라인을 지정하고 있습니다.

해결책:

• ibrsp을 더 자주 호출하여 대기열을 비웁니다.
• ibconfig 함수를 사용하여 자동 풀링을 비활성화(옵션 IbcAUTOPOLL)하거나 GPIB 구성 유틸리티에서 자동 폴링을 비활성화하십시오.

에러 조건: SRQ가 ON 위치에 고정되어 있습니다.

설명: ESRQ는 상태 워드(ibsta)의 RSQ 비트가 반환되면 ibwait 함수가 반환되도록 구성한 디바이스 레벨의 ibwait 호출에 의해서만 반환될 수 있습니다. ESRQ는 GPIB SRQ 라인이 ON에 고정되어 있기 때문에 RQS를 기다리는 것이 불가능함을 나타냅니다.

예상되는 원인: 이 상황은 케이블 문제가 SRQ 라인이 지정된 상태로 유지되도록 하는 경우, 소프트웨어에 알려지지 않은 디바이스가 SRQ 라인을 지정하는 경우(소프트웨어가 이 디바이스를 알지 못하므로 디바이스를 직렬 폴링하여 SRQ 라인을 지정 해제할 수 없음), GPIB 버스 테스터(또는 이와 비슷한 장비)가 SRQ 라인을 지정되도록 강제하는 경우 등으로 발생할 수 있습니다.

해결책:

• 버스에 있는 디바이스 중 하나(어플리케이션에서 사용하지 않는 디바이스 포함)가 SRQ 라인을 지정하고 있는지 확인하십시오. 필요 시 GPIB에서 분리하십시오.
• GPIB 케이블을 살펴보고 커넥터가 올바르게 장착되어 있는지 확인하십시오.

에러 조건: 테이블 문제.

설명: ETAB은 FindLstn 함수와 FindRQS 함수가 실행 중일 때만 발생합니다. ETAB은 이러한 함수가 사용하는 테이블에 문제가 있음을 나타냅니다.

예상되는 원인: FindLstn의 경우, ETAB은 주어진 테이블에 리스너가 찾은 주소를 모두 보관할 충분한 공간이 없음을 의미합니다. FindRQS의 경우, ETAB은 주어진 테이블에 있는 디바이스 중에서 서비스를 요청한 디바이스가 없음을 의미합니다.

해결책:

• FindLstn의 경우, 결과 배열의 크기를 늘립니다.
• FindRQS의 경우, 어플리케이션에서 사용하지 않는 다른 디바이스가 SRQ을 지정하고 있는지 확인하십시오. 필요 시 GPIB에서 분리하십시오.

에러 조건: GPIB 인터페이스가 잠겨 있어 액세스할 수 없습니다.

예상되는 원인: 이 에러는 일반적으로 동일한 인터페이스에 액세스하려는 두 개 이상의 프로세스가 있고 한 프로세스가 이미 인터페이스를 잠근 경우 발생합니다. 이 에러는 인터페이스에 적용된 기존 잠금으로 인해 작업을 수행할 수 없는 경우 반환됩니다. 프로세스가 잠금이 존재하지 않는 인터페이스를 잠금 해제하려고 시도하는 경우에도 반환됩니다.

솔루션:

• ELCK 에러를 방지하는 방법은 인터페이스를 다시 잠그려고 시도하기 전에 임의의 시간 동안 기다리는 것입니다. iblck 명령을 사용하여 인터페이스를 잠그는 경우, LockWaitTime을 증가시키고 다른 프로세스가 인터페이스의 컨트롤을 해제할 때까지 기다립니다. 또한 프로세스가 전체 실행 시간 동안 인터페이스를 잠그지 않도록 하십시오.

에러 조건: ibnotify 콜백이 재활성화(Rearm)에 실패했습니다.

예상되는 원인: 이 에러는 NI-488.2 어플리케이션에서 비동기 알림(ibnotify)을 사용할 경우 발생합니다. 이 함수는 하나 이상의 GPIB 이벤트에 대해 어플리케이션에 비동기식으로 알림이 제공되도록 하려는 경우에 유용합니다. 이 이벤트 알림은 콜백 함수에 의해 수행됩니다. 콜백 함수는 ibnotify 호출이 이루어지면 NI-488.2 드라이버에 등록됩니다. 이 에러는 콜백 알림이 잘못된 값을 반환하여 재활성화(Rearm)에 실패했거나 치명적인 드라이버 에러(EDVR)가 발생했음을 나타냅니다.

해결책:

• 콜백 함수가 반환하는 값이 유효한 ibnotify 마스크 값인지 확인하십시오.
• 콜백 함수에서 0 값을 반환하여 비동기 이벤트 알림 메커니즘을 등록 해제하십시오. 그런 다음 ibnotify를 호출하여 알림을 다시 활성화하십시오.

에러 조건: 입력 핸들이 유효하지 않습니다.

예상되는 원인: 몇몇 GPIB 명령은 보드 또는 디바이스의 입력 핸들을 입력 파라미터로 받습니다. 이것이 이 에러의 원인이 될 수 있습니다. 이 에러는 몇 가지 상황에서 발생할 수 있습니다. 다음은 그중 몇 가지 시나리오입니다.

• 유효한 보드 핸들이 디바이스 핸들 파라미터로 전달되었거나 디바이스 핸들 파라미터가 유효한 보드 핸들로 전달되었습니다.
• 유효하지 않은 보드 또는 디바이스 설명자가 NI-488.2 함수의 입력으로 전달되었습니다.
• 0~99의 범위를 벗어나는 보드 ID가 기존 NI-488.2 보드 수준 함수 또는 NI-488.2 루틴으로 전달되었습니다.
• ibconfig 또는 ibmask가 디바이스 유닛 설명자 및 보드 전용 구성 옵션과 함께 호출되었거나 보드 유닛 설명자 및 디바이스 전용 구성 옵션과 함께 호출되었습니다.

해결책:

• 각 함수를 호출할 때 디바이스 수준 및 보드 수준 함수가 혼동되지 않았는지 확인하십시오.
• NI 488.2 호출로 전달된 보드 인덱스가 유효한 인덱스 번호인지도 확인하십시오.

에러 조건: 지정된 입력 핸들에서 대기가 진행 중입니다.

예상되는 원인: 이 에러는 동일한 프로세스에 두 개 이상의 스레드가 있고 두 개 이상의 스레드가 동일한 인터페이스에 액세스할 때 발생합니다. EWIP는 지정된 유닛 설명자에서 이미 ibwait 호출이 진행 중임을 나타내며, 스레드가 동일한 설명자를 사용하여 ibwait을 수행하고 있고 다른 스레드가 동일한 설명자에서 ibwait을 호출하려고 시도할 때 발생합니다.

솔루션:

• 언제든 주어진 유닛 설명자에서 하나의 스레드만 ibwait 호출을 수행하십시오.

에러 조건: 인터페이스의 리셋으로 인해 이벤트 알림이 취소되었습니다.

예상되는 원인: ERST는 인터페이스의 리셋으로 인해 이벤트 알림이 취소된 경우 발생합니다. 드라이버에서 보류 중인 ibwait 호출이 다음과 같은 상황에서 ERST를 반환합니다.

• 동일한 프로세스의 다른 스레드가 ibwait과 동일한 유닛 설명자를 사용하여 ibonl을 호출합니다.
• 다른 스레드 또는 프로세스가 보드 수준의 ibonl 1을 발행합니다.

다음과 같은 상황에서 ibnotify 콜백이 ERST와 함께 호출될 수 있습니다.

• 다른 프로세스가 보드 수준의 ibonl 1을 발행합니다.

해결책:

• 드라이버에서 보류 중인 ibwait 호출과 함께 bonl을 호출하지 않습니다.
• 다른 어플리케이션이 ibonl을 호출할 수 없도록 iblck로 인터페이스를 잠급니다.

에러 조건: 인터페이스의 전원이 끊겼습니다.

예상되는 원인: EPWR은 인터페이스의 전원이 끊어진 경우 발생합니다. 이는 시스템이 대기 상태로 들어가고 대기 상태에서 돌아올 때 종종 발생합니다.

해결책:

• 모든 핸들을 오프라인 상태로 만들고 어플리케이션을 다시 초기화합니다.
• 어플리케이션을 종료하고 시스템을 다시 시작하십시오.
• PC에서 대기 모드와 최대 절전 모드를 비활성화하십시오.

• NI-488.2 사용자 매뉴얼
• GPIB 대화식 컨트롤(IBIC)을 자동으로 시작하고 사용하는 방법