TestStand 코드 모듈 개발 우수 사례

테스트 시스템 개발을 시작하기 전에 테스트 시스템의 다음 측면에 대한 일반적인 접근 방식을 정의하는 것이 좋습니다.

• 코드 모듈 세분성 – 각 모듈의 기능 범위를 정의합니다.
• 테스트 코드용 디렉토리 구조 정의 – 잘 정의된 디렉토리 구조를 통해 보다 쉽게 다른 개발자와 코드를 공유하고 테스트 시스템에 코드를 배포할 수 있습니다.

코드 모듈 세분성

테스트 시스템을 설계할 때 코드 모듈에 대해 일관된 수준의 세분성을 정의하는 것이 중요합니다.  세분성은 테스트 시스템에서 각 코드 모듈 기능의 범위를 나타냅니다.  세분성이 낮은 테스트 시퀀스는 각각 더 많은 기능을 수행하는 코드 모듈을 거의 호출하지 않지만 세분성이 높은 시퀀스는 각각 더 작은 범위를 갖는 많은 코드 모듈을 호출합니다.

각각 장점이 있기 때문에 이러한 극단 사이에서 균형을 목표로 해야 합니다.  

다양한 세분성 수준을 사용하여 간단한 테스트를 구현

테스트 시스템 전반에서 일관된 세분성을 유지하려면 다음과 같이 일련의 코드 모듈 개발 표준을 작성하십시오.

• TestStand가 하드웨어 세션 수명을 관리할 수 있도록 별도의 코드 모듈에서 하드웨어 초기화 및 종료를 수행합니다.
• 각 요구 사항 항목마다 단일 테스트 단계를 생성하여 테스트 요구 사항을 기반으로 세분성을 결정합니다.  이 접근 방식을 통해 보다 쉽게 모든 요구 사항을 충족할 수 있습니다.  또한 NI Requirements Gateway를 TestStand와 함께 사용하여 테스트 단계와 요구 사항 문서 간에 링크를 생성할 수 있습니다.  더 자세한 정보는 NI Requirements Gateway와 TestStand 연결하기 길라잡이를 참조하십시오.
• 원하는 테스트 결과 구조를 사용하여 개별 단계의 범위를 결정합니다.  각 단계에서는 결과 항목을 생성하므로 테스트 단계를 필요한 결과 항목에 일대일로 맵핑하면 보고 작업 또는 데이터베이스 로깅을 최소한으로 변경하여 보다 쉽게 테스트 결과를 구성할 수 있습니다.

시퀀스 파일 및 코드 모듈의 디렉토리 구조 정의

테스트 단계에서 코드 모듈의 경로를 지정할 때 절대 또는 상대 경로를 사용하도록 선택할 수 있습니다. 다음과 같은 이유로 절대 경로는 피하는 것이 좋습니다.

• 시퀀스 파일 및 종속성을 디스크로 이동하는 경우 경로가 더 이상 유효하지 않습니다.
• 시퀀스 파일을 대상 시스템에 배포하는 경우 파일이 동일한 위치에 설치되지 않으면 경로가 유효하지 않습니다.

상대 경로를 지정하면 TestStand가 검색 디렉토리 목록을 사용하여 경로를 분석합니다.  이러한 검색 디렉토리에는 일반적으로 현재 시퀀스 파일 디렉토리, TestStand 관련 디렉토리, 시스템 디렉토리가 포함됩니다.

개발을 시작하기 전에 테스트 시퀀스 및 코드 모듈의 파일 구조를 정의하는 것이 중요합니다.  다음 지침에 따라 시퀀스 파일 및 코드 모듈을 저장하기 위한 전략을 정의하십시오.

• 단일 시퀀스 파일에서 사용되는 코드 모듈의 경우, 코드 모듈 파일을 시퀀스 파일에 상대적인 서브디렉토리에 저장합니다.  이렇게 하면 시스템에서 이동하거나 다른 시스템으로 복사한 경우 시퀀스 파일이 항상 코드 모듈을 찾을 수 있습니다.
• 여러 관련 시퀀스 파일간에 공유되는 코드 모듈의 경우 관련 시퀀스 파일을 동일한 디렉토리에 저장하면 단일 시퀀스 파일과 동일한 방법을 사용할 수 있습니다.  모든 관련 시퀀스 파일 및 코드 모듈을 포함할 작업 공간을 생성하는 것이 좋습니다.
• 관련되지 않은 여러 시퀀스 파일 간에 공유되는 코드 모듈의 경우, 모든 공유 코드 모듈을 포함할 특정 디렉토리를 생성하고 이 위치를 가리키는 새 검색 디렉토리를 생성합니다.  이렇게 하면 시스템의 모든 시퀀스 파일이 이 검색 디렉토리에 대한 상대 경로를 사용하여 파일을 찾을 수 있습니다.  코드 모듈을 배포할 때 <TestStand Application Data>\Cfg\SearchDirectories.cfg에 있는 검색 디렉토리 구성 파일을 배포할 수 있습니다.  이 방법을 사용하는 경우, 시퀀스 파일 호출에 지정된 경로가 끊기지 않도록 디렉토리 내에서 코드 모듈 파일을 이동하지 마십시오.

