1. 项目背景与核心需求拆解1.1 为什么会有“400组num型数据”这个需求在汽车零部件冲压车间做产线集成的朋友大概率遇到过这种场景一台ABB机器人负责从压机取件、放到输送线上位机通常是工控机或者PLC侧的一个数据采集服务需要实时记录机器人每个节拍的位置、速度、力矩等工艺参数。一个节拍下来需要采集的数值型变量动辄几十上百个连续跑几个节拍做工艺分析400组num型数据这个量级就出来了。标题里的“400组num型数据”本质上是400个数值型变量的一次性批量传输。注意这里的“组”不是400个字节也不是400个字符串而是400个独立的数值。ABB机器人RAPID语言里的num类型是双精度浮点数一个num占8字节400个num裸数据就是3200字节。如果按字符串拼接发送每个数字平均6到8个字符加分隔符数据量会膨胀到3KB到4KB左右。这个需求的核心矛盾在于机器人控制器的socket通信缓冲区有限而应用层又要求一次性把400个数据完整送达上位机不能丢、不能乱序、不能因为TCP粘包导致解析错位。我见过太多项目在实验室跑得好好的一到现场数据量上来就开始丢包、错位、解析崩溃根子都在这里。1.2 适合哪些人参考这篇内容适合三类人一是做ABB机器人产线集成的电气工程师手头有RAPID编程基础但socket通信写得不多二是上位机软件开发人员需要和ABB机器人做数据对接但不清楚机器人侧的发包逻辑三是自动化专业的学生或者刚转行做工业通信的开发者想找一个完整的、能直接抄作业的案例。我默认你手里有ABB机器人IRC5或OmniCore控制器都行RobotStudio能连上SocketMessaging选项已经装好。如果没有SocketMessaging选项后面的代码你跑不起来这个先确认。1.3 整体方案选型为什么用socket而不是其他方式ABB机器人对外传数据常见的有几种路子一是用Write指令写文件到控制器硬盘上位机再通过FTP去取二是用OPC UAOmniCore原生支持IRC5需要额外选项三是用socket直接发四是通过PLC中转机器人跟PLC走Profinet/EtherNet-IPPLC再跟上位机通信。选socket的理由很直接实时性最好延迟最低不依赖中间设备开发成本可控。写文件的方式有磁盘IO延迟400组数据写一次文件再读一次节拍时间根本扛不住。OPC UA在IRC5上要么不支持要么要加钱买选项而且配置复杂。走PLC中转多一层设备就多一层故障点调试的时候你都不知道是机器人没发对还是PLC没转对。socket的缺点也有TCP是流式协议没有消息边界400组数据发过去上位机可能一次收到200组也可能一次收到600组两次合并这就是经典的粘包问题。所以方案的核心不只是“怎么发”更是“怎么让接收方知道一组数据到哪里结束”。我的做法是自定义一个简单的应用层协议用固定分隔符长度校验的方式解决粘包。具体在第二节展开。2. 核心细节解析与实操要点2.1 RAPID侧socket通信的基本骨架ABB机器人的socket通信靠SocketMessaging选项里的几个指令SocketCreate建套接字SocketConnect连服务端SocketSend发数据SocketReceive收数据SocketClose关闭。机器人通常做客户端Client上位机做服务端Server因为机器人的IP一般固定上位机开监听端口等机器人来连这样机器人重启后自动重连的逻辑好写。一个最小的RAPID socket客户端长这样VAR socketdev clientSocket; VAR string recvData; PROC main() SocketCreate clientSocket; SocketConnect clientSocket, 192.168.1.100, 5000; ! 到这里连接建立 SocketSend clientSocket \Str:hello; SocketClose clientSocket; ENDPROC看起来简单但坑在后面。SocketSend默认发的是字符串你要发num型数据得先转成字符串。RAPID里没有直接的NumToStr函数得用NumToStr或者自己拼。实际上RAPID有NumToStr函数用法是NumToStr(value, decimals)返回一个字符串。2.2 400组num数据怎么组织成一次发送最朴素的做法是循环400次每次SocketSend发一个数字加一个分隔符。但这样有致命问题400次系统调用每次都有网络栈开销而且TCP会把小包合并Nagle算法接收方可能收到一堆粘在一起的数据解析逻辑会疯掉。更好的做法是在RAPID侧先把400个num拼成一个长字符串然后一次SocketSend发出去。RAPID的字符串最大长度是1024个字符IRC5或更大OmniCore400个num如果每个平均7个字符加1个分隔符大约3200字符超过IRC5的1024限制。所以要么分批发要么用SocketSend的\RawBytes参数发二进制。这里有个关键决策点用字符串拼接还是用RawBytes发二进制。字符串拼接的优点是调试方便用串口助手或者网络调试助手直接能看到可读的数字缺点是受字符串长度限制IRC5上400组数据得分4到5次发每次发完要加延时或者等接收方确认否则还是会粘包。RawBytes的优点是数据量精确可控400个num就是3200字节一次发完缺点是接收方得按二进制解析调试的时候看到的是乱码得写专门的解析工具。我的建议是如果控制器是OmniCore字符串长度够优先用字符串拼接分隔符调试效率高如果是IRC5老老实实用RawBytes分批发每批加一个批次头。下面我按IRC5的场景来讲因为IRC5存量最大坑也最多。2.3 自定义应用层协议的设计解决粘包的核心思路是让接收方能够从字节流里准确切分出每一组数据。常见的有三种方案第一种是固定长度。400个num每个num固定用8字节的double表示一组就是3200字节接收方每次读3200字节就切一组。这个方案最简单但要求发送方和接收方对数据格式完全一致而且RAPID里把num转成8字节double需要用到PackRawBytes稍微麻烦一点。第二种是分隔符。每个num后面跟一个特殊字符比如|或者\n接收方按分隔符切分。这个方案可读性好但如果num的字符串表示里出现了分隔符比如数字里不可能有|所以安全就没问题。缺点是如果数据量太大接收方要缓存整个字符串再切分内存占用高。第三种是长度前缀。每组数据前面加一个4字节的整数表示后面跟了多少字节。接收方先读4字节知道长度再读对应长度的数据。这个方案最通用但RAPID侧实现起来最复杂。我实际项目里用的是分隔符批次头的混合方案每次发送以#BATCH,序号,总数#开头然后跟数据数据之间用,分隔一组数据以\n结尾。接收方按\n切分先解析批次头再解析数据。这样即使TCP粘包接收方也能通过\n找到消息边界。2.4 数据精度与格式化的坑RAPID的NumToStr函数有个参数是小数位数。如果你写NumToStr(value, 2)它会返回两位小数的字符串比如3.14。但如果你写NumToStr(value, 0)它会四舍五入到整数。这里有个大坑NumToStr的第二个参数是小数位数不是有效数字位数。我见过有人写NumToStr(value, 6)以为保留6位有效数字结果123456.789变成了123456.789000字符串长度暴涨。对于400组数据每个num的小数位数要统一否则字符串长度不一致接收方解析的时候容易出错。我的做法是所有num统一保留3位小数因为工业现场的位置数据毫米和速度数据毫米每秒保留3位已经足够力矩数据牛米保留3位也够。这样每个num的字符串长度在5到10个字符之间400个num大约3000到4000字符。还有一个坑负数和小数的格式化。RAPID的NumToStr对负数的处理是直接加负号比如-3.14这个没问题。但如果你的num是-0.001格式化后可能是-0.001也可能是-0.000如果四舍五入到3位接收方解析的时候要注意符号。3. 实操过程与核心环节实现3.1 上位机服务端的准备先在工控机上写一个TCP服务端用Python最方便因为调试快。下面是一个最简服务端监听5000端口接收数据并打印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(fListening on {PORT}...) conn, addr server.accept() print(fConnected by {addr}) buffer while True: data conn.recv(4096) if not data: break buffer data.decode(utf-8) while \n in buffer: line, buffer buffer.split(\n, 1) print(fReceived: {line})这个服务端的关键点是用buffer缓存未完成的消息。recv(4096)可能收到半条消息也可能收到多条消息所以不能直接print(data)要先拼到buffer里再按\n切分。这就是解决粘包的标准做法。3.2 RAPID侧的数据打包逻辑假设我们要发送400个num这些num存在一个数组dataArray{400}里。RAPID的数组下标从1开始所以是dataArray{1}到dataArray{400}。打包的逻辑是先拼批次头再循环拼数据最后加\n。但IRC5的字符串长度限制是1024所以我们要分批。假设每批发100个num分4批发。MODULE SocketSendModule VAR socketdev clientSocket; VAR num dataArray{400}; VAR i; VAR j; VAR string sendStr; VAR string batchStr; VAR num batchSize : 100; VAR num batchCount : 4; PROC main() ! 初始化数据这里用随机数模拟 FOR i FROM 1 TO 400 DO dataArray{i} : i * 1.234; ENDFOR SocketCreate clientSocket; SocketConnect clientSocket, 192.168.1.100, 5000; FOR j FROM 1 TO batchCount DO batchStr : #BATCH, NumToStr(j, 0) , NumToStr(batchCount, 0) #; sendStr : batchStr; FOR i FROM (j-1)*batchSize 1 TO j*batchSize DO sendStr : sendStr NumToStr(dataArray{i}, 3) ,; ENDFOR sendStr : sendStr \n; SocketSend clientSocket \Str:sendStr; WaitTime 0.05; ENDFOR SocketClose clientSocket; ENDPROC ENDMODULE这段代码有几个关键点。第一NumToStr(j, 0)把批次序号转成整数因为批次序号不需要小数。第二NumToStr(dataArray{i}, 3)保留3位小数。第三每批发完WaitTime 0.05给接收方一点时间处理避免TCP缓冲区堆积。第四批次头用#BATCH,序号,总数#的格式接收方可以校验是否丢批。3.3 接收方的解析逻辑接收方收到#BATCH,1,4#1.234,2.468,...,123.400,\n这样的字符串后解析步骤是先按\n切分出完整消息再检查是否以#BATCH,开头然后提取批次序号和总数最后按,切分数据部分。def parse_message(line): if not line.startswith(#BATCH,): return None header_end line.index(#, 7) header line[7:header_end] batch_idx, batch_total header.split(,) data_str line[header_end1:] values [float(x) for x in data_str.split(,) if x] return { batch_idx: int(batch_idx), batch_total: int(batch_total), values: values }这个解析函数的关键是先找批次头的结束位置再切数据。因为数据部分也可能包含#虽然num的字符串表示里不会有#但为了健壮性还是先定位。values列表的长度应该是100每批100个num如果不是100说明数据丢了或者多了要报警。3.4 完整的数据流验证把上面的服务端和RAPID代码跑起来你应该在服务端看到4条消息每条消息的values长度是1004条加起来400个num。如果看到values长度不是100或者批次序号不连续说明有问题。我实际调试的时候第一次跑就遇到了values长度是99的情况。排查发现是RAPID侧NumToStr对某个num格式化后产生了空字符串因为那个num是0NumToStr(0, 3)返回0.000不是空字符串所以不是这个原因。后来发现是字符串拼接的时候最后一个逗号后面直接跟了\n接收方按,切分后最后一个元素是空字符串被if x过滤掉了导致少一个。解决办法是在拼接的时候最后一个num后面不加逗号或者接收方不过滤空字符串但去掉最后一个空元素。4. 常见问题与排查技巧实录4.1 连接建立失败10061错误Windows上跑服务端机器人连过来报10061意思是“由于目标计算机积极拒绝无法连接”。这个错误的原因通常是服务端没启动或者防火墙拦了。排查顺序先在工控机上用netstat -an | findstr 5000看端口有没有监听如果没有说明服务端没跑起来如果有用telnet 127.0.0.1 5000测试本地能不能连如果本地能连但机器人连不上检查Windows防火墙的入站规则把5000端口放行。还有一个坑服务端绑定的是127.0.0.1而不是0.0.0.0。127.0.0.1只监听本地回环机器人从外部连不进来。必须绑0.0.0.0或者工控机的实际IP。4.2 数据粘包一次收到多条消息粘包是TCP的固有特性不是bug。接收方必须用buffer缓存按分隔符切分的方式处理。我见过有人用recv(3200)以为一次能收全结果有时候收到1600有时候收到4800解析直接崩。正确做法是不管收到多少先拼到buffer再按\n切分切出完整消息就处理剩下的留在buffer里等下次。如果发送方发得太快接收方处理不过来TCP缓冲区会满发送方的SocketSend会阻塞。RAPID的SocketSend是阻塞式的如果接收方不读机器人会卡在SocketSend那里节拍就乱了。所以发送方每批之间加WaitTime接收方尽快读这是双向的。4.3 数据错位解析出来的num数量不对数据错位通常有几个原因。一是分隔符冲突如果num的字符串表示里出现了,不可能因为NumToStr用.做小数点或者批次头里的,和数据里的,混淆。解决办法是批次头用#包裹和数据部分明确分开。二是字符串截断IRC5的字符串长度限制是1024如果一批数据超过1024字符SocketSend会报错或者截断。解决办法是减小批次大小比如每批50个num。三是编码问题RAPID的字符串是ASCIIPython默认用UTF-8解码如果数据里有非ASCII字符不会有会出错。统一用ASCII或者UTF-8都行因为数字和逗号都是ASCII。4.4 常见问题速查表问题现象可能原因排查方法解决方案连接被拒绝10061服务端没启动或防火墙拦截netstat查端口telnet测本地启动服务端放行防火墙一次收到多条消息TCP粘包打印每次recv的长度buffer缓存按分隔符切分解析出的num数量少分隔符处理不当打印原始字符串检查拼接逻辑去掉末尾逗号机器人卡在SocketSend接收方不读缓冲区满看机器人是否停在Send指令接收方尽快读发送方加WaitTime字符串超长报错IRC5字符串限制1024打印sendStr长度减小批次大小数据精度不对NumToStr小数位数不对打印格式化后的字符串统一小数位数4.5 独家避坑技巧第一个技巧在RAPID侧加一个发送计数器。每次SocketSend成功后计数器加1如果计数器超过某个值比如1000就SocketClose再SocketConnect重连一次。因为长时间运行后TCP连接可能因为各种原因半死一方认为连着另一方已经断了重连能解决大部分玄学问题。第二个技巧接收方加超时机制。如果超过5秒没收到新数据就认为连接断了关闭当前连接重新accept。这样机器人重启后能自动重连不需要人工干预。第三个技巧用Wireshark抓包验证。如果实在搞不清楚数据为什么不对在工控机上用Wireshark抓5000端口的包看机器人实际发出来的字节流是什么。Wireshark能看到TCP层的分段情况帮你判断是发送方的问题还是接收方的问题。我有一次遇到数据错位抓包发现机器人发出来的字符串里有个\0是RAPID字符串拼接的时候没初始化导致的这种问题不看抓包根本找不到。第四个技巧RobotStudio的虚拟示波器。RobotStudio里有个示波器功能可以把num变量的值实时画出来。调试的时候先在RobotStudio里用虚拟控制器跑一遍确认数据打包逻辑没问题再上真机。这样能省很多现场调试时间。4.6 性能优化建议400组num数据如果每个节拍都要发节拍时间是1秒那么每秒要发3200字节这个数据量对TCP来说很小性能不是瓶颈。但如果节拍时间是100毫秒每秒要发32000字节就要考虑优化了。优化的方向有几个。一是减少字符串拼接的次数。RAPID的字符串拼接是O(n)的400次拼接就是O(n²)如果数据量再大拼接本身就成了瓶颈。解决办法是用PackRawBytes直接打包二进制一次发3200字节接收方按8字节一个double解析。二是用UDP代替TCP。UDP没有粘包问题但会丢包适合对实时性要求高但对丢包不敏感的场景。ABB机器人支持UDP socket用SocketCreate的时候指定\UDP参数就行。三是压缩数据。如果num的变化范围不大可以用定点数代替浮点数比如把毫米精度的位置数据乘以1000变成整数用2字节表示数据量能压缩到原来的四分之一。不过说实话大部分工业场景下400组num数据用TCP字符串发送已经足够了优化到二进制层面属于过度设计。除非你的节拍时间真的到了几十毫秒级别否则没必要折腾。4.7 一个完整的调试记录我最近做的一个项目机器人是IRC5上位机是C#写的服务端。第一次联调的时候机器人发出来的数据在C#端解析出来总是少几个num。用Wireshark抓包发现机器人发出来的字符串里有些num的格式化结果是1.234有些是1.23有些是1.2因为NumToStr对末尾的0会省略。比如NumToStr(1.200, 3)返回的是1.2不是1.200。这就导致接收方按,切分后有些字段是1.2有些是1.234长度不一致但数量是对的。后来发现数量少是因为C#端的Split函数默认会去掉空字符串而RAPID侧最后一个num后面跟了逗号导致最后一个字段是空字符串被去掉了。解决办法是在RAPID侧拼接的时候最后一个num后面不加逗号或者C#端用StringSplitOptions.None。这个问题的根子是RAPID的NumToStr不保证固定长度。如果你需要固定长度的字符串得自己补零。比如NumToStr(value, 3)之后检查字符串长度如果不足前面补空格或者补零。但补零会影响数值解析所以一般不建议。最好的做法是接收方按实际长度解析不要假设固定长度。5. 扩展思考从400组到更多组400组num数据只是一个具体的数字实际项目中可能是200组也可能是1000组。核心逻辑是一样的打包、发送、切分、解析。区别在于数据量大了之后字符串拼接的性能问题和TCP缓冲区的管理问题会更突出。如果数据量到了几千组我的建议是改用二进制协议。RAPID侧用PackRawBytes把num打包成8字节的double一次发几百个double接收方按8字节解析。这样数据量精确没有字符串格式化的开销也没有分隔符冲突的问题。缺点是调试的时候看不到可读的数字得写一个专门的解析工具把二进制转成可读格式。还有一个方向是用多个socket并行发送。比如开4个socket每个socket发100组数据这样能利用多核CPU的并行处理能力。但ABB机器人的socket数量有限制IRC5最多同时开8个socket而且多socket的同步是个麻烦事一般不建议。最后说一个实际项目中的经验不要试图在一次socket连接里发送所有数据。我见过有人把400组数据攒在一起等所有数据都准备好了再一次性发结果机器人内存不够RAPID报错。正确的做法是流式发送数据产生一组就发一组或者攒够一批就发一批。这样内存占用小实时性也好。这个项目后续还可以这样扩展把接收到的数据存到数据库里用Grafana做可视化或者用Python的pandas做工艺分析。这些就是上位机侧的事情了跟机器人侧的socket发送关系不大但整个数据链路的思路是一样的。
