多相机GigE Vision系统里“触发信号和图像数据走同一网段还是分离”这个问题容易让人一开始就往“网络冲突”上想。但GigE Vision协议本身已经把这两件事分得很清楚了GVCP控制协议管配置和触发走UDP 3956端口GVSP流协议管图像传输每条流绑定独立端口。协议层面触发和数据从来不在一个通道里抢路。真正会“打架”的地方在物理网络的瞬时带宽和上位机的接收调度上。触发报文本身很小但它决定了几台相机在什么时刻同时开始往外吐数据。多台相机被同一触发源同步拉起时图像数据会在极短时间内涌入交换机或网卡这才是丢包和“冲突”的来源。物理拓扑先看同步精度再看带宽如果每台相机接独立的网卡控制流量和数据流量天然隔离。触发广播走各自网卡出去图像流从各自网卡回来彼此不共享任何物理链路。这是最干净的做法多相机性能也最好。但如果相机通过交换机汇聚到一块网卡比如单口千兆接4台、8台相机触发和图像就共享了同一物理链路。这时“分离”不再是物理上的分离而是逻辑上的错峰。同时触发时必须给每台相机设置不同的包间延迟GevSCPD或帧传输延迟把图像数据拉开避免瞬时总带宽超过网卡或交换机端口的容量。千兆网卡接多台相机时这是必做项万兆网卡加万兆交换机可以放宽甚至不做因为总带宽本身够大。同步精度要求高的时候还要考虑Action广播的落点。普通的Action Command是毫秒级Scheduled Action配合PTP可以做到微秒级但前提是所有相关相机在同一网段内广播消息才能覆盖到。如果为了“隔离”把相机拆到不同VLAN或子网Action广播过不去同步就无从谈起。这种情况下要么接受独立NIC带来的物理隔离但用硬件触发线要么在交换机上做好PTP和IGMP配置让控制广播在受控的域内传递。上位机侧接收线程要隔离触发要去重网络侧把数据送到之后上位机的调度决定了下游会不会因为处理不过来而反压丢帧。最基本的要求是每条GVSP流一个独立的接收线程或异步任务不能用一个线程轮询所有相机。一个相机的数据包处理慢了不拖累其他相机。GenTL的常见实现也是每条流一个接收线程容忍包重排和丢包请求。接收线程只负责把包搬进队列解码、显示、存盘由下游消费者按各自节奏处理。队列可以是无界的内存允许时或有界加丢弃策略——GigE Vision的GVSP本身有重传机制但上位机不能依赖重传来兜底实时性要求高的场景。触发侧容易忽略的一个细节是广播源IP去重。如果上位机网卡配置了多个IP发送Action广播时如果不指定源IP每个IP都会发一次相机会收到重复触发多拍一帧。发送Action时绑定明确的本地端点是避免这种“幽灵帧”的最小改动。触发和图像的时间戳对齐也依赖相机侧的支持。支持PTP的相机Image Chunk里可以拿到与PTP时钟同步的曝光时间戳上位机用它而不是PC本地收包时间来做多相机帧配对。PC收包时间受协议栈和调度影响抖动可能在毫秒级跨相机对齐时不够用。由你创科技的做法我们由你创科技在做多相机GigE Vision上位机开发时通常先和客户确认两件事同步精度是毫秒级还是微秒级以及相机是独立网卡还是交换机汇聚。这决定了物理拓扑是“分离”还是“错峰”。上位机侧按每条流独立接收、独立缓冲的结构来搭触发发送明确绑定源端点时间戳优先用相机侧的PTP时间而不是PC收包时间。