코드 모듈이 시퀀스 파일의 서브디렉토리에 위치하는 디렉토리 구조를 정의합니다.

TestStand Deployment Utility를 사용하여 테스트 코드를 배포할 때 시퀀스 파일 및 종속 코드 모듈의 특정 대상을 선택할 수 있습니다.  시퀀스 파일의 대상 디렉토리와 코드 모듈 사이에 상대 경로가 존재하면 TestStand Deployment Utility는 업데이트된 위치를 가리키도록 시퀀스 파일의 경로를 업데이트합니다.  대부분의 경우 배포의 디렉토리 구조를 개발 시스템의 디렉터리 구조와 일치시켜 배포가 개발 시스템의 코드와 최대한 유사하도록 하는 것이 가장 좋습니다.

테스트 시스템용 코드 모듈의 범위를 정의할 때 코드 모듈 및 시퀀스 파일 각각에서 구현될 기능에 대한 전략을 정의하는 것이 중요합니다. 다음 섹션은 일반적인 기능을 구현하기에 가장 적합한 위치를 결정하는 데 도움이 될 수 있습니다.

• 리미트에 대한 테스트 측정값 평가
• 자극 값 정의
• 테스트 결과 및 에러 보고 및 로깅
• 작업 루핑
• 스위칭 작업 수행
• 계산 수행 및 데이터 조작

리미트 및 테스트 결과 평가

이상적으로, 코드 모듈은 테스트 측정값 획득과 직접 관련된 기능을 포함해야 하며 테스트 시퀀스는 원시 테스트 결과를 처리해야 합니다. 이 방법에는 다음과 같은 이점이 있습니다.

• 프로퍼티 로더와 같은 도구를 사용하여 단일 중앙 위치에서 여러 단계에 대한 리미트를 관리할 수 있으므로 테스트 리미트는 시퀀스 파일에서 관리하기가 더 쉽습니다.
• 시퀀스에 정의된 테스트 리미트는 보고서 또는 데이터베이스와 같은 테스트 결과에 자동으로 포함됩니다.
• 테스트 리미트는 코드 모듈을 변경하지 않고 업데이트할 수 있으며 테스트 시퀀스만 수정되므로 유효성 검사가 덜 필요합니다.

보다 간단한 측정의 경우 코드 모듈은 처리를 위해 원시 측정값을 시퀀스로 반환할 수 있습니다. 예를 들어, 테스트 단계에서 테스트 대상 유닛(UUT)의 특정 핀에서 전압을 측정하는 경우 코드 모듈에서 직접 검사를 수행하는 대신 코드 모듈이 측정된 값을 반환해야 합니다.  이 값을 처리하면 숫자 리미트 테스트 단계를 사용하여 시퀀스 파일에서 테스트 결과를 판별할 수 있습니다.

테스트 단계에서 리미트를 평가할 경우 코드 모듈이 단순화되고 결과 로깅이 향상됩니다.

그러나 일부 테스트는 복잡하기 때문에 시퀀스 파일에서 원시 테스트 결과를 항상 처리할 수 있는 것은 아닙니다.  보다 복잡한 측정의 경우 결과 데이터를 추가로 처리해야 할 수 있습니다.  복잡한 데이터를 단일 문자열 또는 숫자 결과로 처리한 다음 문자열 또는 숫자 비교를 사용하여 TestStand에서 평가할 수 있습니다.  예를 들어, 주파수 스윕 테스트의 결과는 복잡하고 직접 평가할 수 없지만 데이터를 최소값을 나타내는 단일 숫자로 처리할 수 있습니다.  이 경우, 아래 모바일 디바이스 테스트 예제에 표시된 것처럼 코드 모듈은 처리된 결과를 평가하고 로깅을 위해 별도의 파라미터로 주파수 데이터를 반환해야 합니다.

