GigE+Vision+2.0说明书.docx_GigEVision文档

GigE

需积分: 50 252 浏览量更新于2023-05-26 评论收藏 28KB DOCX 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

引言 

第  章设备发现 

链路选择 

 地址配置 

设备枚举 

设备添加与删除 

第  章  协议 

基本概念 

通道 

其他 

第  章引导寄存器 

引导寄存器 

相机的标准特征表 

引言

是一种通信接口标准，可用于各种网络拓扑上的视觉软件与视频流设备间的交互。该标准

是基于  协议体系，并构成了 协议（工作在应用层，包括  和  两个协议）。

需要的设备包括  网络上各种软硬件摄像机、处理器、路由器等。本说明中，设备指的是一个 

 兼容的可控设备，而应用程序指运行在一台主机上的一个与  兼容的控制程序。

本说明分三部分，即设备发现、 协议和引导寄存器，分别在对应的章节中介绍。

第  章设备发现

 在接入设备时，需要一种机制发现设备，即链路选择、 地址配置、设备枚举。

链路选择

设备在接入  后，需要确定所有通信链路哪些是可用的，然后与  端协调选择相应速率的链路。共

提供了  种不同类型的物理链路配置：

单链路配置 

多链路配置 

静态链路聚合组配置 

动态链路聚合组配置 

其中，头  个配置中，每个物理链路接口都有  个不同的  地址；对于后  个配置，物理接口经过重

组后，只有  个  地址在程序中可见，物理链路的分组在  层执行，对于应用软件是透明的。

单链路配置

最简单的配置，所有的流通道加到一个有效物理链路上，所有设备必须支持  配置。

多链路配置

一个设备必须最多支持  个不同的网络接口。接口 !（唯一支持 ）为主接口来控制设备的控制与

消息通道，如设备发现总是在 ! 上执行，以确保设备使用不同的  地址而不被多次发现。其他接口只

支持附加的流通道，如发送或接收  数据包。只能在 ! 中使用 "#$ 消息，其他接口必须使用

静态 、% 或  来获取其  配置信息。

可以认为  配置中的一个链接就是一个 。若支持多链路配置，必须在 & 寄存器中指定流通道

使用的具体接口，其 '()*+'),-.+& 字段在流通道与网络接口间提供了映射机制，如果映射

采用硬编码，则该字段只读。

允许将每个网络接口视为一个不同的  设备，则每个接口是独立的且具有合适的资源，这等

价于将多个设备组合成一个单元。

负载平衡：网际协议  会设计好一个路由使数据包到达接收端的正确接口上。在  中，为达到负载

平衡，可分别将多个流通道一一关联到不同的链路，以平衡这些链路所需的整体网络带宽。

链路聚合组配置 

/!0 标准规范了  的相关特性。该标准下的电缆以太网交换机遵守  规范，这样可能不

会平衡负载  流输送到多个外向端口上，这些端口通常使用 '1)' 帧的头部信息（有时为  头）

来作为其分配算法的输入参数，这些交换机在  中是不可见的。由于  显示单个 ，这些

交换机不能指出怎样去分配  输送，可能在某交换机的一个外向端口上就停止输送了。

网络接口：只允许有一个聚合器，因此，所有与  关联的活动链接均绑定到该聚合器上。若支持链

路聚合配置，设备只允许静态和动态  两个配置中有一个聚合器，且其应该使用与  相关的具有

最小编号物理网路接口的  地址。故在引导寄存器中，只有一个“虚拟”网络接口可见。

 影响：一个  通道必须总是在  同一物理链路上被发送。

 影响：定义比较宽松，使用 )23)4 分配算法平衡网络负载。首个流数据包可以在该聚合器

的任意接口上传送，也可在新的数据块边界上重启一个 )23)4 新循环。

静态  和动态 ：两者唯一区别在于 /!0 的  协议的使用。静态

 用于增加流的有效带宽，假定这些链路的所有电缆走向同一目的地（如多端口 5）；但如果布

线不正确， 协议用来确保系统能正确绑定属于同一互连的物理链路，对于动态 ，其保证了一

个聚合器中所有链接都在同一伙伴间。

 事件：由于聚合组中的一个物理链路连接上或断开，而引起聚合速度改变时，设备应发送一个

+56+57++%5 事件。

 地址配置

该过程即分配一个  地址给设备。 设备支持 %、 和静态 （可选）三种方式分配

。该配置在设备启动或重启时执行。

协议选择

每个  配置协议的执行顺序必须是静态 （若支持并启用）、%（若启用）和 。出厂默认静

态  禁用，% 启用， 一直可用。

静态 

静态  相关的信息必须存储在设备的非易失内存中，如果没有该内存，则不能支持。如果设置的  与

同一网络上的设备  冲突，设备就不能使用该  地址并应告知用户，这时，设备必须使用下一个 

配置方案。$"8 文档使用 $ 协议来探测静态  地址，以检测是否有潜在的冲突。如果分配的 

地址不能识别，程序可修改引导寄存器的静态  信息，设置为一个有效的状态或简单禁用静态 。

