做视觉项目久了你会发现算法精度做到99.9%只是第一步真正让产线停下来的往往是通讯环节。海康威视视觉控制器比如我手上这台MV-VB2100-120G本身是一台预装Linux的工控机加GPU卡靠VisionMaster做定位、测量、缺陷检测一旦结果交不到PLC手里前面的算法工作全部白费。这几年我经手的视觉对接项目里超过一半的调试时间不是花在调参上而是花在TCP与Modbus通讯上。问题不在于协议本身多难而是两边工程师的预期完全不一致电气工程师盯着寄存器地址软件工程师盯着Socket收发缓冲区现场一吵就是半天。这篇文章我把TCP三次握手、长连接、短连接、Modbus RTU与TCP的报文差异、寄存器映射这些坑一次讲透同时给出一套能在MV-VB2100-120G上直接落地的配置流程文末还会整理我踩过多次的现场排障笔记。不管你是做集成的、做售后的还是刚从视觉算法转岗到现场的工程师照着这篇来省下的时间至少够你多睡两晚好觉。1. 调试前的必备认知为什么海康视觉系统离不开TCP与Modbus1.1 一条典型产线链路里视觉系统到底在跟谁说话在标准工位里视觉系统很少孤立工作。一个典型的检测工位链路是这样的传感器检测到产品到位给PLC一个硬接点信号PLC通过TCP或Modbus TCP向视觉控制器发送“触发拍照”指令视觉控制器完成抓图、算法处理再把OK或NG结果、测量数据写回PLCPLC根据结果控制气缸或报警灯。这个链路里视觉控制器扮演的是一个“边缘计算单元”角色。MV-VB2100-120G这类设备通常会装两个网口一个走GigE Vision接工业相机另一个走外部以太网接PLC和上位机。很多人第一次调试时喜欢把相机、PLC、电脑全塞进一个交换机结果发现拍照帧率上不去或者相机偶尔丢包其实就是内部图像数据流和外部控制数据流抢带宽。我的习惯是严格区分内外网控制器插相机的网口只做图像采集外部网口单独规划一个网段给PLC和上位机用。另一个容易忽略的点是触发方式。视觉控制器可以接受硬触发、软触发和通讯触发。通讯触发的优势在于不用额外拉线而且可以一次携带多个参数比如当前产品的型号、工艺版本号。TCP和Modbus在这里承担的就是触发与结果回传两条通道所以通讯稳定性直接决定了产线会不会频繁报“视觉超时”。1.2 TCP和UDP的区别以及为什么现场我优先选TCP很多刚从算法岗转过来的人会把TCP和UDP当成一个选择题其实在视觉场景里这不是选择而是妥协后的结果。TCP提供可靠传输有连接状态数据包丢失会重传顺序也能保证。UDP虽然延迟低但丢包了没人管用在图像流传输上可以靠应用层补偿用在控制信号上就是灾难。之前有个项目客户坚持要用UDP做结果回传理由是“响应快”。结果现场跑了半天偶尔出现PLC收到的是旧数据因为UDP不保证顺序客户端先发的包后到后发的包先到把视觉的OK信号当成上一个工件的NG信号差点导致不良品流出。后来我改成TCP虽然每次握手多点延迟但几十毫秒的量级对一般检测节拍完全没影响。除非你的节拍要求低于10毫秒否则别碰UDP。TCP的可靠性也意味着你要处理“连接建立”和“连接断开”这两个状态。视觉控制器作为服务端时如果PLC异常断电TCP连接不会立刻断开服务端要等到超时才能发现这会在现场表现为“PLC重启过后视觉一直显示连接正常但数据写不进去”。解决方法是应用层加心跳包后面我会专门讲。1.3 Modbus家族再认识RTU、ASCII、TCP不是简单换了个壳Modbus协议发展了几十年现在现场能见到的至少有三种变体Modbus RTU、Modbus ASCII和Modbus TCP。很多人以为TCP版本就是RTU报文前面套一个IP头这个理解不算全错但容易漏掉关键细节。表格对比一下特性Modbus RTUModbus ASCIIModbus TCP物理层串口RS232/RS485串口RS232/RS485以太网报文格式二进制带CRC16校验ASCII字符带LRC校验二进制以太网底层自动处理校验从站地址1字节0为广播地址1字节0为广播地址单元标识符Unit ID但IP地址已经起到寻址作用默认端口无无502典型应用变频器、仪表老旧设备PLC、SCADA、视觉系统Modbus TCP在MBAP报文头里有一个单元标识符这个字段在纯以太网场景下经常被忽略填0或1都能通。但当你有网关把Modbus TCP转成Modbus RTU时这个字段就会映射成RTU从站地址所以一开始就规划好Unit ID后面扩展设备会省很多事。MV-VB2100-120G的VisionMaster里Modbus配置页面是有Unit ID输入框的默认是1我习惯把它和PLC的站号对应起来方便现场维护。我选择Modbus TCP最重要的原因是接线成本和故障排查成本都低网线直接插交换机电脑上能开Wireshark抓包分析。串口Modbus RTU只要有一根线接触不良整个车间查起来都想摔键盘。2. 协议底层拆解三次握手、长连接与Modbus报文结构2.1 TCP三次握手和四次挥手用电话挂断来理解TCP建立连接大家听过三大名场面SYN、SYNACK、ACK。我用打电话来打比方客户端说“喂能听到吗”SYN服务端说“能听到你能听到我吗”SYNACK客户端再说“听到了”ACK线路正式建立。这个过程数据包只有几十字节但对视觉项目来说它意味着服务端程序必须能处理“半连接状态”。四次挥手比三次握手更折磨人。正常关闭过程是客户端发送FIN服务端返回ACK服务端再发送FIN客户端返回ACK。问题在于服务端发完FIN后会进入TIME_WAIT状态这个端口在默认Linux配置下会保持一两分钟不能立即重用。PLC频繁重连时视觉服务端有时候会报“bind: only one usage of each socket address”就是这个原因。后面我会给出具体解决办法。现场实际中PLC作为TCP客户端频繁掉线重连视觉控制器作为服务端不断收到SYN如果服务端程序卡在某个阻塞函数里操作系统协议栈会帮它把连接请求放进队列队列满了以后直接丢弃新连接。表现为PLC连不上但视觉软件看起来一切正常。所以在写视觉通信模块时主线程不能处理耗时逻辑必须把Socket监听和业务处理分线程。2.2 TCP长连接和短连接视觉项目到底该选哪个长连接就是建立一次TCP连接之后一直复用这条链路收发数据。短连接是每次交互都重新建立和断开。视觉场景里我强烈建议用长连接原因很简单一次TCP握手要经过一个RTT网络往返时间本地局域网虽然只有0.几毫秒但加上操作系统调度和PLC扫描周期可能变成几十毫秒。如果每个工件都走一次短连接节拍会白白损失。长连接最大的敌人是网络设备空闲超时。很多交换机或防火墙默认会清理长时间无流量的TCP会话比如300秒没有数据就主动断开。所以长连接必须配心跳频率建议在网关或交换机空闲超时时间的一半以下。一般我设置5秒一次心跳只发一个字节的空包。VisionMaster的TCP模块里可以配置心跳间隔我通常选5-15秒太频繁会占用PLC资源太少会被防火墙掐断。应用层还应该做重连机制。PLC那边断网重拨是常有的事视觉端必须能识别连接断开并自动进入监听状态。很多自己写脚本的工程师出问题就是只做了一次accept连接断开后程序直接退出第二天发现设备还在跑但通信线程早就没了。2.3 Modbus TCP报文结构一帧一字节拆开看Modbus TCP报文从TCP载荷开始算总共是MBAP头加PDU。MBAP头共7个字节前2字节是事务处理标识符第三、四字节是协议标识符固定为0x0000第五、六字节是后续字节数第七字节是单元标识符。举个例子读取从站1的保持寄存器起始地址40001读取10个寄存器。请求报文是事务标识符0x0001每次请求递增协议标识符0x0000长度0x0006单元标识符0x01功能码0x03读保持寄存器起始地址高字节0x00低字节0x00协议内部从0开始计数寄存器数量高字节0x00低字节0x0A连起来就是01 03 00 00 00 0A前面加上MBAP的00 01 00 00 00 06 01完整报文是00 01 00 00 00 06 01 03 00 00 00 0A。响应报文里长度字段表示后面还有多少字节比如返回20个字节数据整个响应会是00 01 00 00 00 17 01 03 14加20字节数据。这里事务标识符会在响应中原样返回我调试时就是靠它判断请求和响应是否对应。当PLC扫描周期很快同时发出多个请求时如果没有事务标识符匹配机制客户端很容易把上一帧响应当成当前帧尤其有网络延迟时数据会错位。2.4 功能码与寄存器类型Modbus世界里的四大存储区Modbus定义了四种基本数据对象线圈、离散输入、输入寄存器、保持寄存器。功能码表我再压一遍功能码名称读写方向位/字01读线圈主站读从站位02读离散输入主站读从站位03读保持寄存器主站读从站字04读输入寄存器主站读从站字05写单线圈主站写从站位06写单寄存器主站写从站字0F写多线圈主站写从站位10写多寄存器主站写从站字视觉结果里OK/NG状态这种开关量用线圈或寄存器都可以但测量值、坐标、角度这种数据必须用寄存器。为了减少PLC的编程量我一般是把视觉计算结果全部映射到保持寄存器上比如40001放触发模式40002放当前工件ID40003开始放X坐标、Y坐标、角度等Float型数据40031放结果状态。PLC只需要读连续寄存器不用区分功能码类型省掉一堆逻辑。有一点必须提醒Modbus文档和PLC组态软件里看到的寄存器地址比如40001到了实际报文里“起始地址”是从0开始偏置的。40001对应协议地址040011对应协议地址10。如果你直接拿PLC界面的40011塞进报文读出来的数据肯定会错位一位。2.5 字节序和数据类型转换数据错乱的万恶之源Modbus TCP传输的数据默认是大端字节序也就是高字节在前。但很多PLC内部存储是小端序比如西门子S7系列某些区域、三菱部分系列导致从寄存器读出来的32位数据高低16位互换、16位数据高低字节互换。我之前遇到过一个测量值忽大忽小的问题排查到最后就是Float32的字节序问题。视觉把X坐标100.5转成IEEE 754的0x42C90000按大端写入寄存器PLC按小端读取结果数值变成一个天文数字。这种情况下不是协议不通而是双方对“四个字节的排列顺序”没有达成一致。我习惯在做协议对接表时把32位数据定义为“高字在前”还是“低字在前”明确写下来必要时在VisionMaster的脚本里手动调整字节顺序。调试时我强烈建议先在测试工具里写入一个固定值比如十进制十六进制能看懂的0x12345678然后在PLC端用十六进制方式观察。如果看到0x3412和0x7856这种交换就知道字节序有问题跟通讯稳定性没关系。3. 海康MV-VB2100-120G的TCP通讯配置实战3.1 上电前的网络设置这一步决定后面所有排障MV-VB2100-120G有两个物理网口在Linux系统里通常显示为eth0和eth1在VisionMaster的通信配置里也能看到对应设备。我拿到的这台eth0用于接外部PLCeth1用于接工业相机。如果把相机插错口GigE Vision会发现设备但带宽可能受限最终还是影响稳定性。上电之前先规划好网段外部网口设一个固定IP比如192.168.10.10PLC端设192.168.10.1子网掩码255.255.255.0。有人喜欢把视觉控制器设成DHCP自动获取这在办公室没问题在产线上极不推荐PLC一重启或者DHCP服务器出问题IP一变整条线就跟视觉失联了。我习惯把视觉控制器设成静态IP并且在PLC侧把这个IP绑定到组态配置里避免别人误改。连接方式上能直连就直连非要走交换机的话视觉控制器和PLC尽量放在同一个二层广播域里。跨VLAN或跨路由场景下如果中间防火墙策略没放行TCP握手就会卡在SYN_SENT状态表现为“能ping通但连接超时”。3.2 VisionMaster中建立TCP服务端从监听连接到收发数据打开VisionMaster在“通信配置”或“视图管理—通信管理”里可以新建一个TCP服务端。参数很简单本地IP选和外网口一致的那个地址本地端口默认用8500或自己定一个不冲突的端口比如8000。有人喜欢用502端口的习惯是来自Modbus TCP自定义TCP就不要再占用502否则会和后面的Modbus服务冲突。服务端启动后VisionMaster会处于监听状态。PLC作为TCP客户端主动连接视觉控制器的IP和端口。建立连接后我在视觉端设置报文解析规则。最简单的触发帧定义是固定长度的ASCII字符串“TRIG”PLC每次触发发送这一帧。VisionMaster收到后触发一次图像采集处理结束后再向PLC回传“OK”或“NG”。这里有几个细节容易踩坑PLC发送的字符串一般带结束符比如回车换行\r\n。如果视觉端按变长报文解析要正确处理结束符PLC那边如果发送频率高几个数据帧可能粘在一起所以入站缓冲区必须按分隔符拆帧。回传结果时我也建议按固定长度帧来比如回传8字节前2字节是结果标识后6字节是预留位方便PLC用固定字节截取不用反复匹配字符。心跳包要单独定义比如PLC每5秒发0x00作为心跳视觉端收到后回复0x00。如果连续3个心跳周期没收到视觉端判定连接异常自动释放旧连接重新监听。3.3 一个实例PLC按键触发视觉回传结果说一个我最近调通的场景。客户用三菱Q系列PLC对接MV-VB2100-120G视觉作为TCP服务端端口8000。PLC侧在每次工件到达时发送5字节ASCII码“START”。视觉端收到后进入触发拍照流程检测完成视觉软件脚本把结果拼成报文发回PLC。报文格式我定成这样字节位置含义示例1结果帧头0xAA2结果状态0x01为OK0x02为NG0x03为超时3-6X坐标Float32高字节在前7-10Y坐标Float32高字节在前11校验字节前10字节异或值12帧尾0x55PLC端收到的数据帧是固定12字节前两字节匹配0xAA和0x55中间数据直接先当十六进制存下来。如果我自己写视觉端的Socket脚本这个过程大约100行Python就够但用VisionMaster内置通信模块的好处是它自带断线重连和心跳管理省掉自己在Linux下写守护进程的麻烦。3.4 端口占用、防火墙和系统层排障端口冲突这么查TCP通讯最常见的报错就是“bind: only one usage of each socket address”。这句话的意思是端口已经被别的进程占用了。调试时我在Linux终端执行netstat -tunlp | grep 8000能看到是哪个进程占用了8000端口然后直接用PID杀掉占用进程或者改VisionMaster的端口。Windows电脑做测试机时用管理员PowerShell跑netstat -ano | findstr 8000一样能定位到进程。防火墙也要注意。MV-VB2100-120G上如果开启了firewalld或iptables必须放行对应的TCP端口。以CentOS系Linux为例iptables -I INPUT -p tcp --dport 8000 -j ACCEPT iptables -I INPUT -p tcp --dport 502 -j ACCEPT这是最直接的操作但重启后会丢失更稳妥的方式还是把规则写进firewalld里。Windows电脑做TCP客户端调试时要确认Windows防火墙没有拦截VisionMaster进程或者直接临时关闭专用网络安全策略连通后再开回来。提示加了防火墙规则后不生效先确认规则顺序。iptables是按顺序匹配的如果前面有一条DROP ALL后面再加ACCEPT就白加了。4. Modbus TCP配置实战从VisionMaster到PLC的寄存器级对话4.1 视觉当主站还是从站角色不同配置差很多Modbus TCP有两种角色主站客户端和从站服务器。VisionMaster两种都能做。主站由视觉主动读写PLC寄存器适合视觉检测完成后主动把结果推进PLC从站则是由PLC每隔几十毫秒来读一次适合PLC需要定时获取视觉状态和数据的场合。在实际项目里我更偏向视觉当从站。因为PLC的扫描周期固定读操作由PLC发起时间上更容易控制不会出现视觉主动写的时候PLC还没扫描到该寄存器、数据被覆盖的问题。VisionMaster端配置Modbus从站时要指定本地端口502单元标识符1然后把预设的寄存器区域划分好。如果你把视觉当主站配置过程则反过来。要给VisionMaster填PLC的IP和端口寄存器地址读写功能码以及轮询周期。我用过一个方案是视觉每200ms读一次PLC的触发寄存器读到变化就拍照但这种方式对寄存器的变化监测逻辑要写得很严谨否则同一个触发信号会被重复处理。4.2 寄存器规划表写在纸上是笨办法但最好用任何一个Modbus项目开工第一件事就是出具一张寄存器地址规划表。我自己惯用的模板是这样的寄存器地址数据说明数据类型读写方向初始值40001触发指令UInt16PLC写视觉读040002工件计数UInt32视觉写PLC读040004检测结果UInt16视觉写PLC读040005X坐标Float32视觉写PLC读0.040007Y坐标Float32视觉写PLC读0.040009角度Float32视觉写PLC读0.040011运行状态UInt16视觉写PLC读0注意地址间隔UInt32占两个寄存器Float32占两个寄存器。我故意把40004设为UInt16因为检测结果只有OK/NG几种状态占一个寄存器就够了。这张表定了以后电气工程师对着PLC地址写梯形图视觉工程师对着VisionMaster脚本填寄存器两边不用扯皮。视觉端写入时要注意VisionMaster的脚本如果直接按内部标签写不一定会自动映射到Modbus地址需要手动把算法结果塞给对应的通讯变量。很多人的坑就在这里算法处理完了但忘了做“算法输出”到“通讯寄存器”的赋值导致PLC读到的一直是初始值。4.3 用Modbus测试工具联调没有PLC也能把协议打通调试视觉端的Modbus TCP我通常不先接PLC而是先用电脑上的测试工具充当对端。Modbus Poll可以模拟主站Modbus Slave可以模拟从站。这两个工具在调试时几乎是黄金搭档我用Modbus Slave模拟PLC从站让VisionMaster当主站去写数据检查数据是否写入再用Modbus Poll模拟PLC主站去读VisionMaster从站的寄存器看返回的数据对不对。有个现实问题这两个工具是商业软件网上确实流传着各种“注册码”或“密钥”。我的建议是别折腾这些不可靠的key弄不好还会带进恶意代码。免费阶段用试用版足够入门长期使用就直接购买授权或者用开源替代方案QModMaster、ModbusPal、Python的pymodbus库写几十行代码也能完成模拟器功能。我自己常用的两个方式QModMaster可以充当Modbus TCP主站界面直接填寄存器地址能实时显示数据变化。Python脚本用pymodbus库模拟从站代码量很小适合做自动化回归测试。from pymodbus.server import StartTcpServer from pymodbus.datastore import ModbusSequentialDataBlock from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext store ModbusSlaveContext( diModbusSequentialDataBlock(0, [0]*100), coModbusSequentialDataBlock(0, [0]*100), hrModbusSequentialDataBlock(0, [0]*100), irModbusSequentialDataBlock(0, [0]*100)) context ModbusServerContext(slavesstore, singleTrue) StartTcpServer(context, address(0.0.0.0, 5020))注意这里端口我故意写成5020避开权限限制。普通用户开502端口会被系统拒绝必须用root启动。测试时先用5020测通了再在正式环境里用502。4.4 与西门子、欧姆龙等PLC对接时的常用技巧西门子S7系列走Modbus TCP无论是300、1200还是1500都要知道一件事西门子原生是S7协议Modbus TCP需要调用专门的Modbus功能块或库函数。以S7-1200为例需要在程序里调用“MB_CLIENT”或“MB_SERVER”块把Modbus数据映射到DB块地址。DB块的字节序和Modbus寄存器字节序有差异操作32位数据时要额外注意高字和低字的排列。欧姆龙NX-CIF105是串行通信单元但欧姆龙也有内置以太网口的CPU可以走Modbus TCP。NX-CIF105要实现Modbus TCP通讯实际是把网络端口映射到PLC的内存区如果现场要求你用这个模块做Modbus TCP你要看清它是否支持EtherNet/IP或Socket Service而不仅仅是RS-232C/485的Modbus RTU。如果只支持RTU那就需要外接一个串口转以太网网关网关的IP作为TCP服务端PLC通过CIF105的串口侧读写Modbus RTU以太网侧和VisionMaster的Modbus TCP对接。我还接过一个项目现场是1个西门子PLC带32台变频器走Modbus RTU中间还挂着一台视觉控制器。这种拓扑下如果视觉也走串口Modbus RTU链路负载会被拖垮。我把视觉剥离到以太网上改用Modbus TCP和变频器分别在不同物理通道一次都没出过通讯竞争。这就是我为什么一直坚持只要条件允许视觉通讯优先考虑Modbus TCP。5. 常见问题与排查技巧实录5.1 端口被占用、bind失败这些报错我见太多“bind: only one usage of each socket address”基本都能归到端口占用或TIME_WAIT。Linux默认TIME_WAIT周期是60秒短连接频发时端口会在TIME_WAIT里滞留导致绑定失败。解决方式有三种设置SO_REUSEADDR让服务端重启后能立即复用端口。VisionMaster的TCP服务端默认会处理这个自己写脚本时必须显式加上。调整系统参数/proc/sys/net/ipv4/tcp_tw_reuse但这不是万能药不建议在关键设备上乱开。排查真实占用用ss -tunlp或是lsof -i:8500看到底谁占着端口。有一种隐蔽情况是同一个设备同时开了VisionMaster和自研的Socket程序两个进程都试图监听同一个TCP端口。VMDebug这个进程有时候会占用调试接口尤其端口范围没配置好就会跟业务端口冲突。5.2 寄存器能读写但数据跟实际对不上这类问题我先列一个速查表现象可能原因排查顺序读到的数据全是0或65535寄存器地址偏了一位或协议地址未转换先用测试工具读固定数值数值反了比如1变成256字节序反了写入0x12345678观察Float型数据是个天文数字IEEE 754字节序问题或高低16位互换比对PLC和视觉的字节序设置数据偶尔跳变长连接缓冲区残留或读写冲突抓包确认请求响应是否成对视觉写入成功但PLC读不到PLC扫描周期和视觉写入时序交叉PLC侧加间隔读取或双缓冲我总会先做一个“写固定值”实验视觉端或者测试工具往某个寄存器写入0x1234PLC端直接看原始十六进制。看到0x3412就是字节交换看到0x1234就是对的。这一步能排除80%的数据对齐问题。5.3 连接正常但通讯频繁超时不是协议的问题超时问题听起来像协议层实际上很多时候是系统层的。视觉控制器CPU在跑深度学习推理时如果代码里没有给通讯线程设置高优先级操作系统调度器可能把Socket线程饿着导致PLC发过来的请求响应延迟爆炸。这时候CPU占用率往往看起来不高但通讯线程就是上不去。我遇到过一次典型的MV-VB2100-120G在跑一个分割模型GPU占用率拉满CPU还有50%但Modbus响应从10ms漂移到500ms。解决办法是给VisionMaster设置CPU亲和性把视觉推理任务绑到物理核通讯任务放到另一个核并且给VisionMaster进程配置高优先级。Linux下可以用taskset和chrt命令来调整。还有交换机的端口隔离和风暴抑制。曾经有客户现场交换机里有一个环网导致广播风暴视觉和PLC之间能ping通但TCP数据进不来这属于网络规划问题。排查手段就是抓包先抓视觉控制器网口上的流量看目标端口的TCP包是否正常。5.4 长连接老是被断开心跳和重连机制别省前面我提到长连接要用心跳。心跳包不是一个可选项而是必须项。设5秒一次心跳PLC如果连续丢掉3个心跳就应该认为通讯链路异常进入报警逻辑。视觉端也一样如果连续收不到PLC的心跳自动断开当前Socket重新进入监听状态。还有一个容易被忽略的是TCP KeepAlive机制。Linux默认KeepAlive时间是7200秒,太长了在应用层自己实现心跳之前可以先把系统参数调短sysctl -w net.ipv4.tcp_keepalive_time30 sysctl -w net.ipv4.tcp_keepalive_intvl5 sysctl -w net.ipv4.tcp_keepalive_probes3但即使这样KeepAlive只能检测到连接不可达如果PLC死机后网线还插着TCP层面可能还是认为连接正常。所以最可靠的方式还是业务层心跳在寄存器里放一个递增计数器PLC每次读的时候判断累加值有没有变化没变化就说明视觉端已经卡死这个计数器我给它取名叫“活着计数器”。5.5 测试工具和密钥问题我的实话Modbus Poll、Modbus Slave这类工具好归好但网上那些“注册码”十有八九是失效的有些甚至是在拿你的电脑当肉鸡跑脚本。我见过有人为了省几百块钱去下破解版结果电脑卡成幻灯片。如果你只是调试视觉和PLC免费版Modbus Poll已经能创建多数主站连接只是不能保存多个配置和长期使用调试完项目绰绰有余。我个人的做法是公司采购一套正版授权一个授权装在调试笔记本上出差必带。个人学习用开源工具ModbusPal模拟从站很稳定QModMaster做主站测试也顺手。如果自己会写Pythonpymodbus库足够满足绝大多数联调需求。工具本身不是核心核心是你理解每一帧的含义工具只是帮你把报文显示出来。提示任何工具显示的数据都要心里先有预期值再去比对。没有预期就去看数据出了错你也不知道错在哪。写在最后的个人体会从硬件接线到寄存器映射再把TCP状态机调通整套流程走下来我发现视觉项目真正需要的不是代码写得多炫而是通讯文档写得够不够细。我每次建新项目第一周一定会拉着电气工程师签一份“寄存器通信表”写清楚地址、类型、读写方向、字节序后面就算人员变动项目也能接得住。还有一个小习惯就是给寄存器地址留一个版本号区域每次协议有改动就把版本号加一PLC和视觉两边对照版本能少吵无数架。现场调试最大的敌人不是技术难题而是“我觉得你那边配错了”和“我觉得我这边没错”这两句来回拉扯。把协议一层层在测试工具里验证清楚再接到PLC上你会发现所以问题最后都会归结到一个很简单的原因上。