보다 복잡한 데이터의 경우 코드 모듈에서 데이터를 처리하여 숫자 또는 문자열 결과를 생성하고 로깅을 위해 원시 데이터를 전달합니다.

원시 데이터가 매우 큰 경우 데이터를 TestStand로 전달하면 성능에 상당한 영향을 줄 수 있습니다.  이 경우 데이터를 TDMS 파일에 직접 로깅하고 테스트 보고서에서 파일에 링크하는 것이 좋습니다.  그러면 TestStand에 전달할 필요 없이 보고서의 데이터를 참조할 수 있습니다.  이 접근 방식에 대한 자세한 내용은 보고서에 하이퍼 링크 포함 - TDMS 파일을 참조하십시오.

단계가 테스트 단계에서 사용 가능한 평가 타입을 사용하여 테스트 결과를 판별할 수 없는 경우, 필요한 테스트 타입을 처리하기 위한 추가 기능이 있는 새 단계 타입을 생성하는 것이 좋습니다.  사용자 정의 단계 타입 생성에 대한 자세한 내용은 이 시리즈의 사용자 정의 단계 타입 개발 우수 사례 문서를 참조하십시오.

테스트 자극 정의

많은 테스트의 경우 테스트를 수행하려면 UUT 또는 테스트 환경이 특정 상태에 있어야 합니다.  예를 들어, 온도 측정을 위해 여기 전압이 필요할 수도 있고 가열된 챔버를 지정된 온도로 설정해야 합니다.  이러한 타입의 모듈의 경우, 파라미터를 사용하여 여기 전압 또는 원하는 온도와 같은 입력 값을 전달합니다.  이는 이전 섹션에서 설명한 대로 코드에서 직접 리미트를 처리하는 것에 비해 테스트 코드 모듈에서 원시 데이터를 반환하는 것과 마찬가지로 많은 이점을 제공합니다.

테스트 결과 로깅

TestStand는 테스트 단계의 결과를 사용하여 보고서 생성 및 데이터베이스 로깅을 위한 기능을 내장하고 있습니다. 이러한 이유로 어떤 타입의 데이터 로깅도 코드 모듈에서 직접 구현하지 마십시오.  대신, 로그하려는 모든 데이터가 파라미터로 전달되도록 하고 TestStand를 사용하여 데이터를 로그합니다.  테스트 결과, 리미트 및 에러 정보와 같은 일부 데이터는 자동으로 로그됩니다.  다른 데이터를 로그하려면 추가 결과 기능을 사용하여 보고서에 포함할 추가 파라미터를 지정할 수 있습니다.

테스트 보고서에 결과를 추가하는 방법에 대한 자세한 내용은 TestStand에 포함된 보고서에 사용자 정의 데이터 추가 예제를 참조하십시오.

로깅에 대한 특정 요구 사항이 있는 경우 결과 처리 플러그인을 수정 또는 생성하는 것이 좋습니다. 그러면 내장된 TestStand 결과 수집을 사용하여 결과를 수집하고 결과 처리 및 표시 방법을 결정할 수 있습니다. 자세한 내용은 TestStand 프로세스 모델 개발 및 사용자 정의 우수 사례 문서의 플러그인 생성 섹션을 참조하십시오.

작업 루핑

각 방법에는 고유한 장점과 단점이 있으므로 루핑 구현에 가장 적합한 방법을 결정하기가 어려울 수 있습니다. 다음 지침을 사용하여 어플리케이션에 가장 적합한 전략을 결정하십시오.

코드 모듈 내부에서 루핑

• 특히 빠르게 루핑하는 경우 성능이 향상됩니다.  각 코드 모듈 호출은 수 밀리초의 오버헤드를 유발할 수 있으므로 외부 루프를 사용하여 수백 또는 수천 회 반복하면 테스트 속도에 영향을 줄 수 있습니다.
• 더 복잡한 루핑 동작이 가능합니다.  

시퀀스 파일 외부에서 루핑

• 코드 모듈을 수정하지 않고 시퀀스 파일에서 직접 루프 설정을 보고 수정합니다.
• 시퀀스 파일에서 루프 인덱스에 쉽게 액세스할 수 있습니다.  이는 현재 반복에 따라 변경되는 스위치 경로 또는 기타 동작을 판별하는 데 유용합니다.
• 루프의 각 반복은 별도로 로그되어 보고서 또는 데이터베이스에서 각 반복에 대한 결과를 보여줍니다.