%

一个 % 可用标志存储在非易失内存中，如果没有储存介质，设备必须决定 % 是否可用。设备

应支持 % 选项：子网掩码和路由选项。

% 重传策略：使用 %，设备发送一个 %#$ 消息，% 服务器返回一个 %#""$

消息；设备发送一个 %$96 消息，服务器返回一个 %7 或 %57 消息。若设备没有

从服务器接收到任何回应，需要重传上述消息，至多允许  次重传（因为最坏情况下设备分别发送 

个上述消息）。如果没有 % 服务器可用，设备在 % 阶段一般会等待 。

% 租借到期：设备停止使用  地址，并重启  配置循环。

链路本地地址 

即私有 。 地址范围从 :;!33:;。必须一直被激活。

设备枚举

在设备获得一个  后， 端程序需要收集网络上所有设备相关信息，如设备 、制造商、制造日期等。

通过单播或组播  命令方式分别得到已知或未知  的设备信息，并使用  协议实现信息交互。

 提供  种机制来枚举设备： 设备发现<强制性=和组播 55 服务发现<可选=。

 设备发现

非强制性（有利于最小化带宽使用）。如果设备没有完整的  配置，则不能回应任一程序发出的设备

发现请求消息，否则，在获得一个有效  地址后，必须回应。

广播设备发现： 广播消息，目的  地址 ，该消息不经过路由器。若程序在一台

多宿主机上，存在多个网卡，则可以使用一个子网定向广播。在回应报文中，设备必须设置源  地址、

子网掩码和默认网关信息，这些在  配置时已获得。

单播设备发现：仅当设备  地址被程序已知才使用该方式。可直接发送一个  数据包到该设备 

地址。设备对该类型消息必须返回一个单播回应报文给发送消息的程序。

将设备关联到枚举表：为方便将一个设备关联到设备发现列表的对于条目中，设备外壳

上应有一个序列号和  地址标签。

零配置发现

结合组播 5 和 5 服务发现。该机制将“主机”与“服务”这两个概念分开。一个服务有  个主要部分：

类型（ 固定）、名称（识别特殊实例）及服务运行的 6 端口。服务可以拥有一个包含特

殊实例详细信息的唯一 606 记录表。在  上下文中，每个服务实例对应一个  控制通道。

标准设备：通知具有一个服务的单台主机。

带链路聚合的标准设备：同上，多路连接可视为一个逻辑连接。

带多链路无连接聚合的标准设备：通知具有多个  地址及一个服务的单台主机，并映射到  配置。

要求程序决定连接哪一个链路，该实现已定义了。

单链路的多控制器设备：通知具有多个  服务的单台主机，每个服务被视为一个共享同一物理接

口的  配置。在同一以太网端口和  地址之后的所有独立的  栈共享同一  地址，因此，如果程

序改变了一台设备的 ，其他台上的  也会跟着变化。

多独立链路多控制器设备：每条链路通知一个对应不同的主机，每个主机通知单个服务。一般来说，

每条链路只响应与该链路相应的唯一主机服务名相匹配的查询，故在链路另一端的主机只能看到其连

接上的接口，且能够通过特定链路降低可获得的服务数量。这映射到一个  配置中，但每个服务有一

个不同的物理接口。

组播 5<>5=：查询类型如  记录（??: 名称解析），查询服务为 $ 记录。在组播

5')' 草案中，为 >5 分配的 ? 组播地址为 !!，?: 链路本地组播地址为

""!@"A，使用  端口 ，仅用 6"3/ 编码资源记录名，采用 5 顶级域名“B.-BC。设备主机名

由设备制造商名D设备名D设备  地址<大写十六进制=DEB.-BE构成。

5 服务发现：使用 5 来查找特定的服务名称。主要任务是列举服务名称列表，及将服务名翻译成

相关联的  地址。合法的服务名需为“+?.F+2FC。若支持 53，其 606 记录必须至少支持如下键：

规范版本号、设备模式、 地址、设备供应商名、模型名、具体制造商版本信息、具体制造商串名、

序列号、自定义名和实例号。

设备添加与删除

程序应能够动态响应设备网络拓扑结构变化（在网络上添加或删除一个设备）。

删除

现场删除主要由控制协议处理，然后程序暂停其发送的消息命令，或者一个控制与接收程序可暂停不

再到来的  发送端视频流。

添加

有三种方法：

程序发送 % 请求给服务器，后者做出响应并通知添加设备的程序，但要求客户端与服务器端联

系密切；

程序定时发送一个 #$G 命令，但这会消耗一定的网络带宽，尤其是每次有很多设备需要回

应，一种解决方案是提供给用户一个控件来刷新设备列表；

执行组播 5 或 5 服务发现来发现新设备。

除了网络带宽要分配给新设备外，原来的设备不受新添加设备的影响。

第  章  协议

 协议描述了程序与设备之间遵守的通信规范，重点介绍了三种类型的通道，即控制通道、消息通

道和流通道，并列举了各种事件命令。

基本概念

