VisualApplets
Operator Reference

Operator Library: Hardware Platform

该算子代表 CXP 双抽头（tap）相机与 VisualApplets 之间的图像数据接口。您可以将该算子用于单通道、双通道或四通道 CXP 接口。您可以通过参数 ConnectionCount 选择接口类型。无论相机输出哪种格式，该算子都会为每个 tap 端口输出原始图像数据。然后，您需要将这些图像数据转换为相机发送的格式。若要转换图像数据，请使用适当的算子来进行聚合，并将原始字节值转换（cast）为像素值。运行过程中的某些特定情况可能会通过事件系统进行通报，如下所述。此外，该算子还具有多个用于指示与相机连接状态的参数。

CXP 标准多抽头（Multi-Tap）定义

通常，图像像素是从左上角到右下角按顺序扫描的。然而，随着现代图像传感器上的像素数量稳步增长，这种方法已无法产生可接受的帧率。为了解决这个问题，传感器制造商通过同时扫描多个像素来应对。CXP 标准通过引入 抽头（tap） 的概念来适应这种技术。抽头可以看作是一个按顺序读取图像像素的扫描设备。图像的扫描方式定义为 Tap Geometry，由主机从设备中读取。

CXP 标准建议帧抓取器主机支持三种 tap 格式：1X-1Y、1X-1Y2 和 1X-2YE。tap 格式 1X-1Y 代表从左上角到右下角逐像素扫描的默认特征，而其他格式则代表下图所示的两种 tap 几何结构：

尽管来自每个 tap 的数据被组合成单独的数据流，但需要注意的是，流 ID 与 tap 之间没有固定的映射关系。不过，可以放心地假设此映射在采集过程中保持不变。 TapG 代码，从而获取查找此映射所需的信息，该信息包含在 CXP 图像标头中，可在可选的 MetaDataTap0/1 端口上读取。

在 VisualApplets 中实例化

该 operator 在其输出抽头上提供图像数据。此输出始终存在。单抽头相机的此值为 1，双抽头相机则需设置为 2。除了这些标准输出端口之外，您还可以为每个抽头输出专门配置一个可选的 MetaData 输出（用于 CXP 标头元数据），即对于双抽头应用，您最多可以定义 2 个 MetaDataTap 端口。在 operator 实例化期间将显示以下弹出对话框，并且可以配置为以下排列组合：

可选的 MetaDataTap 端口

两个元数据端口的格式完全相同。 它在 VisualApplets 中作为 32 位输出提供，如以下图片所示：

每个 CXP 帧都提供相应的无错误图像标头。对于不正确的图像标头，不会将任何图像流数据源入 VisualApplets 管道。压缩的图像标头由 6 个字组成。最后一个字节用于附加信息，仅供内部使用。特别是，HeaderError 位用于通知图像标头本身是否存在错误。

设备资源占用

根据参数 ConnectionCount 的选择，该运算符使用一个或多个类型为 CameraPort 的资源。对于事件 system，将使用类型为 EventPort 的资源。如果将 ConnectionCount 设置为 X4（四通道），将打开以下资源对话框：

错误处理与事件系统

当运算符检测到接收到的重建帧大于或小于相机在 CXP 图像标头中通告的大小时，将激活安全电路。然后，运算符会截断超出部分的像素和行，以便后续的处理流水线始终看到图像标头中定义的帧大小。如果接收到的帧尺寸小于图像标头中指定的大小，运算符将用未定义的数据填充接收到的帧，以达到图像标头中指定的帧尺寸。填充较小的帧可能会导致后续帧丢失。随后会将丢失情况通过事件报告给运行时软件（Framegrabber SDK）（参见下一段）。尺寸不匹配也会引发事件。

For a set of very critical errors, the operator will forward asynchronous events to the host runtime software (Framegrabber SDK). The event name in the Framegrabber API is <hierarchical operator name>\CxpStreamStatus, e.g. Device1\Process0\Camera\CxpStreamStatus. The event payload is provided as four 16-bit data words. The event format is defined as follows:

事件分为两种类型：损坏实体的事件和丢失实体的事件。word 3 的 bit 0 描述了发生了哪种类型的事件。如果事件缓冲区已满，可能会导致事件丢失。当标记损坏实体的事件丢失时，word 3 的 bit 1 将被置位。当标记丢失实体的事件丢失时，word 3 的 bit 2 将被置位，且 bit 3 到 15 将提供指示丢失帧的丢失事件数量。如果 bit 2 已置位但 Counter 为 0，则意味着发生了 Counter 溢出。

每个事件都会引发一个软件中断。为了 减少事件数量，可能会将具有相同帧标记（frame tag）的多个事件合并在一起。在这种情况下，某些错误标志会被组合。如果某个事件丢失，则丢失事件之前的事件将包含有关丢失事件的信息，并且不能与具有相同帧标记的后续事件合并。

由 CRC 错误引起的事件会报告一个帧标记（frame tag），该标记可能不完全对应于发生 CRC 错误的帧。帧标记可能是前一帧或后一帧的帧标记。这种情况只会在相机发送包含 2 个或更多帧之间过渡的 CXP 数据包时发生。CRC 计算在数据包结束时完成，但流数据是即时重建的。这意味着可能会出现这种情况：仅在操作员发送前一帧之后才检测到 CRC 错误。在正常情况下，如果相机数据包不包含正在进行的帧末尾和下一帧开头的数据，则 CRC 错误期间的帧标记将始终正确。对于所有其他情况，只要完整的帧流数据小于 8k 的最大数据包大小，一个数据包内可能仅存在 1 个帧重叠。在这种情况下，软件应用程序应将带有帧标记 -1 的前一帧和带有帧标记 +1 的后一帧也视为可能已损坏。