스위칭 작업 수행

많은 테스트 시스템은 단일 하드웨어에서 여러 사이트를 테스트할 수 있도록 스위칭을 사용합니다.  스위치를 사용하면 미리 정의된 경로를 통해 테스트 대상 유닛(UUT)의 어느 핀을 특정 하드웨어에 연결할지 프로그래밍 방식으로 제어할 수 있습니다.  

다음과 같은 방법으로 TestStand 코드 모듈에서 스위칭을 구현할 수 있습니다.

• 단계의 내장 스위칭 프로퍼티 사용(NI Switch Executive 필요)
• TestStand IVI 스위치 단계 사용(32비트 TestStand만 해당)
• 코드 모듈에서 직접 스위치 드라이버 기능 호출

NI Switch 하드웨어를 사용할 때 NI Switch Executive를 사용하여 신속하게 경로를 정의할 수 있습니다. NI Switch Executive에 대한 액세스 권한이 있는 경우, 스위칭을 위해 내장 단계 설정을 사용하는 것이 일반적으로 가장 좋은 방법이며 다음과 같은 이점이 있습니다.

• 단계에서 스위치 구성을 정의하면 스위칭 기능이 테스트 코드와 분리되므로 재사용성이 향상되고 코드 모듈의 복잡성이 감소합니다.
• 스위칭 설정의 많은 필드는 식으로 지정되며 RunState.LoopIndex 프로퍼티 또는 다른 변수를 사용하여 반복하는 단계에 대한 경로 또는 경로 그룹 이름을 인덱싱할 수 있습니다.
• 병렬 테스트의 경우 테스트 소켓 인덱스(RunState.TestSockets.MyIndex)를 라우팅 문자열의 일부로 사용하여 각 테스트 소켓마다 다른 스위치 경로를 사용할 수 있습니다.
• 연결 수명을 단계, 시퀀스, 스레드 또는 실행에 연결할 수 있습니다.

NI Switch Executive를 사용하여 현재 루프 인덱스 또는 다른 프로퍼티를 사용하여 경로를 동적으로 결정하기 위한 TestStand 식 지원을 포함해 TestStand 단계 설정에서 직접 경로를 지정합니다.

계산 수행 및 데이터 조작

간단한 태스크에 대한 코드 모듈을 유지하지 않으려면 TestStand에서 식 언어를 사용하여 기본 계산 및 단차원 배열 조작을 수행할 수 있습니다. 프로그래밍 언어는 이러한 태스크에 더 적합한 보다 강력한 기능을 제공하므로 코드 모듈에 보다 고급 프로그래밍 요구 사항을 구현해야 합니다.  예를 들어, 다차원 배열을 연결하는 경우 식 언어를 통하는 것보다 원시 LabVIEW 빌드 배열 함수를 사용하는 것이 훨씬 쉽습니다.

경우에 따라 .NET 프레임워크와 함께 제공된 기본 클래스를 사용하면 지나치게 복잡한 식을 작성하지 않아도 됩니다.  예를 들어, System.IO.Path 클래스를 사용하여 코드 모듈을 생성하지 않고 경로 조작을 빠르게 수행할 수 있습니다.

.NET 단계를 사용하여 코드 모듈 없이 .NET 프레임워크 메서드를 활용할 수 있습니다.

코드 모듈을 구현할 때 생성하는 코드 모듈에 영향을 주는 디자인 결정 사항이 여러 가지 있습니다.  이 섹션에서는 다음 개념에 대한 지침을 제공합니다.

• TestStand에서 코드 모듈로 데이터 통신
• 코드 모듈 내에서 시퀀스 종료 처리
• TestStand에 코드 모듈 에러 보고
• 코드 모듈 실행 속도 및 메모리 사용 관리

TestStand에서 코드 모듈로 데이터 통신

코드 모듈 내에서 TestStand 데이터에 액세스하는 데 사용할 수 있는 방법은 두 가지가 있습니다.

• 코드 모듈 파라미터를 통해 데이터 전달
• TestStand API를 사용하여 코드 모듈 내에서 직접 데이터에 액세스

대부분의 경우 다음과 같은 이유로 TestStand API가 아니라 파라미터를 사용하여 데이터에 직접 액세스하는 것이 좋습니다.

