简介面向FANUC机器人集成、自动化产线调试与视觉应用工程师压缩包内仅含一份PDF系统梳理FANUC机器人与康耐视智能相机基于TCP/IP的Socket标准通信协议重点解答机器人作为客户端或服务器端时如何建立连接、收发数据并切换通信角色从而为产线自动化提供可靠的数据交互方案。文档从软硬件前提讲起明确机器人侧需具备User Socket MsgR648功能FRA/FAC北美标准机型还需安装KARELR632并配合康耐视In-Sight软件及控制柜间网线完成硬件部署协议实现部分围绕DATA_SEND与DATA_RECV两个核心函数覆盖2D视觉抓取、Pass/Fail检测、OCR字符识别/读码及测量结果输出等现场高频场景便于在实际项目中直接参考落地。数据格式部分按位置坐标Model IDXYR最多8组、Pass/Fail信号、OCR/读码字符串20字符以内与测量数据最多20个四类展开统一采用逗号分隔并以回车结束分别存入位置寄存器、数字寄存器与字符串寄存器便于读者直接对照报文结构调试程序。整包约695KB已有7383人学习适合需要快速掌握通信协议要点与数据格式的自动化工程师参考。1. Socket是视觉引导机器人最常用的数据通道这套协议在解决什么问题产线上做视觉引导抓取最常搭起来的组合就是FANUC机器人配康耐视智能相机相机负责拍照、定位、算出坐标机器人负责把坐标变成实际动作。两个设备之间的数据通道怎么搭是每次集成都要面对的问题。用硬接线I/O只能传合格/不合格这类开关量位置数据根本传不过去用Socket通信检测结果像一封信一样整体打包一次就能带走X坐标、Y坐标、角度和OK/NG状态。这是FANUC机器人与康耐视智能相机Socket通信要解决的核心问题也是当前视觉引导项目里最主流、最值得吃透的集成方式。下面按一线调试的顺序把角色怎么分、报文怎么定、两端怎么配、联调阶段容易在哪翻车一次讲清楚适合正在做视觉引导抓取、上下料分拣和质量检测集成的工程师参考。2. 谁做服务器谁做客户端通信架构与报文格式先定明白Socket通信里一个等、一个连分工不同后面所有程序的写法都不同。FANUC和康耐视配合的常见做法是康耐视相机做TCP服务器开机后持续监听固定端口FANUC机器人做TCP客户端程序流程走到拍照位时主动发起连接。机器人掌握生产节拍由它决定“什么时候该拍照”相机只需要被动响应这样架构最简单、调试最直接。2.1 为什么默认让相机做服务器角色分配的三个依据第一个依据是流程主导权。抓取节拍由机器人控制机器人到点停下、请求视觉数据这个动作由客户端发起最自然。反过来让相机做客户端主动推送机器人就要在后台开一个常驻监听任务TP程序多出一个并行分支复杂度和出错面都会增加。第二个依据是故障恢复。产线设备频繁断电重启相机做服务器开机就监听机器人做客户端程序跑到连接指令时自然重连。相机做客户端时就要在Job里单独维护重连逻辑而且相机端的调试手段远不如示教器丰富出了故障很难看清是重连失败还是发送间隔问题。第三个依据是资源占用。相机跑视觉算法已经很吃CPU被动监听的开销比主动连接小得多让相机不断尝试连接、处理失败重试会直接影响检测周期。当然也有例外。如果现场是多台机器人共享一台相机的检测结果那相机只能做服务器每台机器人作为独立客户端来连接。一对多模式下要重新设计端口分配和并发连接数相机侧要能支持多个客户端同时接入此时“谁来主导”这个结论就不适用了。遇到这种场景建议在协议里再加一个客户端ID字段让相机能区分每一帧结果该发给谁。2.2 报文格式二进制帧还是文本帧先选一个能落地的Socket只是传输通道真正容易扯皮的是报文怎么编排。常见的标准协议做法是约定一个固定帧结构让接收方不用猜。我常用的设计是字段长度说明帧头2字节固定0xAA 0x55接收方靠它识别帧起始位置命令字1字节0x01机器人请求拍照0x02相机返回结果0x03心跳应答数据长度2字节数据体字节数大端表示数据体N字节具体业务数据校验1字节从帧头到数据体的累加和取低8位这个结构的好处是长度字段告诉接收方这一帧有多长校验字段能拦住大多数传输错误。数据体里放什么要按业务约定。以视觉引导抓取为例相机返回的数据体通常是1个字节检测状态1表示OK0表示NG4个字节X坐标IEEE 754浮点数单位毫米4个字节Y坐标4个字节旋转角单位度范围[-180,180]。一共13个字节机器人端按固定偏移读取即可。不过第一次联调我建议不要直接上二进制帧。先用纯文本报文把链路跑通比如机器人发TRIGGER\n相机回OK,X100.50,Y200.25,R45.00\n。文本肉眼可见哪一端出问题一眼就能看出来。等链路稳定后对传输效率有要求再切二进制。文本报文解析也简单按逗号和等号拆分字符串就行很多成熟项目的通信协议其实就是这种类CSV格式配合换行符做帧结束标志比二进制帧好维护得多。还有一个容易忽略的约定是字节序。如果采用二进制帧X坐标4个字节是大端还是小端必须在协议里写明。不同相机固件版本对浮点数的字节序处理不完全一致联调前先用PC模拟器发一帧已知数值的数据确认解析正确再上产线。2.3 一次通信的完整生命周期连接→握手→请求→应答把一次完整通信拆成四个阶段联调时按顺序排查会省很多时间。连接建立机器人到拍照位触发TCPCONNECT指定相机IP和端口相机accept后进入已连接状态。握手确认机器人发握手命令字相机回固定应答收到应答才认为链路可用现场有多台相机时这一步尤其有用能防止“连上了但对面不是目标相机”。数据交互机器人发触发拍照命令相机拍照、处理图像把结果按约定格式返回。这里要注意机器人发送后应该进入接收等待状态不能立即往下走否则容易漏帧。连接保持视觉引导场景一次拍照周期通常只有几十到几百毫秒建议保持连接不关闭下次拍照直接复用。频繁断开重连一方面增加时间开销另一方面端口容易进入TIME_WAIT状态重连时报地址已被占用。超时参数也在设计阶段定好机器人发触发命令后接收等待超时建议1到3秒。视觉检测一般不会超过1秒超时太短在相机偶发慢一拍时会误报太长又会拖停产线。这套流程就是Socket标准通信的核心骨架后面两端配置都是按这个骨架展开的。3. 两端配置实战康耐视相机与FANUC机器人把协议跑起来理论定了就动手。这一章按相机端、机器人端、联调前自检三步走。前提是两端都能单独工作相机能正常拍照并输出结果机器人能正常走完自己的动作流程。3.1 康耐视相机端开Socket服务器按协议发结果康耐视智能相机的配置在In-Sight Explorer里完成有电子表格和EasyBuilder两种模式。做Socket通信我习惯在电子表格模式里操作每一步都能看到单元格的计算结果方便确认输出内容拼对没有。关键步骤有三步第一步固定相机IP。在网络设置里把相机设为静态地址和机器人控制器保持在同一个网段。很多联调问题都出在IP不在同一网段看起来网络通机器人就是连不上。第二步开放Socket监听端口。在通信设置里启用TCP服务指定一个未被占用的端口比如5000。康耐视相机默认开放很多服务端口建议自定义端口避开默认服务避免和调试工具冲突。第三步在电子表格里组织发送内容。检测完成后把结果拼成约定格式的字符串用Socket发送动作输出。输出字段大致如下输出字段取值示例说明检测状态OK / NG由检测逻辑生成X坐标100.50定位结果格式化为两位小数Y坐标200.25同上角度45.00旋转角确认单位是度还是弧度拼接示例OK,X100.50,Y200.25,R45.00\n末尾换行符是关键机器人端把它当一帧结束标志。这里有个容易忽略的点电子表格里数值默认可能输出成科学计数法拼接前要显式调用格式化函数固定小数位否则像1.0050e02这种结果机器人端按字符串解析会直接翻车。3.2 FANUC机器人端TP程序里的Socket指令与解析逻辑机器人端主要在示教器上操作FANUC的Socket通信是一组独立TP指令前提是控制器开通了TCP/IP通信选项。如果示教器指令列表里找不到TCPCONNECT先确认选项是否注册这是最容易卡住的第一步。另外FANUC不同系统版本对主机地址的写法有差异有些版本要求先在主机通信设置里定义一个主机条目把相机IP和端口填进去程序里引用主机编号有些版本允许直接在指令里写IP字符串。执行前先在示教器的程序编辑界面看一下指令语法提示以系统提示的格式为准省得因为版本差异浪费一个下午。一段最简TP程序如下!---- 固定连接参数 ---- R[1:ConnID]1 R[2:Timeout]3000 !---- 建立TCP连接 ---- TCPCONNECT R[1], 192.168.1.100, 5000 TCPWAIT R[1] !---- 发送触发命令 ---- TCPSEND R[1], TRIGGER\n !---- 等待并接收相机结果 ---- TCPRECV R[1], S[10], 11 !---- 单次通信模式关闭连接 ---- TCPCLOSE R[1]代码说明R[1]是连接ID同一时刻有多条连接时用ID区分TCPCONNECT第二个参数是相机IP地址字符串第三个是端口号TCPWAIT阻塞等待连接完成TCPSEND发送的触发命令必须和相机端约定完全一致大小写和换行符都不能错TCPRECV把数据存到字符串寄存器S[10]第三个参数是最大接收字节数。这里设置的11是返回报文OK,X100.50...去掉换行符后的长度实际使用时要根据相机端输出报文的最大长度来调整。跑通后再改连接保持模式把TCPCONNECT和TCPWAIT放到主程序开头拍照循环里只做TCPSEND和TCPRECVTCPCLOSE放到程序结束或异常分支。解析结果时TP程序对字符串处理能力有限常见做法是先用字符串寄存器保存报文用比较函数判断OK/NG坐标要转成数值寄存器用字符串截取函数取子串再转换成NUMREG才能参与位置修正。TCPRECV的接收缓冲长度必须不小于相机返回报文的最大长度。设短了数据被截断设长了如果相机一次发多帧会把下一帧内容并进来造成解析错位。最稳的是按文本帧的固定最大长度接收再校验末尾换行符。3.3 联调前的最小自检用PC模拟相机端验证机器人程序在机器人和相机联调之前强烈建议先用PC模拟相机端。原因很简单链路不通时两边都会说是对方的问题先用PC把机器人测一遍变量范围就缩小了。一段简单的Python脚本就能实现import socket HOST 0.0.0.0 PORT 5000 server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((HOST, PORT)) server.listen(1) print(f模拟相机监听 {PORT} 端口等待机器人连接...) conn, addr server.accept() print(f机器人已接入地址: {addr}) while True: data conn.recv(1024) if not data: print(连接关闭) break print(f收到触发: {data!r}) # 模拟相机返回一帧检测结果 response bOK,X100.50,Y200.25,R45.00\n conn.send(response) conn.close() server.close()代码逻辑很简单PC监听5000端口收到机器人发来的任何数据后回一行固定检测结果。SO_REUSEADDR让程序关闭后端口能立即重新绑定频繁调试时不用等TIME_WAIT超时。用它联调的步骤是先启动脚本再在示教器上单步运行机器人程序观察脚本窗口是否打印触发内容、机器人端是否收到应答。注意机器人TCPCONNECT里IP要临时改成PC的IP联调通过后改回相机IP。这个自检能提前暴露两类问题机器人Socket指令语法和参数顺序是否正确触发命令文本是否和约定一致。真机联调时就只需要聚焦在相机端输出格式上。4. Socket联调避坑指南四类高频故障的现象、原因与处理先说一个原则Socket通信故障90%不是协议不对而是配置细节不一致。IP、端口、报文格式、超时时间有一处和对面不一致现象就很随机。下面四条是从项目里反复遇到、也最值得记录的。排查Socket问题前我习惯先备好三样东西示教器上的报警历史记录确认故障发生时的指令和错误代码PC端的抓包工具在实验室模拟环境里把现场参数搬过来看数据到底有没有到网线上一段能稳定复现故障的最小测试程序不要带着整个生产流程去排查把通信单独拉出来测。这三样比任何经验都管用。4.1 现象能连上但机器人端收不到完整数据现象TCPCONNECT成功触发命令发出去了但TCPRECV超时或收到的数据只有一半末尾换行符没过来。原因最常见两个。一是报文太长超出TCPRECV最大接收长度二是相机端发送后立刻关闭连接或机器人接收时机不对数据还在系统缓冲区里机器人已经超时退出。解决把TCPRECV最大接收字节数设为相机报文的实际最大长度加4个字节余量在TCPSEND后加一个等待条件或把超时放宽到3秒再TCPRECV。相机端检查Socket发送是否配置了延迟关闭有些固件版本在发送后立即关闭Socket需要在Job里加200毫秒保持延时再断开。这个坑的特征很典型第一次触发能收到数据第二次开始就不稳定因为第一次连接建立后相机立即断开机器人端还没反应过来。4.2 现象机器人报TCP超时错误程序卡在TCPWAIT或TCPRECV现象示教器弹出通信超时报警程序停在TCPWAIT或TCPRECV按复位消不掉只能重启程序。原因TCPWAIT超时常见于目标IP不可达或端口没监听。TCPRECV超时则复杂些相机收到触发命令但图像处理时间超过了接收等待时间或者相机还在处理上一张图来不及响应当前请求。解决分两类排查。TCPWAIT超时先ping相机IPping通了再看端口有没有监听可以在PC上用端口连通性工具测相机的5000端口。TCPRECV超时把超时参数调到3到5秒同时优化相机端流程让Socket发送紧跟图像处理完成之后不要在多个单元格里跳来跳去。还有一种隐蔽情况机器人后台任务和前台任务同时操作同一个连接ID前台TCPRECV的数据被后台任务抢走。排查时检查所有任务里是否重复使用连接ID。4.3 现象数据能收到但解析出来乱码或坐标明显不对现象机器人端收到的字符串肉眼看着正常转成数值后坐标偏移几百毫米或者直接是一串不可读字符。原因字符集不匹配和字节序问题。相机端如果输出UTF-8带BOM机器人按ASCII解析就会带进额外字符。真正容易踩的是二进制场景浮点数字节序没对齐相机按小端输出接收端按大端解析4个字节读出来就是不合理的值。解决文本模式统一用ASCII或无BOM的UTF-8。二进制模式严格按约定解析字节序并在解析时加合理性判断坐标如果是毫米正常范围不会超过-2000到2000超出就丢弃并记录日志。另外很多工程师把数据寄存器当数组用接收入口定义不对造成数据错位这种问题在示教器上很难发现建议在PC模拟器阶段把二进制解析逻辑完整测一遍不要等上了产线再查。真机联调时可以先让相机拍一张固定在已知位置的工件对比返回坐标和实际示教坐标差在1毫米内才算通过。4.4 现象设备重启后通信不自动恢复现象机器人或相机断电重启后程序启动时TCPCONNECT失败或者连接保持模式下机器人直接报警“连接不存在”必须手动重启程序。原因连接保持模式的通病。程序重启但相机端不知道旧连接已断开更常见的是机器人侧TCPCLOSE没执行连接还挂在系统里再次TCPCONNECT时系统认为连接ID仍被占用。解决程序启动时先做清理动作对已知连接ID执行TCPCLOSE并忽略错误再重新TCPCONNECT。机器人断电重启后相机端要配置成检测到断开后自动释放Socket一般体现在一个Socket空闲超时时间上比如300秒没有数据就关闭连接。机器人主程序里加通信失败重试逻辑TCPCONNECT失败后延时2秒重试连续重试5次仍失败再报警停机避免偶发网络抖动把整条产线停掉。这个策略在自动化产线上几乎是必备的没有重试逻辑的通信程序早晚会在某个深夜把产线停住。5. 进阶技巧把Socket通信从“能跑”做到“稳定跑”到这里通信链路基本能跑但要支撑全天候产线运行还需要两个技巧模块化封装和状态自恢复。5.1 把握手、重试和断开做成示教器子程序通信逻辑不需要写KARELTP程序里的Call指令就能完成模块化。把TCPCONNECT、TCPWAIT、握手校验、失败重试放到一个独立TP子程序主程序只保留业务动作。好处是换相机IP、改端口、调超时时间时只改子程序开头参数不用翻主程序业务逻辑。我习惯在子程序里先清理再连接!---- 清理可能残留的连接 ---- TCPCLOSE R[1] !---- 重新建立连接 ---- TCPCONNECT R[1], 192.168.1.100, 5000 TCPWAIT R[1]这个做法依赖TCPCLOSE对不存在的连接不报致命错误所以要把清理动作放在容错区段内或者先判断连接ID是否有效再执行。具体写法跟随系统版本差异调试时用PC模拟器反复断电重连验证逻辑可靠性即可。5.2 心跳包和最后一包日志故障定位的两个黑匣子稳定运行之后偶发故障最难查。我的习惯是加心跳机器人每5秒发一次0x03心跳命令相机收到后回固定应答。连续3次心跳无应答机器人判定通信异常主动断开重连。这样故障发生在拍照间隙也能被及时发现不用等下一次请求才发现链路早断了。另一个动作是记录“最后一包”。机器人端把最近一次发送的触发命令和最近一次接收的报文分别存到两个字符串寄存器出问题时通过示教器直接读取比盲猜“是不是相机没触发”快得多。我在某次抓偏故障排查里就靠它省了几小时所有人都在查视觉标定一看日志相机返回坐标里角度字段偶尔变负是格式化函数在180度附近的精度问题。调试Socket通信最怕凭感觉改参数。把通信过程做成可观测的心跳状态、最后一次收发内容、重连次数都留着产线上有据可查。希望这些经验能帮到你也让你的Socket联调不再全靠猜。本文还有配套的精品资源点击获取