在  协议报文中，最大传输单元 6 定义为 8:4H'，包括  头、 头、 头以及数据负

载部分。

 控制头和数据段部分大小必须是  字节的倍数。

 是基于  无连接服务的，因此，设计了消息重传机制。消息重试次数可以由用户设定，默认

值为 。)I+J!，在控制通道关闭后，其值会被初始化。此外，还启用了端到端连接，通过设置心

跳计数来侦听链路是否断开。同理，其值是可以自定义的。一般来说，应用程序端的心跳频率应略低

于设备端的 ，这样可以在  包发送丢失时排除心跳因素的干扰。

 头包含了键值 !&，用于设备与应用程序识别  包。

设备的第一个  端口号必须为 ;:。

通道

通道即虚拟连接。在本说明中包含  个控制通道，!3 个流通道，! 或  个消息通道。

控制通道

分两种类型：主控制通道和第二控制通道。在消息或流通道创建前，必须实例化一个控制通道。例如，

有程序请求对一个寄存器进行写操作，以实现一个图像捕获，设备应该在寄存器被写入时返回一个响

应，而不是捕获已完成时。

特权：独占访问，通过写  寄存器授权访问。主程序能对设备进行读写，其他程序则不能，也不允

许创建一个第二控制通道，除其发送的 #$G+、"#$+ 等少数命令，其他命令请求

设备一概返回一个错误；控制访问，与前者不同在于，其他程序可以读设备，也允许具有控制访问权

的二级程序创建一个控制通道；具备切换能力的控制访问，与控制访问不同在于，该模式允许具有正

确凭据的程序控制设备；监控访问，条件最弱，一般用于调试帮助。只要无独占访问的程序连接设备

就可以读该设备。

设备必须记录主程序相关的上下文信息，至少包括程序  地址、源  端口和授予特权类型，以确定

其是否可授权给其他程序（如果收到的命令消息合法）。

在程序端使用一个动态端口号（任意），设备端使用标准  端口（除非通过 >5 通告了一个不

同的端口）就可以创建控制通道，再通过 #$G 命令创建链接。在软件开发阶段，对设备

使用非独占方式访问，有助于其他调试工具监控该设备。

寄存器：控制通道特权寄存器；控制切换键寄存器；心跳超时寄存器；待定超时寄存器。打开关闭

控制通道：程序通过对  寄存器写请求特权，并检查设备 7 消息返回的状态，根据状态码内容决

定是否有打开通道的资格。允许主程序在不关闭控制通道时请求相同的特权类型，如可通过写  寄

存器来直接切换到另一控制特权。通过对  寄存器写 ! 来关闭通道，并释放主程序的特权。

控制通道心跳：使用心跳序列可以定期检测控制通道是否处于活动状态，心跳速率是可自定义的，默

认每秒  次。设备在接收到主程序任一有效命令后，必须重置心跳计数，少数命令除外，如

6#5+。心跳计数可通过读  寄存器来重置，且只能由主程序执行。若设备在超过用户设置

的心跳超时时间（默认  秒）后，且没有禁用心跳性能寄存器，仍没有收到一个控制消息，则必须断

开控制通道。如果主程序不能读  寄存器或读取非预期数值时，即可判定链路断开，此时，必须实

例化控制通道以建立与设备的新链接。

设备控制：主程序可以在打开通道后，发送任何受  支持的命令，二级程序可发送 $$ 和

$ 命令读取设备速率。#$G、6#5 和 76$5 命令可以在任何时间由任一程

序发送，且设备总是在收到后返回一个 7 消息。

使用待定应答：若设备执行命令时间比程序预期的要长，则下述机制有助于相互间通信： ① 执行一

个请求所需的最大执行时间；

当请求执行时间将超过①中的值，使用使用 55+7 消息通知程序使其可以等待额外必需的

时间来完成该请求。

剩余18页未读，继续阅读

xayaya123

粉丝: 0
资源: 5

会员权益专享

GigE+Vision+2.0说明书.docx

评论0

会员权益专享

最新资源

GigE+Vision+2.0说明书.docx

评论0

GigE-Vision-2.0说明书

GigE-Vision-2.0中文版.pdf

GigE_Vision_Specification2.0

GigE Vision Specification 2.0.0.3

GigE-Vision简介.docx

GigE Vision2.0标准文档

GigE Vision v1.2.pdf

GigE-Vision-接口标准详细版本

gigevision协议下载

aia Gige vision 摄像机协议

GigE Vision Specification 1.0

gigecamera.rar_gige

python语言下如何通过yolov5调用gige相机

python语言下如何通过yolov5调用gige工业相机具体的代码

VS用于basler相机sdk二次开发要下载哪些组件

基于FPGA和万兆网的GigE Vison设计方案

Halcon连接Gige相机取图超时

GigE调试笔记_已经可以读取到数据和对摄像机进行设置

ros相机 uvc camera和usb camera

IPG20N06S4L-11A INFINEON 英飞凌芯片 中文版规格书.pdf

会员权益专享

最新资源

IPG20N06S4L-11A INFINEON 英飞凌芯片中文版规格书.pdf