• 에러 발생 가능성 감소 - 파라미터 값이 코드 모듈이 아닌 TestStand의 단계 타입 설정에서 정의되므로 프로퍼티 이름 또는 데이터 타입의 에러를 쉽게 찾을 수 있습니다.
• 유지보수성 향상 -단계 프로퍼티 변경이 코드 모듈을 수정하지 않고 TestStand의 파라미터 구성에 지정됩니다.
• TestStand 외부에서 재사용하기 쉬움 - 코드 모듈이 TestStand API에 의존하지 않으므로 모듈을 수정하지 않고 TestStand 외부에서 사용할 수 있습니다.

가능하면 파라미터를 사용하여 필요한 데이터를 코드 모듈로 전달합니다.

그러나 코드 모듈이 단계 상태에 따라 다양한 데이터에 동적으로 액세스하는 경우에는 API를 사용하여 프로퍼티에 직접 액세스하는 것이 유용할 수 있습니다.  이러한 경우에 단계 파라미터를 사용하면 실제로는 다양한 조건에서 일부만 사용되는 긴 파라미터 목록이 생성될 수 있습니다.

코드 모듈에서 TestStand API를 사용하는 경우 SequenceContext 객체(ThisContext)에 대한 참조를 파라미터로 전달합니다. SequenceContext 객체는 TestStand 엔진 및 현재 Runstate를 포함한 다른 모든 TestStand 객체에 대한 액세스를 제공합니다. 종료 모니터 또는 모달 대화 상자 VI를 사용하는 경우에도 시퀀스 컨텍스트 참조가 필요합니다.

SequenceContext를 사용하여 코드 모듈의 TestStand API에 액세스합니다. 그러면 프로그래밍 방식으로 데이터에 액세스할 수 있습니다.

TestStand 외부에서 코드 모듈을 재사용하는 경우, TestStand API를 사용하는 모든 작업은 모듈이 TestStand 시퀀스에서 호출된 경우에만 사용 가능합니다. 모듈이 API를 통해 TestStand에서 얻은 데이터는 사용할 수 없습니다.  먼저 Sequence Context 참조가 널인지 확인하여 코드 모듈이 TestStand 외부에서 호출되는 경우 테스트 데이터를 얻기 위한 대체 메커니즘을 정의할 수 있습니다.  LabVIEW에서 그림 3과 같이 부울 값을 반환하는 Not A Number/Path/Refnum? 함수를 사용할 수 있습니다.

Not a Number/Path/Refnum?을 사용하여 TestStand 외부에서 사용되는 코드 모듈에 대해 SequenceContext 객체 참조의 유효성을 확인합니다.

코드 모듈에서 대규모 데이터 세트 처리

대부분의 경우 코드 모듈은 측정 또는 분석에서 복잡한 데이터를 대량으로 생성할 수 있습니다.  TestStand는 데이터를 저장할 때 데이터 복사본을 생성하므로 이러한 타입의 데이터를 TestStand 변수에 저장하지 마십시오.  이러한 복사본은 런타임 성능을 저하시키거나 메모리 부족 에러를 일으킬 수 있습니다.  불필요한 복사본을 만들지 않고 대규모 데이터 세트를 관리하려면 다음 방법을 사용하십시오.

• 데이터를 획득한 동일한 코드 모듈에서 데이터를 분석하는 등 코드 모듈 내부에서 대규모 데이터 세트에 대해 연산하고 필요한 결과만 TestStand에 반환합니다.
• TestStand와 코드 모듈 간에 데이터 포인터를 전달합니다.  LabVIEW 코드 모듈의 경우, 데이터 값 참조(DVR)를 사용합니다.

코드 모듈 내에서 시퀀스 종료 처리

사용자가 종료 버튼을 누르면 TestStand는 실행 시퀀스를 중지하고 정리 단계를 실행합니다. 그러나 실행이 코드 모듈을 호출한 경우, 모듈이 실행을 완료하고 제어를 다시 TestStand로 반환해야 시퀀스가 종료할 수 있습니다. 코드 모듈의 런타임이 몇 초보다 길거나 모듈이 사용자 입력과 같은 조건이 발생할 때까지 대기하는 경우 사용자에게 종료 명령이 무시된 것으로 보일 수 있습니다.

이 문제를 해결하기 위해 종료 모니터를 사용하여 코드 모듈이 호출 실행의 종료 상태를 확인하고 응답하게 할 수 있습니다. 예를 들어, 컴퓨터 마더 보드 테스트 예제는 아래와 같이 시뮬레이션 대화 상자에서 종료 모니터를 사용합니다.  테스트 시퀀스가 종료되면 종료 상태 확인 VI가 거짓을 반환하고 루프가 중지됩니다.

