1. 项目概述为什么要给IN-Sight智能相机加TCP/IP通讯做机器视觉这一行迟早要面对一个问题相机检测完了结果怎么告诉PLC或者上位机今天要聊的IN-Sight智能相机也就是康耐视的In-Sight系列虽然本身自带串口和I/O但实际项目中接触最多的还是以太网通讯。原因很简单——产线上设备越来越多距离越来越远串口速率和布线灵活性已经跟不上需求了。TCP/IP通讯在IN-Sight上的意义说白了就两件事一是把相机的检测结果OK/NG、坐标、尺寸数据发送给PLC或MES系统二是接收外部设备发来的指令触发信号、配方切换、参数修改。这两件事能跑通视觉系统才算真正融入到整条自动化产线里。如果你之前只停留在“相机连上电脑看图像”的阶段那这篇内容正好可以帮你把通讯这块补上。这篇文章会完整走一遍IN-Sight智能相机实现双向TCP/IP通讯的流程从最基础的IP地址规划、Socket通讯原理讲起带你在In-Sight内部搭建TCP服务器和客户端处理数据收发最后再分享几个我在现场常用的网络调试助手工具和踩过的坑。适合的读者包括刚接触视觉系统的电气工程师、调试设备的现场人员以及准备把视觉系统接入上位机的自动化集成从业者。2. TCP/IP通讯基础从PLC到相机都要懂的几个关键点2.1 为什么TCP/IP在工业现场比串口更吃香很多老师傅习惯用RS232或RS485但新项目里大家越来越倾向以太网通讯。这不是赶时髦而是实际使用体验决定的。RS485虽然抗干扰能力强但布线要手拉手串联波特率一般也就9600到115200数据量一大就卡。而以太网用的是双绞线或光纤带宽随便就是百兆千兆而且走的是标准TCP/IP协议栈不需要自己折腾CRC校验、从站地址这些底层东西。TCP和UDP的区别也值得一提。TCP是有连接的要经过三次握手建立会话数据发出去对方没收到会自动重传所以可靠性高适合传检测结果、配方参数这些不能出错的数据。UDP则是无连接的只管发不管收没收到速度快但容易丢包通常用在实时性要求极高、丢几帧也无所谓的场景。IN-Sight相机做双向控制我建议首选TCP因为视觉检测结果一旦丢包可能造成漏检误判产线上这是出大事的。2.2 IP地址规划通讯第一步也是最容易踩坑的一步做TCP/IP通讯第一步不是打开软件写代码而是先把网络地址规划好。IN-Sight相机默认的IP地址通常需要手动配置你必须确保相机、电脑、PLC三者在同一个网段内。举个例子相机的IP是192.168.1.10子网掩码255.255.255.0那你的电脑就要设成192.168.1.20这种前三位一样、第四位不同的地址否则物理上通了逻辑上也是不通。PLC的以太网模块比如西门子S7-1200的PROFINET口、三菱FX5U的以太网口一样要设成同一网段。网关地址如果现场没有跨网段需求可以不用太较真但最好还是统一设成192.168.1.1这样的习惯值方便后续扩展。实际项目中我就遇到过把相机设成192.168.1.10、电脑却用着自动获取的192.168.8.55这种鬼情况排查了半天才发现是网段不一致造成的。2.3 客户端与服务端的角色判断TCP通讯里有两个角色服务端Server和客户端Client。服务端是被动方它绑定一个端口号开始监听等别人来找它客户端是主动方它知道服务器的IP和端口号后主动发起连接。这里有个关键认知谁做服务端谁做客户端不是根据设备重要性来的而是根据谁能固定提供IP来决定的。IN-Sight相机既能做服务端也能做客户端。我在实际项目中是这样选的如果PLC或上位机软件比如康耐视自带的VisionView、第三方SCADA主动来连相机取数据那相机就做服务端如果相机需要主动把数据推送到某个固定IP的服务器那相机就做客户端。没有绝对标准但有个原则——固定的那端做服务端变动的那端做客户端这样地址维护起来最省事。3. IN-Sight相机侧配置实操从网络参数到通讯模块3.1 用In-Sight Explorer修改相机IP地址拿到相机第一步先确认当前IP。用网线直连电脑打开In-Sight Explorer软件在联机状态下会自动以广播方式搜索到相机。如果搜不到大概率是IP网段问题这时可以把电脑网卡手动设成192.168.0.x具体要看相机出厂默认网段老的In-Sight相机很多是192.168.0.100。进入“传感器设置”——“网络”界面能看到当前相机的IP、子网掩码、网关。改成你要规划的地址后点“设置”相机会自动重启网络服务。这时电脑网卡也要改到同一网段不然又断了。顺带一提IN-Sight相机支持DHCP自动获取但工业现场强烈不建议开DHCP因为一旦路由器重启或者有人接错网线IP一变上位机连不上了产线直接报警停线太被动了。3.2 建立TCP服务端接收外部指令很多项目里PLC需要在下发触发信号的同时给相机传几个参数比如当前产品型号。IN-Sight里实现这个功能需要用到“网络”面板下的“TCP服务器”设置。操作路径大致是在In-Sight Explorer里打开EasyBuilder就是那个拖拽式的视觉流程编辑界面在左侧工具列表的“通讯”分类下找到“TCP服务器”工具拖到流程里。双击打开配置窗口设置监听端口比如10240缓冲区大小默认就行。关键一步是设置“接收到的数据”如何处理——通常是把接收到的字节数组保存为单元格方便后续用电子表格公式解析。这里有个容易忽略的细节TCP是流式协议不像串口一帧一帧那么清晰应用层必须自己定义帧格式。最简单实用的做法是每条指令以回车换行符结尾\r\n或者用固定的帧头帧尾比如帧头AA55、帧尾55AA。解析时先找帧头再按固定位置取数据这样最稳。3.3 用TCP客户端向PLC发送检测结果相机做服务端适合被动的等指令但检测结果主动上报用客户端模式更自然。IN-Sight的“TCP客户端”工具同样在“通讯”分类下。在EasyBuilder流程里添加TCP客户端工具后需要填目标服务器的IP和端口号也就是PLC或者上位机的监听地址。发送内容的构造是核心。我的习惯是把检测结果拼成固定格式的字符串再发送。比如发送“$DETOK;X12.34;Y56.78;Angle90.5\r\n”这种格式用分号分隔字段PLC端用FIND指令按关键字分割提取。为啥要带固定帧头因为TCP数据可能被拆分也可能合并接收端需要靠起始标记来对齐数据帧。你要是不信抓包看一次就明白了——发送端一次send出去的数据接收端可能recv到两三次所以按固定分隔符解析比按固定长度解析可靠得多。3.4 实现双向通讯的整体流程编排真正实现双向通讯不能只靠一个工具。我一般把流程排成这样第一步相机的JobManager里跑视觉检测流程图像采集、定位、测量、判断第二步TCP服务器一直在线监听外部指令第三步TCP客户端负责把视觉脚本计算出的结果包封装成帧并发送出去。In-Sight的EasyBuilder流程是循环执行的所以可以把TCP服务器的接收状态做成一个条件分支如果收到特定指令就切换到对应的配方流程或者触发一次拍照。视觉结果出来后把数据写入单元格TCP客户端发送工具每次都读取这些单元格的值去组帧发送。这是个循环往复的过程调试时要特别小心的是发送频率别太高否则上位机可能处理不过来一般建议加了通讯成功标志位确认之后再发下一帧。4. 实操过程用网络调试助手配合搞定双向通讯4.1 网络调试助手到底怎么选工欲善其事必先利其器调试TCP/IP通讯必须要有趁手的工具。这里直接说结论这些年我用的最多的是下面这几个工具名称支持协议优点适用场景网络调试助手NetAssistTCP Server/Client、UDP界面简单上手快收发显示齐全日常通讯调试首选TCPUDP调试工具TCP/UDP Debug ToolTCP Server/Client、UDP支持定时发送、文件发送模拟批量数据交互SocketToolTCP Server/Client、UDP多连接管理方便测试多个客户端同时连接WiresharkTCP/UDP抓包工具能看到每个数据包的内容和时序排查协议层疑难杂症网络调试助手NetAssist应该是工控圈子里流传最广的一款经典版本V5.0.3至今还在很多电脑上装着。它最实用的功能就是你既可以启动一个TCP Server来等相机连上来收数据也可以作为TCP Client去连相机验证相机的服务端监听是否正常。反正调试时角色别搞混工具两端都扮演过你就知道数据应该从哪边发、从哪边收了。4.2 完整调试流程演示相机做主助手做从上位机视角验证下面的流程我以最经典的组合来演示相机作为TCP客户端主动把检测结果发送给电脑上运行的“网络调试助手”TCP Server同时相机上再开一个TCP服务端接收调试助手发来的指令。这样一个电脑上的软件就能同时验证相机的收发功能实际项目里只不过是把电脑替换成PLC或MES服务器而已。第一步打开网络调试助手协议类型选“TCP Server”本地IP选电脑网卡地址比如192.168.1.20本地端口填10240点击“打开”。这时调试助手就进入监听状态等待客户端连接。第二步在In-Sight Explorer里配置好TCP客户端工具目标IP填192.168.1.20目标端口填10240然后触发一次视觉流程或直接手动触发发送。网络调试助手的接收区就会弹出类似于“[2024-01-01 10:00:00] $DETOK;X12.34;Y56.78”的字符串这说明相机到电脑的链路通了。第三步验证反向通讯。在网络调试助手里作为TCP Server双击连接列表里的相机在下方的“发送”区域输入“$TRIG\r\n”点击发送。切回In-Sight Explorer观察TCP服务器工具的接收区是否收到了这串数据。如果能在单元格里看到“$TRIG”说明电脑到相机的链路也通了。两边都通双向TCP/IP通讯就建立成功了剩下的就是格式解析和业务逻辑的活。4.3 报文设计心得字段分隔符与数据类型转换调试中最容易出问题的就是数据类型转换。TCP只认字节你发送的“12.34”本质上是ASCII字符PLC收到后要做字符串转浮点数的处理才能参与计算。反过来PLC发给相机的数据可能是整数或实数相机侧接收后也要转回字符串再做拆分。所以我的建议是能发字符串就发字符串不要发二进制浮点。字符串可读性好抓包一眼能看出对错PLC侧SCL或梯形图里有现成的字符串转数值指令比如西门子的STRG_VAL、三菱的串口转换功能解析起来轻松很多。如果追求传输效率或者数据量特别大可以考虑二进制但调试成本会高不少项目周期不宽裕时不要冒险。5. 常见问题与排查技巧实录5.1 连接不上先从物理层自查“相机连不上”、“数据发不过来”是出现频率最高的问题。我总结了一个排查顺序大家照着做基本能解决八成问题看网口指示灯——网线插上后电脑和相机的网口灯应该亮起或者闪烁不亮就换网线或者查接口氧化ping一下——电脑命令提示符里ping 192.168.1.10相机的IP能通说明链路通不通就检查IP设置和防火墙关防火墙——Windows防火墙经常拦掉非标准端口的TCP连接调试期直接临时全关或者把你用的端口加入放行规则确认端口没被占用——netstat -ano | findstr 10240 命令看一下如果被其他进程占用了换个端口号。5.2 数据能连上但收不到或乱码链接建立成功说明TCP握手没问题故障集中在数据解析层。乱码大概率是编码格式不匹配相机默认用ASCII字符串PLC那边如果用GBK解析或者字节序搞反了显示就会乱。解决办法是统一编码工控环境建议全链路用ASCII中文内容能不用就不用避免编码地狱。收不到完整帧也比较常见。TCP没有消息边界发送方一次发送的内容接收方可能分两包收到也可能两包并一包收到。应对思路很简单接收端按固定帧头帧尾做缓存拼接。我写过无数次的套路是——把接收到的每段数据追加到缓冲区然后搜索帧头位置截取从帧头到帧尾或换行符之间的完整数据帧剩下的留在缓冲区等下一段。IN-Sight的电子表格环境里可以用FIND和MID函数实现同样的逻辑PLC侧就是沿用一个背景数据块做累加和解析。5.3 相机通讯偶发性断线还有一种玄学故障通讯平时好着但产线跑着跑着就断了过一会又自己恢复。这种多半是网络环境不稳定最常见的有两种情况。一种是网线质量差工业环境电磁干扰强普通网线跑百兆跑不了多远就丢包另一种是交换机问题有些现场用的家用宽带路由器长时间高负载运行会死机重启相机和PLC重连就需要时间。解决方向换工业级超五类或六类屏蔽网线摄像头侧和PLC侧都加工业以太网交换机而不是民用路由器如果你的控制器支持把TCP KeepAlive参数打开就是TCP层面的心跳保活机制这样链路假死几分钟后会被系统强制断开并重连避免一直挂着断掉的连接。5.4 发送给PLC的数据触发不了动作数据明明显示了PLC就是不动作这种也让人很抓狂。排查重点在于数据类型和字节顺序。PLC的字符串寄存器通常需要调用指令去解码不能用普通数值比较指令直接比较一个字符串变量。另外西门子PLC的STRING类型自带长度字节头和相机的纯ASCII帧格式有差异所以很多人选择用Modbus TCP或者干脆用S7协议来传而不是用裸TCP自己解析。这里给个实用建议如果PLC侧不想花太多精力做字符串解析可以给相机配一个“双格式输出”既能发ASCII字符串给MES看也能发Modbus TCP写PLC的保持寄存器。这样各取所需但实现难度会上升适合项目预算充裕、调试时间充足的情况。6. 从调试助手到真实产线一个完整的通讯方案实例6.1 实际场景描述前面讲了太多零散的操作最后用一个真实场景把整个流程串一遍。假定现场有台IN-Sight相机做产品定位检测检测结果需要送给西门子S7-1200 PLCPLC根据结果决定气缸是否动作。同时PLC在接近传感器触发时送给相机一个拍照指令和当前产品型号ID。整体通讯架构是这样的相机作为TCP服务器监听端口10240等着PLC作为客户端连上来PLC通过以太网模块主动连接相机后发送“$SHOT;MODEL2\r\n”指令相机收到后执行对应型号的检测流程检测完成后相机通过同一个TCP连接发送“$RES;OK;X10.0;Y20.0;R90.2\r\n”给PLC。为什么用同一条连接因为TCP Server可以同时接收和发送PLC连上一次后保持长连接省去反复握手的时间。6.2 相机侧的具体配置清单相机IP设为192.168.1.10子网掩码255.255.255.0。TCP Server工具的端口设为10240。接收数据设置以换行符作为帧结束标志收到的数据存到单元格$RecvBuf。确认收到完整指令的方法是判断字符串末尾是否包含“\r\n”然后用FIND($SHOT, $RecvBuf)做关键词匹配。发送检测结果的TCP Client工具或者用TCP Server的发送属性在流程最后执行数据源是$ResultStr数据格式是$RES;OK;X10.0;Y20.0;R90.2\r\n字段位置用分号固定好头两位$RES是帧头标记第三位OK是结果后续按约定顺序排坐标和角度。PLC端用FIND和MID依次提取各字段转成REAL类型参与逻辑判断。6.3 PLC侧配合的要点PLC侧的S7-1200用TCON、TSEND、TRCV这三个指令配合做TCP通讯这仨指令在博途的“通信 - 开放式用户通信”里能找到。TCON建立连接时要把伙伴地址设成192.168.1.10:10240注意PLC侧需要本地端口比如15000。连接ID和连接数据块要建好否则TCON报错。收发数据都建议用Buffer收发缓冲区单独建。TRCV接收到的数据放在数组里然后通过循环找帧头$RES找到后再定位分号坐标。注意在PLC侧做接收使能时要常通很多新手只使能一次、接收完就关掉了这样后面数据就进不来了。正确做法是TRCV的数据参数一直传入相同的接收缓冲区有新数据会自动覆盖解析。6.4 联调期间的注意事项联调时最忌讳一上来就跑全流程。我习惯分三步走第一步相机上和网络调试助手连通确认相机发的数据格式正确第二步用网络调试助手模拟PLC作为TCP Client连接相机发指令收回复确认相机逻辑无误第三步关闭调试助手把PLC作为真正的客户端连上来验证PLC的TCON连接和TRCV收发是否稳定。这样每一步都有明确的验证标准和排错边界出了问题能快速定位在哪个环节。7. 最后分享两个提升效率的小经验第一个经验用网络调试助手做“回环测试”。自检方法很简单——在网络调试助手里同时开两个TCP Client都连到相机的Server端口一个发指令一个收数据。如果相机不管收到哪个客户端的数据都会同时广播回复给所有已连接客户端那调试时用两个客户端窗口一发一收你就能直观看到相机数据广播逻辑对不对。缺点是外部设备如果只认一对一连接会收到多余数据所以这个测试仅限联调阶段用。第二个经验通讯异常时花十分钟抓一次包胜过瞎猜两小时。Wireshark抓包的时序能清楚看到TCP三次握手是否成功、数据包有没有重传、应用层报文的真实内容是什么。不用懂太多底层知识用“Follow TCP Stream”功能直接看下发双方的原始数据流就足以定位九成以上的通讯问题。家里备一个USB转网口的适配器解决笔记本网口不够用的尴尬现场调试更从容。做工业通讯这行最重要的是把基础原理弄扎实再通过工具去验证自己的理解。TCP/IP双向通讯说白了就是“谁监听、谁连接、发什么都协议、收到怎么解”这四个问题。把这四个问题在IN-Sight调试环境里各解决一遍以后再接到新的摄像头、新的PLC照样能稳稳地连起来。这篇内容里面的操作细节和坑点都是在实际项目里一条一条蹚出来的希望对正在搞视觉通讯的朋友有些帮助。
IN-Sight智能相机TCP/IP双向通讯配置与调试实战指南
1. 项目概述为什么要给IN-Sight智能相机加TCP/IP通讯做机器视觉这一行迟早要面对一个问题相机检测完了结果怎么告诉PLC或者上位机今天要聊的IN-Sight智能相机也就是康耐视的In-Sight系列虽然本身自带串口和I/O但实际项目中接触最多的还是以太网通讯。原因很简单——产线上设备越来越多距离越来越远串口速率和布线灵活性已经跟不上需求了。TCP/IP通讯在IN-Sight上的意义说白了就两件事一是把相机的检测结果OK/NG、坐标、尺寸数据发送给PLC或MES系统二是接收外部设备发来的指令触发信号、配方切换、参数修改。这两件事能跑通视觉系统才算真正融入到整条自动化产线里。如果你之前只停留在“相机连上电脑看图像”的阶段那这篇内容正好可以帮你把通讯这块补上。这篇文章会完整走一遍IN-Sight智能相机实现双向TCP/IP通讯的流程从最基础的IP地址规划、Socket通讯原理讲起带你在In-Sight内部搭建TCP服务器和客户端处理数据收发最后再分享几个我在现场常用的网络调试助手工具和踩过的坑。适合的读者包括刚接触视觉系统的电气工程师、调试设备的现场人员以及准备把视觉系统接入上位机的自动化集成从业者。2. TCP/IP通讯基础从PLC到相机都要懂的几个关键点2.1 为什么TCP/IP在工业现场比串口更吃香很多老师傅习惯用RS232或RS485但新项目里大家越来越倾向以太网通讯。这不是赶时髦而是实际使用体验决定的。RS485虽然抗干扰能力强但布线要手拉手串联波特率一般也就9600到115200数据量一大就卡。而以太网用的是双绞线或光纤带宽随便就是百兆千兆而且走的是标准TCP/IP协议栈不需要自己折腾CRC校验、从站地址这些底层东西。TCP和UDP的区别也值得一提。TCP是有连接的要经过三次握手建立会话数据发出去对方没收到会自动重传所以可靠性高适合传检测结果、配方参数这些不能出错的数据。UDP则是无连接的只管发不管收没收到速度快但容易丢包通常用在实时性要求极高、丢几帧也无所谓的场景。IN-Sight相机做双向控制我建议首选TCP因为视觉检测结果一旦丢包可能造成漏检误判产线上这是出大事的。2.2 IP地址规划通讯第一步也是最容易踩坑的一步做TCP/IP通讯第一步不是打开软件写代码而是先把网络地址规划好。IN-Sight相机默认的IP地址通常需要手动配置你必须确保相机、电脑、PLC三者在同一个网段内。举个例子相机的IP是192.168.1.10子网掩码255.255.255.0那你的电脑就要设成192.168.1.20这种前三位一样、第四位不同的地址否则物理上通了逻辑上也是不通。PLC的以太网模块比如西门子S7-1200的PROFINET口、三菱FX5U的以太网口一样要设成同一网段。网关地址如果现场没有跨网段需求可以不用太较真但最好还是统一设成192.168.1.1这样的习惯值方便后续扩展。实际项目中我就遇到过把相机设成192.168.1.10、电脑却用着自动获取的192.168.8.55这种鬼情况排查了半天才发现是网段不一致造成的。2.3 客户端与服务端的角色判断TCP通讯里有两个角色服务端Server和客户端Client。服务端是被动方它绑定一个端口号开始监听等别人来找它客户端是主动方它知道服务器的IP和端口号后主动发起连接。这里有个关键认知谁做服务端谁做客户端不是根据设备重要性来的而是根据谁能固定提供IP来决定的。IN-Sight相机既能做服务端也能做客户端。我在实际项目中是这样选的如果PLC或上位机软件比如康耐视自带的VisionView、第三方SCADA主动来连相机取数据那相机就做服务端如果相机需要主动把数据推送到某个固定IP的服务器那相机就做客户端。没有绝对标准但有个原则——固定的那端做服务端变动的那端做客户端这样地址维护起来最省事。3. IN-Sight相机侧配置实操从网络参数到通讯模块3.1 用In-Sight Explorer修改相机IP地址拿到相机第一步先确认当前IP。用网线直连电脑打开In-Sight Explorer软件在联机状态下会自动以广播方式搜索到相机。如果搜不到大概率是IP网段问题这时可以把电脑网卡手动设成192.168.0.x具体要看相机出厂默认网段老的In-Sight相机很多是192.168.0.100。进入“传感器设置”——“网络”界面能看到当前相机的IP、子网掩码、网关。改成你要规划的地址后点“设置”相机会自动重启网络服务。这时电脑网卡也要改到同一网段不然又断了。顺带一提IN-Sight相机支持DHCP自动获取但工业现场强烈不建议开DHCP因为一旦路由器重启或者有人接错网线IP一变上位机连不上了产线直接报警停线太被动了。3.2 建立TCP服务端接收外部指令很多项目里PLC需要在下发触发信号的同时给相机传几个参数比如当前产品型号。IN-Sight里实现这个功能需要用到“网络”面板下的“TCP服务器”设置。操作路径大致是在In-Sight Explorer里打开EasyBuilder就是那个拖拽式的视觉流程编辑界面在左侧工具列表的“通讯”分类下找到“TCP服务器”工具拖到流程里。双击打开配置窗口设置监听端口比如10240缓冲区大小默认就行。关键一步是设置“接收到的数据”如何处理——通常是把接收到的字节数组保存为单元格方便后续用电子表格公式解析。这里有个容易忽略的细节TCP是流式协议不像串口一帧一帧那么清晰应用层必须自己定义帧格式。最简单实用的做法是每条指令以回车换行符结尾\r\n或者用固定的帧头帧尾比如帧头AA55、帧尾55AA。解析时先找帧头再按固定位置取数据这样最稳。3.3 用TCP客户端向PLC发送检测结果相机做服务端适合被动的等指令但检测结果主动上报用客户端模式更自然。IN-Sight的“TCP客户端”工具同样在“通讯”分类下。在EasyBuilder流程里添加TCP客户端工具后需要填目标服务器的IP和端口号也就是PLC或者上位机的监听地址。发送内容的构造是核心。我的习惯是把检测结果拼成固定格式的字符串再发送。比如发送“$DETOK;X12.34;Y56.78;Angle90.5\r\n”这种格式用分号分隔字段PLC端用FIND指令按关键字分割提取。为啥要带固定帧头因为TCP数据可能被拆分也可能合并接收端需要靠起始标记来对齐数据帧。你要是不信抓包看一次就明白了——发送端一次send出去的数据接收端可能recv到两三次所以按固定分隔符解析比按固定长度解析可靠得多。3.4 实现双向通讯的整体流程编排真正实现双向通讯不能只靠一个工具。我一般把流程排成这样第一步相机的JobManager里跑视觉检测流程图像采集、定位、测量、判断第二步TCP服务器一直在线监听外部指令第三步TCP客户端负责把视觉脚本计算出的结果包封装成帧并发送出去。In-Sight的EasyBuilder流程是循环执行的所以可以把TCP服务器的接收状态做成一个条件分支如果收到特定指令就切换到对应的配方流程或者触发一次拍照。视觉结果出来后把数据写入单元格TCP客户端发送工具每次都读取这些单元格的值去组帧发送。这是个循环往复的过程调试时要特别小心的是发送频率别太高否则上位机可能处理不过来一般建议加了通讯成功标志位确认之后再发下一帧。4. 实操过程用网络调试助手配合搞定双向通讯4.1 网络调试助手到底怎么选工欲善其事必先利其器调试TCP/IP通讯必须要有趁手的工具。这里直接说结论这些年我用的最多的是下面这几个工具名称支持协议优点适用场景网络调试助手NetAssistTCP Server/Client、UDP界面简单上手快收发显示齐全日常通讯调试首选TCPUDP调试工具TCP/UDP Debug ToolTCP Server/Client、UDP支持定时发送、文件发送模拟批量数据交互SocketToolTCP Server/Client、UDP多连接管理方便测试多个客户端同时连接WiresharkTCP/UDP抓包工具能看到每个数据包的内容和时序排查协议层疑难杂症网络调试助手NetAssist应该是工控圈子里流传最广的一款经典版本V5.0.3至今还在很多电脑上装着。它最实用的功能就是你既可以启动一个TCP Server来等相机连上来收数据也可以作为TCP Client去连相机验证相机的服务端监听是否正常。反正调试时角色别搞混工具两端都扮演过你就知道数据应该从哪边发、从哪边收了。4.2 完整调试流程演示相机做主助手做从上位机视角验证下面的流程我以最经典的组合来演示相机作为TCP客户端主动把检测结果发送给电脑上运行的“网络调试助手”TCP Server同时相机上再开一个TCP服务端接收调试助手发来的指令。这样一个电脑上的软件就能同时验证相机的收发功能实际项目里只不过是把电脑替换成PLC或MES服务器而已。第一步打开网络调试助手协议类型选“TCP Server”本地IP选电脑网卡地址比如192.168.1.20本地端口填10240点击“打开”。这时调试助手就进入监听状态等待客户端连接。第二步在In-Sight Explorer里配置好TCP客户端工具目标IP填192.168.1.20目标端口填10240然后触发一次视觉流程或直接手动触发发送。网络调试助手的接收区就会弹出类似于“[2024-01-01 10:00:00] $DETOK;X12.34;Y56.78”的字符串这说明相机到电脑的链路通了。第三步验证反向通讯。在网络调试助手里作为TCP Server双击连接列表里的相机在下方的“发送”区域输入“$TRIG\r\n”点击发送。切回In-Sight Explorer观察TCP服务器工具的接收区是否收到了这串数据。如果能在单元格里看到“$TRIG”说明电脑到相机的链路也通了。两边都通双向TCP/IP通讯就建立成功了剩下的就是格式解析和业务逻辑的活。4.3 报文设计心得字段分隔符与数据类型转换调试中最容易出问题的就是数据类型转换。TCP只认字节你发送的“12.34”本质上是ASCII字符PLC收到后要做字符串转浮点数的处理才能参与计算。反过来PLC发给相机的数据可能是整数或实数相机侧接收后也要转回字符串再做拆分。所以我的建议是能发字符串就发字符串不要发二进制浮点。字符串可读性好抓包一眼能看出对错PLC侧SCL或梯形图里有现成的字符串转数值指令比如西门子的STRG_VAL、三菱的串口转换功能解析起来轻松很多。如果追求传输效率或者数据量特别大可以考虑二进制但调试成本会高不少项目周期不宽裕时不要冒险。5. 常见问题与排查技巧实录5.1 连接不上先从物理层自查“相机连不上”、“数据发不过来”是出现频率最高的问题。我总结了一个排查顺序大家照着做基本能解决八成问题看网口指示灯——网线插上后电脑和相机的网口灯应该亮起或者闪烁不亮就换网线或者查接口氧化ping一下——电脑命令提示符里ping 192.168.1.10相机的IP能通说明链路通不通就检查IP设置和防火墙关防火墙——Windows防火墙经常拦掉非标准端口的TCP连接调试期直接临时全关或者把你用的端口加入放行规则确认端口没被占用——netstat -ano | findstr 10240 命令看一下如果被其他进程占用了换个端口号。5.2 数据能连上但收不到或乱码链接建立成功说明TCP握手没问题故障集中在数据解析层。乱码大概率是编码格式不匹配相机默认用ASCII字符串PLC那边如果用GBK解析或者字节序搞反了显示就会乱。解决办法是统一编码工控环境建议全链路用ASCII中文内容能不用就不用避免编码地狱。收不到完整帧也比较常见。TCP没有消息边界发送方一次发送的内容接收方可能分两包收到也可能两包并一包收到。应对思路很简单接收端按固定帧头帧尾做缓存拼接。我写过无数次的套路是——把接收到的每段数据追加到缓冲区然后搜索帧头位置截取从帧头到帧尾或换行符之间的完整数据帧剩下的留在缓冲区等下一段。IN-Sight的电子表格环境里可以用FIND和MID函数实现同样的逻辑PLC侧就是沿用一个背景数据块做累加和解析。5.3 相机通讯偶发性断线还有一种玄学故障通讯平时好着但产线跑着跑着就断了过一会又自己恢复。这种多半是网络环境不稳定最常见的有两种情况。一种是网线质量差工业环境电磁干扰强普通网线跑百兆跑不了多远就丢包另一种是交换机问题有些现场用的家用宽带路由器长时间高负载运行会死机重启相机和PLC重连就需要时间。解决方向换工业级超五类或六类屏蔽网线摄像头侧和PLC侧都加工业以太网交换机而不是民用路由器如果你的控制器支持把TCP KeepAlive参数打开就是TCP层面的心跳保活机制这样链路假死几分钟后会被系统强制断开并重连避免一直挂着断掉的连接。5.4 发送给PLC的数据触发不了动作数据明明显示了PLC就是不动作这种也让人很抓狂。排查重点在于数据类型和字节顺序。PLC的字符串寄存器通常需要调用指令去解码不能用普通数值比较指令直接比较一个字符串变量。另外西门子PLC的STRING类型自带长度字节头和相机的纯ASCII帧格式有差异所以很多人选择用Modbus TCP或者干脆用S7协议来传而不是用裸TCP自己解析。这里给个实用建议如果PLC侧不想花太多精力做字符串解析可以给相机配一个“双格式输出”既能发ASCII字符串给MES看也能发Modbus TCP写PLC的保持寄存器。这样各取所需但实现难度会上升适合项目预算充裕、调试时间充足的情况。6. 从调试助手到真实产线一个完整的通讯方案实例6.1 实际场景描述前面讲了太多零散的操作最后用一个真实场景把整个流程串一遍。假定现场有台IN-Sight相机做产品定位检测检测结果需要送给西门子S7-1200 PLCPLC根据结果决定气缸是否动作。同时PLC在接近传感器触发时送给相机一个拍照指令和当前产品型号ID。整体通讯架构是这样的相机作为TCP服务器监听端口10240等着PLC作为客户端连上来PLC通过以太网模块主动连接相机后发送“$SHOT;MODEL2\r\n”指令相机收到后执行对应型号的检测流程检测完成后相机通过同一个TCP连接发送“$RES;OK;X10.0;Y20.0;R90.2\r\n”给PLC。为什么用同一条连接因为TCP Server可以同时接收和发送PLC连上一次后保持长连接省去反复握手的时间。6.2 相机侧的具体配置清单相机IP设为192.168.1.10子网掩码255.255.255.0。TCP Server工具的端口设为10240。接收数据设置以换行符作为帧结束标志收到的数据存到单元格$RecvBuf。确认收到完整指令的方法是判断字符串末尾是否包含“\r\n”然后用FIND($SHOT, $RecvBuf)做关键词匹配。发送检测结果的TCP Client工具或者用TCP Server的发送属性在流程最后执行数据源是$ResultStr数据格式是$RES;OK;X10.0;Y20.0;R90.2\r\n字段位置用分号固定好头两位$RES是帧头标记第三位OK是结果后续按约定顺序排坐标和角度。PLC端用FIND和MID依次提取各字段转成REAL类型参与逻辑判断。6.3 PLC侧配合的要点PLC侧的S7-1200用TCON、TSEND、TRCV这三个指令配合做TCP通讯这仨指令在博途的“通信 - 开放式用户通信”里能找到。TCON建立连接时要把伙伴地址设成192.168.1.10:10240注意PLC侧需要本地端口比如15000。连接ID和连接数据块要建好否则TCON报错。收发数据都建议用Buffer收发缓冲区单独建。TRCV接收到的数据放在数组里然后通过循环找帧头$RES找到后再定位分号坐标。注意在PLC侧做接收使能时要常通很多新手只使能一次、接收完就关掉了这样后面数据就进不来了。正确做法是TRCV的数据参数一直传入相同的接收缓冲区有新数据会自动覆盖解析。6.4 联调期间的注意事项联调时最忌讳一上来就跑全流程。我习惯分三步走第一步相机上和网络调试助手连通确认相机发的数据格式正确第二步用网络调试助手模拟PLC作为TCP Client连接相机发指令收回复确认相机逻辑无误第三步关闭调试助手把PLC作为真正的客户端连上来验证PLC的TCON连接和TRCV收发是否稳定。这样每一步都有明确的验证标准和排错边界出了问题能快速定位在哪个环节。7. 最后分享两个提升效率的小经验第一个经验用网络调试助手做“回环测试”。自检方法很简单——在网络调试助手里同时开两个TCP Client都连到相机的Server端口一个发指令一个收数据。如果相机不管收到哪个客户端的数据都会同时广播回复给所有已连接客户端那调试时用两个客户端窗口一发一收你就能直观看到相机数据广播逻辑对不对。缺点是外部设备如果只认一对一连接会收到多余数据所以这个测试仅限联调阶段用。第二个经验通讯异常时花十分钟抓一次包胜过瞎猜两小时。Wireshark抓包的时序能清楚看到TCP三次握手是否成功、数据包有没有重传、应用层报文的真实内容是什么。不用懂太多底层知识用“Follow TCP Stream”功能直接看下发双方的原始数据流就足以定位九成以上的通讯问题。家里备一个USB转网口的适配器解决笔记本网口不够用的尴尬现场调试更从容。做工业通讯这行最重要的是把基础原理弄扎实再通过工具去验证自己的理解。TCP/IP双向通讯说白了就是“谁监听、谁连接、发什么都协议、收到怎么解”这四个问题。把这四个问题在IN-Sight调试环境里各解决一遍以后再接到新的摄像头、新的PLC照样能稳稳地连起来。这篇内容里面的操作细节和坑点都是在实际项目里一条一条蹚出来的希望对正在搞视觉通讯的朋友有些帮助。
