简介《FANUC机器人与康耐视智能相机Socket标准通信协议介绍》面向工业机器人视觉集成、自动化调试及设备通信开发人员梳理FANUC机器人基于TCP/IP的套接字通信方法。内容围绕用户套接字消息功能及北美特定机型所需的KAREL软件展开说明机器人作为客户端或服务器端的连接方式并介绍发送、接收函数在二维抓取、合格判定、字符识别读码和测量输出中的使用。文档归纳位置坐标、合格信号、字符识别读码字符串、测量结果四类数据格式强调逗号分隔、回车结束及寄存器存放规则便于理解视觉数据如何写入机器人寄存器。资源包为1个PDF文件约695KB篇幅精炼便于随查随用。已有7390人学习适合作为视觉通讯配置、数据解析与现场排错的技术参考。1. Socket 通信机器人为什么要把自己降级成客户端或服务器一条网线两端都是控制柜中间跑的协议既不是 Modbus也不是 EtherNet/IP而是最原始的 TCP Socket——这件事本身就值得琢磨。工业现场明明有一堆现成的总线协议为什么要退回到「自己拼字符串、用逗号分隔、回车结尾」这种看起来像上世纪的做法因为视觉系统的输出本质上是不定长、不定结构的结果集可能是一个坐标可能是一串 OCR 字符可能是二十个测量值标准总线的固定映射表很难表达这种弹性而 Socket 把解释权交回给了写机器人程序的人。理解这套机制你就理解了工业现场最朴素也最顽强的一层胶水逻辑。这套通信的基础能力来自 FANUC 机器人侧的 User Socket MsgR648选项它把 TCP/IP 的 connect、send、recv 这一层原语暴露给了机器人程序部分区域标准机型还需要额外的 KARELR632支持才能真正落地。相机侧则是 In-Sight 软件提供的主机通信接口。真正关键的认知点在于通信双方没有主从概念机器人可以当客户端也可以当服务器端角色由现场的网络拓扑和谁的启动时机更可控来决定。这个自由度是优点也是绝大多数现场翻车的起点。2. 角色选择客户端与服务端到底该谁先开口2.1 两种角色的本质差异不在数据方向而在谁承担重连责任很多人以为「机器人当客户端」和「机器人当服务器端」只是主动连接与被动监听的区别实际影响远不止于此。TCP 的连接是有状态的断线之后必须有人负责重建。如果机器人是客户端重连逻辑写在机器人程序里机器人会在发送失败或检测到连接断开后重新发起 connect如果机器人是服务器端它必须先 bind 并 listen然后等相机来连此时相机侧的重连策略就成了决定系统恢复速度的关键。现场常见的做法是把机器人设成客户端理由很实在机器人程序是循环执行的可以在主循环里塞一段连接检查而智能相机的作业Job触发逻辑更偏向事件驱动一旦连接断开恢复动作不如循环程序来得自然。但这不是铁律如果产线里有多台相机要连同一台机器人让机器人做服务器端反而更省事——一个监听端口多个客户端接入逐个 recv逻辑更线性。2.2 端口与连接参数在两侧必须镜像对齐不管谁当客户端有一组参数必须在两侧完全一致否则连接会静默失败或者连上后立刻被对端复位。这类参数没有玄学但漏一个就够你排查半天。参数机器人侧相机侧不对齐的典型表现端口号Socket 打开时指定主机通信端口设置connect 直接超时无任何日志IP 地址对端相机 IP对端机器人 IPping 通但连接被拒连接角色Client / Server对应反向双方都在 listen永远连不上结束符CR (0x0D)行结束符设为 CR数据粘包一次 recv 读到两帧超时打开时的 timeout 值通信超时偶发接收空字符串提示端口号这一步最容易出错的地方不是填错而是填对了但被现场另一套系统占用。上线前用一台笔记本先对着相机端口做一次连接测试比在机器人示教器上盲试高效得多。2.3 连接建立时序决定了程序的第一行该写什么时序这件事在文档里往往一句话带过但在实际调试中是第一个拦路虎。相机的 In-Sight 作业启动、网络服务就绪、机器人程序启动这三件事没有天然的顺序保证。如果机器人上电就跑 connect而相机还在自检你会得到一个「连接被拒绝」而这个错误在机器人侧看起来和「IP 填错了」几乎一样。稳妥的处理方式是在机器人程序里加一个带重试的连接循环而不是一次性 connect 后就不管。重试间隔不需要太短一两秒一次足够重要的是要有次数上限和明确的失败分支避免程序卡死在建立连接这一步而在现场表现为「机器人不动了」。; 伪代码带重试的连接建立逻辑 retry 0 WHILE retry 10 DO status SOCKET_CONNECT(ip_camera, port, timeout_ms) IF status success THEN connected TRUE EXIT ENDIF WAIT 1.0 sec ; 给相机侧服务就绪留出时间窗 retry retry 1 ENDWHILE IF NOT connected THEN ; 走到这里说明不是时序问题回头查端口和网段 CALL alarm_handler(conn_fail) ENDIF这段逻辑里timeout_ms决定了单次 connect 愿意等多久通常不需要设得太长因为 TCP 三次握手在局域网内是毫秒级的等太久往往意味着对端根本没在监听真正的等待价值在WAIT那一行的重试间隔上。retry上限的存在是为了让故障显性化——一个永远在重试的连接循环在现场就是一台永远不报警也不干活的机器人这比直接报错更难查。3. 四种数据格式为什么用逗号加回车这种「土办法」3.1 定界符协议的设计动机让解析逻辑可以被现场工程师读懂四种数据格式共用同一套语法规则字段之间用逗号分隔一帧数据以 CR回车0x0D结束。这个设计的精妙之处在于它的可调试性——任何一个现场工程师拿一个串口助手或者网络调试工具就能直接把相机发出来的字节流看懂不需要协议描述文件不需要解析工具。对比一下二进制协议同样一帧数据你得对着字节序和偏移量表逐个字段抠。代价当然也有。字符串解析比二进制解析慢而且对格式异常极其敏感多一个逗号、少一个回车解析就会全盘错位。这实际上是一种取舍——牺牲吞吐和健壮性换取透明度和可维护性。在一个视觉检测节拍通常在几百毫秒量级的场景里这点解析开销完全可以接受而透明度的收益是长期的。3.2 位置坐标格式四字段一组与位置寄存器的覆盖语义第一种数据是位置坐标用于 2D 视觉抓取这类场景。每组数据包含四个字段Model ID 加 X、Y、R 三个分量最多一次接收 8 组存放在机器人的位置寄存器中。这里有个非常容易被误解的机制位置寄存器的数据是「被更新」而不是「被追加」。也就是说相机把多组坐标一次性发过来机器人侧调用一次接收函数寄存器里的内容会被这批发来的数据覆盖。如果一次发 3 组寄存器相应位置被填上这 3 组下一次调用如果相机发来 5 组前面几组会被新的数据盖掉。文档里那句「同时接收多组数据每调用一次位置寄存器数据将被更新直到全部数据更新完成后再次重新获取数据」说的就是这个覆盖语义。理解这一点才能避免写出「上一帧的残留坐标被当成新目标」这种隐蔽 bug。典型的做法是每轮抓取前先清零相关寄存器或者用一个序号字段自校验确认本轮数据确实是新到的。字段位置含义取值说明1Model ID视觉作业中定义的模型编号2X像素或标定后的物理坐标3Y同上4R旋转角度结束CR0x0D3.3 Pass/Fail 信号一位信息为什么要占用一次通信往返第二种格式是 Pass/Fail 检测结果每次调用只接收一个信号值只能是 1 或 0存放在数字寄存器里。看起来极不划算——为了一个布尔值走一次完整的 TCP 往返。但这是工业检测里最高频的场景判断工件合格与否然后机器人决定是放行还是剔除。不划算的感觉来自对通信成本的误判。在局域网内一次 recv 的往返在毫秒级相对于机械臂运动的时间尺度几乎可以忽略。真正需要考虑的是这次通信有没有明确的结束标志。有 CR 作为帧结束符就意味着即使 TCP 层把两次发送合并成一个报文接收端也能靠定界符正确切分。这就是为什么简单的布尔值也值得配一套完整帧格式——一致性比省字节重要。3.4 OCR 与读码结果20 字符上限背后的寄存器约束第三种是字符串结果用于 OCR 字符识别或读码。每次接收一个字符串长度必须小于 20 个字符存放在字符串寄存器中。这个 20 的限制不是协议随意规定的而是机器人字符串寄存器本身的容量约束。这条约束在实际项目里会真真切切地咬人二维码内容稍微长一点就容易超限。处理方式有两种一是在相机侧就把内容截断或只发关键字段二是在机器人侧接收前先做长度校验超长直接判为无效并触发重读。后者的好处是故障可见不会出现「读到半截码还当作有效」的情况。; 伪代码带长度校验的字符串接收 SOCKET_RECV(raw_buf, timeout_ms) frame SPLIT_BY_CR(raw_buf) ; 按 CR 切出完整帧 IF LEN(frame) 20 THEN ; 超长说明相机侧内容越界直接判无效 read_ok FALSE CALL log_warn(ocr_len_overflow) ELSE str_register frame ; 写入字符串寄存器 read_ok TRUE ENDIFSPLIT_BY_CR这一步不能省因为一次 recv 拿到的可能是半帧也可能是两帧粘在一起。只有在确认拿到以 CR 结尾的完整帧之后长度校验才有意义。而长度校验放在写入寄存器之前是为了防止超长内容把寄存器写坏——这个操作在部分实现里会产生不可预期的截断。3.5 测量结果最多 20 个数字寄存器的顺序写入第四种是测量结果输出最多 20 个数据同时发送依次存放在数字寄存器中。这里的机制要点是「依次」第 1 个数据进第一个寄存器第 2 个进第二个位置即含义。这意味着相机侧发送顺序和机器人侧读取顺序必须严格对应中间任何一方调整了字段顺序读到的就是张冠李戴的值。这种位置绑定还有个副作用空字段的处理。如果某个测量项本次没有有效值相机应该发一个占位值还是干脆不发发占位值会让字段数保持稳定读取逻辑简单不发则会导致后续字段整体前移全部错位。绝大多数现场选择前者哪怕占位值需要一个约定好的无效标记。3.6 统一的帧结构逗号分隔加 CR 结尾如何保证不粘包把四种格式放在一起看会发现它们共享同一条语法主干字段逗号分隔帧 CR 结尾。这条规则解决的核心问题就是粘包。TCP 是字节流协议没有消息边界如果发送方连续发两帧接收方完全可能一次读到两帧拼在一起的内容。有了 CR 作为帧结束符接收端就有了切分依据缓冲区里攒字节每遇到一个 CR 就切出一帧交给解析逻辑剩下的留在缓冲区等下一次。这个机制的实现细节在于缓冲区必须能在多次 recv 之间保持状态不能每次 recv 都清空——一旦清空跨包的半帧就丢了。; 伪代码累积缓冲区 CR 切帧 buffer buffer recv_bytes ; 追加不清空 LOOP idx FIND_CHAR(buffer, CR) IF idx 0 THEN EXIT LOOP ENDIF ; 没找到完整帧等下一次 frame SUBSTR(buffer, 0, idx) ; 切出一帧 buffer SUBSTR(buffer, idx 1, END) ; 剩余部分保留 CALL parse_frame(frame) ENDLOOPbuffer的生命周期必须跨越多次 recv这是整个解析逻辑的根。FIND_CHAR找的是第一个 CR 的位置SUBSTR切完之后剩余部分写回buffer等待与后续字节拼接。这套逻辑写对了粘包和半包问题就同时消失了。写错的地方通常是把 buffer 定义在循环内部每次 recv 都重新初始化结果就是帧边界永远对不上。4. 现场排查Socket 通信最常见的几类翻车4.1 现象连接能建立但每次接收都是空字符串原因通常不是通信断了而是帧结构没对上。相机侧可能用了 LF0x0A作为行结束符而机器人侧在等 CR0x0D找帧结束符的逻辑一直找不到缓冲区越攒越多但一帧都切不出来。解决方式是把两侧的结束符设置逐字对齐用抓包或者日志把实际收发的字节打出来看一眼比对着配置项猜快得多。这类问题的血泪经验是永远不要假设「回车」这个词在两侧指同一个字节。4.2 现象坐标数据偶发错位抓取位置飘忽原因往往出在位置寄存器的覆盖语义上。上一轮的残留数据没有清掉本轮相机只发了部分组未更新的寄存器仍保留旧值机器人程序却按全部有效去读于是抓到了上一轮的目标。解决方式是在每轮接收前显式清零相关寄存器或者用一个自增序号字段配合校验确认本轮数据完整到达后才允许使用。这个坑的隐蔽性在于它只在「本轮数据组数少于上轮」时才暴露正常节拍下可能几百个循环都不出现。4.3 现象机器人程序卡在接收函数里不返回原因通常是阻塞式接收等一个永远不会来的帧。相机侧作业没有被触发或者触发条件不满足于是什么都不发机器人侧的 recv 就一直等。解决方式是给接收调用设置明确的超时超时后走异常分支而不是继续等。同时要检查相机侧作业的触发源——是外部 IO 触发、还是定时触发、还是由机器人先发一条触发指令再等结果。如果是最后一种那么发送和接收的顺序就必须严格配对漏发一次之后就永远对不上。4.4 现象通信正常跑了几小时后突然断开重启才恢复原因是双方都没有做连接保活链路上的中间设备把空闲连接回收了。表现在机器人侧就是某个时刻 recv 返回错误或者零字节。解决方式是在应用层加心跳即使没有业务数据也定期收发一个最小帧或者至少在检测到断开后能自动重连而不是等人来按复位。这里有个取舍心跳太频繁浪费资源太稀疏则发现断线太晚一般按业务节拍的几倍来定间隔比较合理。4.5 现象改了相机侧的字段顺序机器人读到的值全乱原因是测量结果这类数据是位置绑定语义第 N 个字段固定进第 N 个寄存器。相机侧调整了发送顺序机器人侧的解析映射没有同步改读出来的就是错位的值。解决方式是给帧结构建立一份双方共同维护的字段定义任何一侧改动都要同步评审。更稳妥的做法是在帧头带一个版本号字段机器人侧读到不认识的版本直接报警而不是闷头解析。5. 设计取舍为什么这套「原始」协议在工业现场活得很好回到最开始那个问题。用逗号分隔、CR 结尾理论上不如二进制紧凑不如 XML/JSON 结构化不如现成的工业总线省心。但它活下来了而且活得很好原因值得拆开看。第一是可观测性。现场调试时最贵的成本不是写代码而是定位问题。一个工程师拿着网络工具看到1,120.5,88.3,0.0\r这样的字节流两秒钟就能判断数据对不对。换成二进制协议同样的判断需要协议文档、偏移表、字节序知识调试时间可能翻十倍。工业现场的设备生命周期以十年计可观测性的复利远超一时的效率优势。第二是耦合度低。这套协议不要求双方共享类型定义、不要求版本协商、不要求中间件。相机换个型号只要还能发逗号分隔的字符串机器人侧一行代码都不用改。这种松耦合在设备频繁更替的产线里是实打实的优势。代价是类型安全全部靠约定维持第五节的错位问题就是这种松散的直接后果。第三是失败模式清晰。帧不完整就是不完整超长就是超长超时就是超时每一种异常都有明确的对应分支。相比之下某些带自动重传和自动恢复的协议故障时表现为「慢」而不是「错」反而更难定位。这套协议把所有的重连、保活、超时责任都推给应用层逼着写程序的人显式处理每一种情况——这其实是把复杂度放在了正确的位置。第四也是最容易被忽略的一点它把时序控制权交给了工艺。机器人什么时候发、什么时候收、收几组、等多久全部由机器人程序决定而机器人程序正是和节拍、夹具、上下游信号绑定最紧密的地方。视觉系统只是被动响应。这种设计让通信逻辑天然嵌入了生产节拍而不是漂在外面自成一套。要说验证方法其实很简单拿一个抓包工具挂在两端之间把一整轮完整交互的字节流录下来然后逐帧对着字段定义核一遍。我一般会在项目交付前做这件事不是为了找 bug而是为了确认自己对帧结构的理解和实际跑出来的东西一致。有一次就是这么发现了相机侧在数据末尾多补了一个空格肉眼看不出来解析时却让最后一个数字变成非法值。从那以后我每次接手这类 Socket 对接都强制走一遍「抓包—对帧—写文档」的流程把实际字节流和字段定义贴在一起存档。后来的人接手时不用再去猜某个逗号后面到底该有几个字段。这份资源里对四种数据格式、寄存器语义和函数调用的拆解正好可以当作这样一份对照底稿把协议层和实现层的对应关系一次理清省掉大量现场试错。希望帮到你。本文还有配套的精品资源点击获取