종료 모니터 사용에 대한 자세한 내용은 종료 모니터 예제를 참조하십시오.

에러 핸들링

테스트 시스템의 에러는 테스트 진행을 방해하는 예기치 않은 런타임 동작입니다. 코드 모듈에서 에러가 발생하면 해당 정보를 테스트 시퀀스로 다시 전달하여 실행 종료, 마지막 테스트 반복, 테스트 수행자에게 메시지 표시와 같이 다음에 수행할 작업을 결정하십시오.

코드 모듈의 에러 정보를 TestStand에 제공하려면 아래 표시된 대로 단계의 Result.Error 컨테이너를 사용합니다.  TestStand는 자동으로 각 단계 후에 이 프로퍼티를 확인하여 에러가 발생했는지 확인합니다.  TestStand의 에러 정보를 코드 모듈로 전달할 필요는 없습니다. 코드 모듈이 TestStand에 에러를 반환하면 실행이 정리 단계 그룹과 같은 테스트 시퀀스의 다른 부분으로 분기될 수 있습니다.

스테이션 옵션의 실행 탭에 있는 런타임 에러 발생 시 설정을 사용하여 TestStand가 단계 에러에 응답하는 방법을 결정할 수 있습니다.  일반적으로 디버깅을 지원하기 위해 시퀀스를 개발하는 동안 대화 상자 표시 옵션을 사용해야 합니다. 이 옵션을 사용하면 실행을 중단하고 시퀀스의 현재 상태를 확인할 수 있습니다.  배포된 시스템의 경우 테스트 수행자의 입력을 요구하는 대신 정리 실행 또는 무시 옵션을 사용하는 것이 좋습니다.  에러 정보는 자동으로 테스트 결과에 로그되며 에러의 원인을 찾는 데 사용할 수 있습니다.
 

단계 에러가 발생하면 에러 정보를 Step.Result.Error 컨테이너에 전달하여 TestStand에 알립니다.

코드 모듈의 성능 및 메모리 사용 관리

기본적으로 TestStand는 파일에서 시퀀스를 실행할 때 시퀀스 파일의 모든 코드 모듈을 메모리로 로드하고 시퀀스 파일을 닫을 때까지 로드된 상태로 유지합니다.  이러한 설정을 사용하면 시퀀스를 시작할 때 모듈을 로드하는 동안 초기 지연이 발생할 수 있습니다.  그러나 모듈이 메모리에 유지되기 때문에 시퀀스 파일의 후속 실행이 더 빠릅니다.

단계 설정 창의 실행 옵션 탭에서 코드 모듈을 로드 및 언로드 할 시기를 구성할 수 있습니다. 일반적으로 기본 로드 옵션이 최상의 성능을 제공하지만 경우에 따라 동적으로 로드 로드 옵션을 함께 사용하는 경우에만 코드 모듈을 로드하는 것이 좋습니다.  특정 테스트가 실패한 후에만 실행되는 진단과 같이 일반적인 실행에서 호출되지 않는 코드 모듈의 경우 동적으로 로드해야 합니다. 이러한 모듈은 대부분의 경우 전혀 로드할 필요가 없기 때문입니다.

코드 모듈을 동적으로 로드할 때 TestStand는 코드 모듈을 로드할 때까지 코드 모듈에 대한 문제를 보고하지 않습니다. 그때가 긴 실행의 끝에 가까울 수도 있습니다. 그러나 시퀀스 분석기를 사용하여 실행 전에 시퀀스에 에러가 없는지 확인할 수 있습니다.  분석기는 정적 및 동적으로 로드된 코드 모듈을 모두 확인합니다.

메모리가 많이 필요한 코드 모듈의 경우 기본 언로드 옵션을 수정하여 총 메모리 사용량을 줄일 수 있습니다.  예를 들어, 모듈을 단계 실행 후 언로드 또는 시퀀스 실행 후 언로드로 설정합니다.  그러나 TestStand는 각 후속 호출에 대해 모듈을 다시 로드해야 하므로 이 변경으로 실행 시간이 늘어납니다. 가능한 경우 더 나은 대안은 64비트 버전의 TestStand와 더 많은 물리적 메모리가 탑재된 시스템을 사용하여 높은 메모리 사용 요구 사항에도 불구하고 가장 빠른 테스트 성능을 얻는 것입니다.

