VisualApplets
사용자 매뉴얼

애플릿 프로세스는 해당 프로세스의 모든 DMA가 시작된 후에만 하드웨어에서 사용할 수 있습니다. 그러나 프로세스에 DMA 채널이 포함되어 있지 않은 경우, 애플릿 초기화 직후에 시작됩니다. 이는 이미지 획득이 시작되기 전에 사용되는 트리거 및 신호 처리 애플리케이션에 유용합니다.

하드웨어에서 VisualApplets 애플릿의 초기화 및 사용에 대해 자세히 알아보려면 'Running Your Applet on Hardware' 섹션 및/또는 Framegrabber SDK documentation을 참조하십시오.

프로세스 간 이미지 데이터는 교환할 수 없습니다. 그러나 TxSignalLinks 및 RxSignalLinks 연산자를 사용하면 신호에 대한 프로세스 간 통신을 설정할 수 있습니다.

애플릿 내 파이프라인의 대역폭은 연산자의 처리 속도와 연결된 링크에 따라 달라집니다. 링크에는 여러 "link properties"가 있습니다('Link Properties' 참조). 그중 하나가 대역폭을 정의하는 Parallelism입니다. Parallelism은 하나의 디자인 클록 주기에서 두 연산자 사이에 몇 개의 픽셀이 병렬로 전송되는지를 정의합니다. Parallelism이 높을수록 대역폭이 커집니다. 연산자는 링크의 필수 대역폭을 충족하도록 자동으로 조정되며, 이것이 불가능한 경우 대역폭을 재정의합니다. Parallelism에 대한 실용적인 지침은 Parallelism 튜토리얼 항목을 참조하십시오.

그림 34. 클록 주파수 125 MHz에 대한 Parallelism

간단한 예를 들어 보겠습니다. Parallelism이 4이면 4개의 픽셀이 병렬로 전송됩니다. 즉, 이미지의 처음 4개의 연속 픽셀이 카메라 모듈에서 후속 모듈(이 경우 버퍼)로 병렬 전송됩니다. 다음으로, 다음 4개의 픽셀이 카메라 모듈에서 버퍼 모듈로 전송됩니다. 그동안 처음 4개의 픽셀은 버퍼 모듈에서 처리되어 이미지 처리 체인의 다음 모듈로 전달됩니다.

앞서 언급한 바와 같이 Parallelism은 디자인 클록 주파수의 한 클록 주기에서 병렬로 전송되는 픽셀 수를 정의합니다. 주파수는 사용되는 하드웨어 장치에 따라 다릅니다. 예를 들어, microEnable IV 시리즈의 프레임 그래버는 62.5MHz의 디자인 클록 주파수를 사용합니다.

	대역폭 계산
	링크의 대역폭 b는 Parallelism p와 주파수 f의 곱으로 결정됩니다.

따라서 Parallelism이 4이면 대역폭은 다음과 같습니다. . 픽셀당 8 bit의 bit width를 가정하면 이는 250MB/s의 대역폭을 초래합니다. 모든 하드웨어 플랫폼의 기본 디자인 클럭 주파수 목록은 다음에서 확인할 수 있습니다. 디바이스 리소스.

오퍼레이터는 입력 링크와 출력 링크 간의 Parallelism을 변경할 수 있습니다. 따라서 디자인 전반에 걸쳐 대역폭이 일정하지 않습니다. 이는 필요한 대역폭이 변경될 수 있기 때문입니다. 예를 들어 오퍼레이터가 이미지 크기를 줄이면 필요한 출력 대역폭도 감소합니다.

위 공식으로 계산된 대역폭은 이론적인 값입니다. 실제 대역폭은 이론적 값보다 약간 낮습니다.

	중요
	일부 오퍼레이터는 입력 링크에서 제공되는 전체 대역폭을 처리할 수 없습니다. 관련 오퍼레이터에 대한 자세한 내용은 Operator Reference에서 확인할 수 있습니다.

대역폭과 지연 시간(latency)의 차이에 유의하십시오. 지연 시간은 각 오퍼레이터에 의해 개별적으로 정의되며 주로 알고리즘 구현 방식에 따라 달라집니다.

	GUI에서의 시각화
	해당 링크 Property를 시각화하기 위해 VisualApplets은 프로그램 창의 툴바에 두 개의 GUI 버튼을 제공합니다: Display Link Info 다이어그램의 모든 링크에 대한 bit width와 Parallelism을 표시합니다: Display Link Throughput 다이어그램의 모든 링크에 대한 초당 메가픽셀 단위의 최대 픽셀 처리량을 표시합니다:

앞서 설명한 바와 같이 VisualApplets에서는 픽셀이 파이프라인을 통해 차례대로 전송됩니다. 링크 Parallelism이 1보다 크면 여러 픽셀이 병렬로 전송됩니다. 이미지나 라인 내 픽셀의 전송 순서는 다음과 같습니다. 일반적으로 카메라에서 프레임(2차원 이미지)의 픽셀은 왼쪽 상단 모서리의 첫 번째 픽셀에서 시작하여 오른쪽 하단 모서리의 마지막 픽셀에서 끝나는 방식으로 전송됩니다. VisualApplets 오퍼레이터가 처리를 위해 픽셀 위치를 필요로 하는 경우 왼쪽 -> 오른쪽, 위 -> 아래와 같은 동일한 순서가 예상됩니다. 다음 그림은 이 순서를 보여줍니다.

그림 35. 픽셀 순서

그러나 카메라와 같은 일부 소스는 이 순서를 따르지 않습니다. 이러한 경우 VisualApplets 오퍼레이터와 디자인을 사용하여 픽셀 순서를 수정할 수 있습니다. 이를 수행하려면 픽셀 전송 프로토콜에 대한 약간의 지식이 있어야 합니다. 관련 정보는 'Image Protocols, Image Dimensions and Data Structure' 섹션에서 확인할 수 있습니다.

Image Protocol은 전송된 픽셀 및 데이터의 이미지 치수와 데이터 구조를 정의합니다. Image Protocol은 앞서 언급한 링크 Property인 Parallelism 외에 또 다른 링크 Property입니다.

이미지 프로토콜에는 세 가지 유형이 있습니다.

Image protocol은 link property입니다. 각 operator는 입력에서 허용되고 출력에서 사용할 수 있는 link property를 개별적으로 결정합니다. 링크 매개변수화에 대한 자세한 내용은 'Link Properties'를 참조하십시오.

이 이전 섹션에서는 VisualApplets 디자인의 파이프라인 구조에 대해 설명했습니다. 앞서 언급했듯이 데이터는 링크를 통해 프로젝트의 모듈 간에 전송됩니다. 모듈이 입력 픽셀을 처리하고 출력 값 계산을 완료하면, 그 결과가 출력 링크로 출력됩니다. 하지만 다음 모듈이 여전히 다른 픽셀을 처리 중이어서 데이터를 처리하지 못할 수도 있습니다. 이 경우 VisualApplets의 흐름 제어가 적용되고 파이프라인이 차단됩니다. 따라서 모듈은 입력을 차단할 수 있습니다. 이 경우 이전 모듈은 결과를 출력하지 않고 파이프라인에서 차단 상태를 역방향으로 전파합니다.

그림 33, 'Simple VisualApplets Design'에 표시된 간단한 예를 살펴보겠습니다. 카메라가 생성하는 대역폭을 처리할 수 없는 느린 PC가 사용된다고 가정해 보겠습니다. 이 경우 DmaToPC 모듈은 데이터를 호스트 PC로 전송할 수 없습니다. 따라서 수시로 입력을 차단하게 됩니다. 차단 신호는 디자인 내에서 이미지 버퍼 모듈까지 전파됩니다. 이제 이미지 버퍼 모듈은 차단이 활성화되어 있는 동안 데이터를 출력하지 않습니다. ImageBuffer 모듈은 버퍼이므로 이후에 들어오는 모든 데이터가 버퍼링되며 버퍼의 Fill 수준이 증가합니다. 카메라가 데이터 전송을 중지하면 버퍼로 전송되는 새로운 입력 데이터가 없어지고 버퍼가 빌 때까지 데이터가 출력됩니다.

	팁
	다시 말해 흐름 제어는 수로의 파이프라인처럼 상상할 수 있습니다. 밸브가 닫히면 더 이상 물을 운반할 수 없습니다. 버퍼 operator는 배출구가 입력 스트림을 소모할 수 없을 때 물이 채워지는 저수지와 같습니다.

Stoppable and Non-Stoppable Data Streams 튜토리얼 항목도 참조하십시오.