코드 모듈이 정적 변수 또는 LabVIEW 기능적인 글로벌 변수와 같은 공유 데이터를 유지하는 경우, 언로드 옵션을 수정하면 모듈이 언로드될 때 글로벌 데이터가 손실되므로 동작이 변경될 수 있습니다. 언로드 옵션을 변경할 때 모든 필요한 데이터가 TestStand 시퀀스로 전달되거나 보다 영구적인 위치에 저장되도록 하여 데이터 손실을 방지해야 합니다.

테스트 시스템 성능을 최적화하는 다른 방법에 대한 자세한 내용은 NI TestStand 시스템 성능 향상을 위한 우수 사례를 참조하십시오.

코드 모듈의 일반적인 용도는 테스트 하드웨어와 인터페이스하여 자극을 설정하고 테스트 측정을 수행하는 것입니다.  하드웨어와 통신하는 방법은 다음과 같습니다.

• NI-DAQmx와 같은 하드웨어 드라이버를 사용하여 하드웨어와 직접 통신.
• VISA 또는 IVI 하드웨어 드라이버를 통해 내부적으로 인스트루먼트로 명령을 보내는 인스트루먼트 드라이버를 사용.
사용하는 통신 방법은 사용중인 하드웨어 타입에 따라 달라집니다.  두 통신 타입 모두 드라이버 관련 호출을 하기 전에 드라이버에 대한 참조 또는 세션을 열고 상호 작용이 완료된 후 핸들을 닫습니다.

하드웨어 참조 관리를 위한 접근 방식 선택

대부분의 경우 여러 테스트 단계에서 동일한 하드웨어와 통신합니다. 각 코드 모듈에서 인스트루먼트 세션을 열고 닫을 때의 성능 영향을 피하려면 테스트 시퀀스 내에서 하드웨어 참조를 관리하는 방법을 고려해야 합니다.  하드웨어 참조 관리에는 두 가지 일반적인 접근 방식이 있습니다.

• 코드 모듈에서 초기화 및 닫기 함수를 호출하여 수동으로 하드웨어 참조를 관리.
• 세션 관리자를 사용하여 자동으로 하드웨어 참조 수명을 관리.

인스트루먼트 드라이버를 사용하는 경우 또는 VISA 또는 IVI 드라이버를 사용하여 인스트루먼트와 직접 통신하는 경우, 하드웨어 세션 수명을 직접 제어할 필요가 없는 한 세션 관리자를 사용하십시오.  DAQmx와 같은 하드웨어 드라이버를 사용하는 경우 세션 관리자를 사용할 수 없으며 수동으로 참조를 관리해야 합니다.

TestStand 변수를 사용하여 수동으로 하드웨어 참조 관리

인스트루먼트를 초기화할 때 세션 참조를 출력 파라미터로 호출 시퀀스에 전달한 다음 참조를 변수에 저장합니다.  그런 다음 인스트루먼트에 액세스해야 하는 각 단계에 변수를 입력으로 전달할 수 있습니다.

NI-DAQmx, VISA 및 대부분의 인스트루먼트 드라이버 등 많은 드라이버는 I/O Reference 데이터 타입을 사용하여 세션 참조를 저장합니다. 이러한 참조를 저장하려면 TestStand의 LabviewIOControl 데이터 타입을 사용하십시오.  

LabVIEWIOControl 타입의 변수를 사용하여 코드 모듈 간에 DAQ 태스크 참조와 같은 하드웨어 참조를 전달합니다.

TestStand와 코드 모듈 간에 인스트루먼트 핸들을 명시적으로 전달할 때 로컬 변수에 하드웨어 참조를 저장합니다.  하드웨어가 여러 시퀀스에서 사용되는 경우 핸들이 필요한 각 시퀀스에 핸들을 시퀀스 파라미터로 전달합니다.  참조를 사용하기 전에 인스트루먼트가 초기화되었는지 확인하기 어려울 수 있으므로 글로벌 변수를 사용하여 하드웨어 참조를 저장하지 마십시오.

다음과 같은 이유로 설정 단계 그룹을 사용하여 하드웨어를 초기화하고 정리 단계 그룹을 사용하여 하드웨어 참조를 닫으십시오.

• 정리 단계 그룹은 실행이 종료될 때 항상 실행되므로 사용자가 시퀀스 실행을 종료하면 하드웨어 참조는 여전히 닫힙니다.
• 설정 및 정리 단계 그룹이 선택한 단계 전후에 실행되므로 하드웨어 참조를 사용하는 단계를 대화식으로 실행할 수 있습니다.

설정 및 정리 그룹을 사용하여 하드웨어 참조를 초기화하고 닫습니다.

세션 관리자를 사용하여 자동으로 하드웨어 참조 관리

VISA 및 IVI 인스트루먼트 핸들의 경우 세션 관리자를 사용하여 자동으로 하드웨어 참조를 관리할 수 있습니다. 세션 관리자를 사용하면 다음과 같이 많은 이점이 있습니다.

• 커플링 감소 - 소프트웨어 구성 요소 간에 인스트루먼트 핸들 변수를 전달할 필요가 없습니다. 대신, 각 구성 요소는 세션을 얻기 위해 논리적 인스트루먼트 이름을 지정합니다.
• 프로그래밍 언어 장벽 감소 - 다른 언어로 작성된 코드 모듈이 언어 간에 쉽게 변환할 수없는 핸들을 전달하지 않고도 동일한 세션을 공유할 수 있습니다.
• 수명 관리 - 인스트루먼트 세션은 참조 횟수가 있는 ActiveX 객체이므로 세션의 수명을 ActiveX 참조 변수의 수명에 연결할 수 있습니다. 그러면 ActiveX 참조 변수를 지원하는 언어에서 인스트루먼트를 명시적으로 닫을 필요가 없습니다.

세션 관리자는 세션이 생성된 후 핸들을 자동으로 초기화하고 세션에 대한 마지막 참조가 해제되면 핸들을 자동으로 닫습니다. 코드 모듈과 시퀀스는“DMM1”과 같은 논리적 이름을 전달하여 세션 관리자에서 해당 인스트루먼트 핸들이 포함된 세션 객체를 얻습니다.

세션 관리자를 사용할 때 세션 객체를 TestStand 객체 참조 변수에 저장하십시오.  세션 수명은 객체 참조 변수의 수명과 연결되므로, 동일한 세션에 액세스하는 시퀀스 코드 모듈 및 하위 시퀀스의 수에 관계없이 인스트루먼트 핸들은 실행당 한 번 초기화되고 닫힙니다.

아래 예제에서 Get DMM Session(DMM 세션 가져오기) 단계는 논리적 이름을 위한 DMM의 인스트루먼트 세션 개체에 대한 참조를 얻습니다. 이 단계는 시퀀스 실행이 지속되는 동안 세션이 초기화된 상태로 유지되도록 세션 참조를 로컬 변수에 저장합니다.

논리 이름을 사용하여 인스트루먼트를 참조할 수 있도록 세션 관리자를 사용합니다.  세션 관리자 VI는 논리적 이름을 사용하여 DMM-IO 참조를 얻습니다.

세션 관리자 사용 방법에 대한 자세한 내용은 <Program Files>\National Instruments\Shared\Session Manager에 있는 NI 세션 관리자 도움말을 참조하십시오.

이전 예제 시퀀스는 세션 관리자를 직접 호출하는 대신 세션 관리자를 호출하는 LabVIEW 코드 모듈에서 세션을 얻습니다. 이 예제는 LabVIEW 어댑터가 별도의 프로세스에서 VI를 실행하도록 구성했기 때문입니다.  세션 관리자 사용 방법에 대한 자세한 내용은 <Program Files>\National Instruments\Shared\Session Manager에 있는 NI 세션 관리자 도움말을 참조하십시오.

하드웨어 드라이버 라이브러리 호출

모든 타입의 하드웨어와 통신하려면 드라이버 라이브러리를 사용합니다. 이러한 라이브러리는 프로그래밍 언어를 사용하여 일련의 태스크를 수행할 수 있도록 설계된 기능 세트를 제공합니다.  드라이버 라이브러리를 사용할 때, 여러 VI 또는 함수를 호출하여 단일 논리 연산(예: 측정 또는 트리거 구성)을 수행하는 경우가 자주 있습니다.  TestStand 단계에서 직접 라이브러리 함수를 호출하는 대신 코드 모듈을 생성하여 이 기능을 구현하면 몇 가지 이점이 있습니다.

• 각 함수 주위에서 단계 기능의 오버헤드를 방지
• 드라이버 호출과 TestStand 시퀀스 간 추상화 계층을 제공
• 보다 쉽게 테스트 프로그램 간에 구현을 공유

고급 NI TestStand 개발자에게 유용한 토픽을 다루는 TestStand 고급 아키텍처 시리즈의 추가 문서를 보려면 클릭하십시오.