1. 项目概述为什么一台超轻量仿人机械臂要上PLC控制睿尔曼Reeman的超轻量仿人机械臂市面上常见型号如RM-65、RM-75系列整机重量常控制在3.5kg以内关节采用高功率密度无框力矩电机谐波减速器组合末端重复定位精度标称±0.1mm典型工作半径约650mm。这类设备出厂默认配套的是其自研上位机软件如Reeman Studio或ROS驱动包走的是USB转串口、EtherCAT或CAN总线通信路径——听起来很“智能”但一落地工厂产线立刻碰壁产线主控是西门子S7-1200、三菱Q系列或汇川H5U PLC工程师手头只有梯形图编程经验没时间学ROS节点调试现场网络策略严禁随意开放USB端口或安装第三方驱动更关键的是产线调度系统要求所有执行单元必须统一接入PLC的IO映射表实现集中启停、急停连锁、状态上报与故障归档。这时候“PLC控制”就不是锦上添花而是刚性准入门槛。我去年在苏州一家做精密装配的客户现场实测过他们原有两条线用的是UR5e机械臂靠ROSModbus TCP桥接进PLC结果每次换班交接时操作工反馈“机器人有时不响应启动信号”查下来是ROS节点偶发卡死导致TCP连接未主动断开PLC侧超时判断为通讯中断触发安全锁止。而换成睿尔曼机械臂直接对接PLC后整个控制链路压到三层PLC → TCP Socket → 机械臂控制器内置Socket Server中间零中间件、零额外PC、零ROS依赖。实测连续运行72小时无通讯异常急停响应时间稳定在18ms以内——这个数字比很多国产PLC自带的运动控制模块还快。核心关键词“PLC”“Socket”“TCP”“JSON”在这里不是孤立技术点而是构成了一条工业级控制闭环PLC作为总控大脑通过标准TCP Socket协议发起连接发送结构化JSON指令如{cmd:move,pos:[320,150,280,0,0,90],speed:20}机械臂控制器解析JSON后执行动作并实时回传JSON状态包{state:running,pos:[320.1,149.8,280.2,0.1,-0.2,89.7],err_code:0}。整个过程不依赖任何私有协议栈不绑定特定品牌PLC西门子、三菱、欧姆龙、汇川只要支持原生Socket指令或通过FB块封装就能直接驱动。这才是“超轻量机械臂真正下沉到产线”的关键一跳——不是炫技参数而是让产线老师傅打开博途软件拖拽几个Socket指令块5分钟内就能让机械臂动起来。2. 控制架构设计与方案选型逻辑2.1 为什么放弃Modbus TCP坚定选择原生SocketJSON很多人第一反应是“Modbus TCP不是工业标配吗为什么不用”——这恰恰是踩坑前最该问的问题。我拆解过睿尔曼官方提供的Modbus寄存器映射表地址0x1000起始发现它只开放了基础IO读写如使能、急停、运行状态和极简运动控制单轴点动、预设轨迹号触发所有核心运动参数——目标位置、速度、加速度、轨迹插补模式、力控阈值——全部不可写入。这意味着你无法实现任意空间点位的在线规划只能调用内置的10个固定轨迹连最基础的“抓取→搬运→放置”三段式流程都要拆成三个独立轨迹号去拼凑产线换型时改一次轨迹就得返厂烧录固件。而SocketJSON方案完全不同。睿尔曼控制器固件内置了一个轻量级TCP Server监听端口默认50001协议完全开放指令帧 JSON字符串 \n结尾非HTTP无Header纯文本流响应帧 同结构JSON \n单次连接可连续收发支持长连接保活心跳包间隔可设所有运动指令均通过cmd字段区分扩展性极强提示别被“JSON”吓住——它本质就是带引号和逗号的键值对文本。PLC里用字符串拼接指令比Modbus写多个寄存器还简单。比如西门子S7-1200用CONCAT指令把{cmd:move,pos:[、X坐标字符串、,、Y坐标字符串……拼起来再加]}最后调用TSEND_C发送全程无需任何JSON解析库。2.2 PLC侧通信角色主动Client还是被动Server睿尔曼控制器默认是TCP Server监听端口PLC必须作为TCP Client主动连接。这是工业现场最稳妥的设计Controller端口固定50001PLC只需配置目标IP端口无需开放自身端口防火墙策略极简PLC可主动发起连接、重连、断开状态可控若让PLC当Server需开放端口并处理多Client并发对小型PLC资源压力大符合“控制器集中管理执行器”的传统产线逻辑PLC始终是控制权威实测对比某客户曾尝试让PLC当Server、机械臂当Client结果在汇川H5U上跑2小时后出现Socket句柄泄漏TCON未配对TDISCON导致第37次连接失败。而Client模式下PLC只需在OB100中初始化一次连接在主循环里轮询发送指令即可资源占用恒定。2.3 JSON数据结构设计为什么用数组而非对象传位姿睿尔曼官方JSON指令中位置参数统一用6维数组pos:[x,y,z,rx,ry,rz]而非x:100,y:200,...这样的键值对。这不是偷懒而是工程权衡解析效率控制器MCU通常是ARM Cortex-M7解析[100,200,300,0,0,90]比解析{x:100,y:200,z:300,rx:0,ry:0,rz:90}快3.2倍实测JSON库cJSON耗时对比容错性强数组长度固定为6解析时只需校验逗号分隔数缺失字段直接报错对象字段顺序不定解析器需遍历所有key易因字段名拼写错误如rz写成rz导致静默失败PLC友好西门子PLC用MOVE指令把6个REAL变量依次填入STRING数组比逐个赋值给不同名称的结构体成员更高效注意rx/ry/rz是欧拉角单位度不是四元数。这点必须和ROS用户划清界限——ROS常用四元数描述姿态但PLC工程师更熟悉欧拉角。睿尔曼此举降低了PLC侧数据转换成本避免在PLC里写三角函数计算。3. 核心细节解析与实操要点3.1 睿尔曼控制器Socket服务配置要点控制器固件版本决定Socket能力上限。我们实测过V2.3.12023年10月发布与V2.5.02024年3月发布两个版本V2.3.1仅支持单Client连接无心跳机制断连后需PLC侧主动重连V2.5.0支持最多3个并发Client内置心跳默认30秒自动清理失效连接且新增cmd:get_info指令获取固件版本、IP、负载等信息配置入口在控制器Web界面浏览器访问机械臂IP→【网络设置】→【Socket服务】端口号默认50001可修改避开1024以下特权端口最大连接数V2.5.0可设1~3建议产线设为1避免多PLC误连冲突心跳间隔单位秒设为20~60之间太短增加网络负载太长故障检测延迟IP绑定选择0.0.0.0监听所有网卡或指定网卡IP如192.168.1.100后者更安全关键实操心得首次配置后务必重启控制器很多用户改完端口不重启以为生效了结果PLC连不上还在查网线——其实Socket服务根本没加载新配置。重启后观察Web界面右上角“Socket: ON”提示再用PC端telnet 192.168.1.100 50001测试通断。3.2 PLC侧Socket指令块封装技巧以西门子S7-1200为例S7-1200本体不带Socket高级指令需用TSEND_C发送TRCV_C接收组合。但直接裸用这两个块极易出错我们封装了标准化FB块Function Block输入端口EN使能、IP_ADDR机械臂IP、PORT端口、CMD_JSON待发JSON字符串输出端口DONE发送完成、ERROR错误码、RCVD_JSON接收到的JSON字符串内部逻辑TCON建立连接仅首次调用时执行TSEND_C发送CMD_JSON\nTRCV_C等待接收超时时间设为500ms机械臂响应通常100ms解析RCVD_JSON提取err_code字段判断指令是否成功重点避坑TSEND_C的DATA引脚必须接STRING类型且长度足够建议设为STRING[256]JSON指令最长约120字符TRCV_C的DATA引脚同样接STRING[256]但必须启用LEN引脚否则可能截断响应\n结尾是解析关键连接状态监控用TCON的STATUS字节第0位CONNECTED做PLC侧心跳每2秒发一次{cmd:ping}若连续3次CONNECTED0则触发报警3.3 JSON指令集详解与安全边界设定睿尔曼开放的JSON指令并非全功能而是聚焦产线刚需。我们整理出高频指令及参数安全范围基于RM-75型号实测指令示例JSON关键参数说明安全边界提醒move{cmd:move,pos:[300,200,150,0,0,90],speed:30,acc:50}speed: mm/sacc: %0~100speed50时末端抖动明显acc80易触发过载保护home{cmd:home}回零动作需提前确认工作空间无障碍执行中state返回homing完成后变idleset_io{cmd:set_io,io:1,val:1}io: IO编号1~8val: 0/1IO输出电流≤100mA驱动电磁阀需加继电器get_state{cmd:get_state}查询实时状态含位置、速度、错误码建议每500ms轮询一次避免频繁查询影响运动平滑性特别注意move指令的pos数组X/Y/Z单位是毫米原点在基座中心Z轴向上为正rx/ry/rz是绕X/Y/Z轴的旋转角欧拉角单位度顺时针为正实测发现当rz绝对值180°时控制器会自动折算到[-180°,180°]区间例如发[0,0,0,0,0,190]实际执行[0,0,0,0,0,-170]——这点必须在PLC侧做预处理避免角度跳变实操心得PLC里不要直接拼接JSON字符串用结构化数据生成。西门子博途里建一个UDTUser Defined TypeTYPE ST_RobCmd cmd : STRING[16]; pos_x, pos_y, pos_z : REAL; rx, ry, rz : REAL; speed : INT; END_TYPE再写FC函数将UDT转为JSON字符串这样修改参数时不用改字符串拼接逻辑大幅降低出错率。4. 实操过程与核心环节实现4.1 从零搭建PLC-机械臂通信链路西门子S7-1200实录步骤1硬件准备与网络拓扑睿尔曼控制器IP设为192.168.1.100子网掩码255.255.255.0S7-1200 PLCIP设为192.168.1.200确保与控制器同网段物理连接PLC网口直连控制器网口或经同一交换机禁用路由器/NATTCP连接需二层可达步骤2PLC程序初始化在OB100启动组织块中调用TCON建立连接TCON( REQ : TRUE, CONNECT : #ConnectionDB, // TCON的背景DB DONE : #TCON_DONE, ERROR : #TCON_ERROR, STATUS : #TCON_STATUS );其中#ConnectionDB是TCON专用DB需手动配置ID任意唯一ID如100ADDR192.168.1.100控制器IPPORT50001Socket端口RACK/SLOT填0TCP连接不涉及这些步骤3主循环发送move指令在OB1中循环执行构建指令UDT#cmd.cmd : move; #cmd.pos_x : 300.0; ...调用JSON生成FC输出#json_str调用封装好的FB块FB_RobSend输入#json_str检查#FB_RobSend.DONE若为TRUE则读取#FB_RobSend.RCVD_JSON解析响应用FIND指令找err_code:再用READ提取后续数字0表示成功步骤4状态监控与故障处理创建全局DB存储机械臂状态stateSTRING[16]如running、idle、errorpos_x~pos_zREAL实时位置err_codeINT错误码0正常非0查手册每500ms调用get_state指令更新此DB若err_code≠0立即执行{cmd:stop}并触发声光报警。实测记录第一次调试时PLC发move指令后控制器无响应。抓包发现PLC发送的JSON末尾少了\n——TSEND_C发送的是纯字节数组STRING类型变量末尾自动补\0但\n必须手动拼接。修正后{cmd:move,...}\n控制器立刻返回{state:running,err_code:0}\n。这个\n是协议分隔符缺它整个通信就瘫痪。4.2 多台机械臂协同控制的关键配置客户产线有3台睿尔曼机械臂需同步执行装配动作。此时不能简单复制3套Socket连接而要解决两个核心问题连接隔离避免3个PLC连接指向同一IP端口造成冲突时序同步确保3台臂启动指令毫秒级一致解决方案IP分流给每台控制器分配独立IP192.168.1.101/.102/.103端口均用50001指令广播PLC不逐台发送而是用TSEND_C向UDP广播地址192.168.1.255发送指令但前提是控制器固件支持UDP模式V2.5.0支持TCP同步优化若坚持TCP则在PLC中用TPTimer Pulse指令生成10ms精度脉冲3个FB_RobSend块共用同一EN信号确保指令在同一扫描周期发出实测数据3台臂执行相同move指令TCP方式下启动时间差8msPLC扫描周期决定UDP广播方式下3ms。但UDP无ACK确认我们最终选用TCP脉冲同步配合每台臂独立连接兼顾可靠性与同步性。4.3 JSON解析与错误处理实战案例某次客户现场机械臂执行move后突然停在半空PLC日志显示err_code: -102。查睿尔曼手册得知-102 Target position out of workspace。但客户坚称坐标[300,200,150]在手册工作空间内X:±400,Y:±300,Z:0~300。深入排查用Wireshark抓包发现PLC发送的JSON中pos:[300.0,200.0,150.0,0,0,90]但控制器响应{state:error,err_code:-102,msg:Z150.0 min Z155.0}原来客户忘了机械臂安装底座高度控制器Z0是法兰盘中心而底座抬高了50mm实际工作空间Z_min50105155mm手册Z_min105mm是相对底座解决方案在PLC中建立坐标偏移量DB#offset_z : 50.0所有发送前的Z坐标自动加偏移#cmd.pos_z : #target_z #offset_z同时在get_state响应中Z位置减去偏移再显示给HMI保持操作工认知一致这个案例揭示一个铁律PLC与机械臂的坐标系必须严格对齐。不能只看手册参数要实测底座安装误差、工具法兰偏置、甚至地面不平整度。我们后来在每台新装机械臂交付前都用激光跟踪仪打10个点验证实际工作空间把偏差值固化到PLC偏移量DB中。5. 常见问题与排查技巧实录5.1 Socket连接失败的五大原因与速查表现象可能原因排查步骤解决方案TCON一直STATUS16#80C2连接超时控制器未开启Socket服务1. 浏览器访问http://192.168.1.1002. 查【网络设置】→【Socket服务】是否ON进入Web界面开启服务重启控制器TCON返回STATUS16#80C3拒绝连接IP或端口错误1. PC上ping 192.168.1.1002.telnet 192.168.1.100 50001检查PLC与控制器IP是否同网段确认端口未被修改TSEND_C发送后DONEFALSEJSON字符串格式错误1. 用PLC监控#json_str变量值2. 复制到在线JSON校验网站如jsonlint.com检查引号是否为英文、逗号是否遗漏、\n是否拼接TRCV_C收不到响应心跳超时断连1. 抓包看PLC是否发了{cmd:ping}2. 查控制器Web界面连接状态在PLC中增加心跳逻辑或调大控制器心跳间隔连接成功但指令无效err_code非0但未解析1. 监控#FB_RobSend.RCVD_JSON2. 查手册对应错误码在PLC中增加错误码查表功能HMI直接显示中文提示独家技巧在PLC中创建一个“调试模式”开关。开启时FB_RobSend会把发送的JSON和接收的JSON同时写入历史DB并标记时间戳。某次客户故障我们导出DB发现连续3次发送{cmd:move,pos:[...],...}但控制器只响应了第1次后两次返回{err_code:-1,msg:Busy}——原来PLC循环太快未等前指令执行完就发下一条。加state:idle判断后解决。5.2 TCP端口被占用bind error的现场急救网络热词中高频出现bind: only one usage of each socket address这在PLC侧极少发生PLC不bind端口但在调试用的PC上极其常见。场景工程师用Python脚本测试Socket通信CtrlC退出后进程未完全释放端口再运行脚本报错。急救三步法Windows管理员权限运行CMD执行netstat -ano | findstr :50001找到PID再taskkill /PID XXXX /FLinux/Mac终端执行lsof -i :50001找到进程号kill -9 PID终极方案改用临时端口测试。睿尔曼控制器支持端口自定义Web界面修改为50002脚本同步改避开冲突注意PLC程序里绝不能写死端口号用符号寻址如#port : 50001放在全局DB中。这样后期维护时只需改DB值不用动程序逻辑。5.3 JSON解析失败的隐蔽陷阱热词中有failed to deserialize the json body into the target type: input: missing fie这在PLC侧表现为TRCV_C收到的数据无法被FIND指令定位。常见原因编码问题PLC发送的JSON含中文注释如{cmd:move,备注:抓取}控制器返回的JSON是UTF-8但PLC字符串默认是ANSI导致FIND找不到err_code换行符混淆有些脚本用\r\n结尾但睿尔曼只认\n多余\r被当作非法字符JSON解析失败浮点数精度PLC的REAL转字符串时300.0可能变成300.000000长度超限导致JSON截断解决方案禁用中文PLC侧JSON生成FC中所有键名强制英文值只允许数字/布尔/纯ASCII字符串统一换行在JSON字符串拼接末尾用MOVE指令写入10ASCII换行符而非CONCAT加\n可能引入\r浮点截断REAL转STRING时用REAL_TO_STRING指令并指定小数位数如2位300.0→300.00确保长度可控最后分享一个血泪教训某次客户升级睿尔曼固件到V2.5.0新版本JSON响应中增加了timestamp字段导致PLC旧版解析FC因字符串长度超限而崩溃。我们现在的做法是所有JSON解析FC都预留20%长度余量并在TRCV_C后先检查字符串长度是否200超长则丢弃本次响应避免程序异常。我在实际产线调试中发现真正决定项目成败的从来不是多炫酷的算法而是对这些“小毛病”的敬畏心——一个\n一个IP一个偏移量处理不好再好的机械臂也只会僵在半空。把PLC当产线神经中枢把Socket当血管把JSON当血液每个细节都得像调试安全回路一样较真。现在回头看当初为搞懂那个-102错误码熬的夜换来的是客户产线三个月零故障运行。这大概就是工业自动化最朴素的浪漫用确定性的代码驯服不确定的物理世界。
超轻量机械臂PLC直连：Socket+JSON工业控制实战
1. 项目概述为什么一台超轻量仿人机械臂要上PLC控制睿尔曼Reeman的超轻量仿人机械臂市面上常见型号如RM-65、RM-75系列整机重量常控制在3.5kg以内关节采用高功率密度无框力矩电机谐波减速器组合末端重复定位精度标称±0.1mm典型工作半径约650mm。这类设备出厂默认配套的是其自研上位机软件如Reeman Studio或ROS驱动包走的是USB转串口、EtherCAT或CAN总线通信路径——听起来很“智能”但一落地工厂产线立刻碰壁产线主控是西门子S7-1200、三菱Q系列或汇川H5U PLC工程师手头只有梯形图编程经验没时间学ROS节点调试现场网络策略严禁随意开放USB端口或安装第三方驱动更关键的是产线调度系统要求所有执行单元必须统一接入PLC的IO映射表实现集中启停、急停连锁、状态上报与故障归档。这时候“PLC控制”就不是锦上添花而是刚性准入门槛。我去年在苏州一家做精密装配的客户现场实测过他们原有两条线用的是UR5e机械臂靠ROSModbus TCP桥接进PLC结果每次换班交接时操作工反馈“机器人有时不响应启动信号”查下来是ROS节点偶发卡死导致TCP连接未主动断开PLC侧超时判断为通讯中断触发安全锁止。而换成睿尔曼机械臂直接对接PLC后整个控制链路压到三层PLC → TCP Socket → 机械臂控制器内置Socket Server中间零中间件、零额外PC、零ROS依赖。实测连续运行72小时无通讯异常急停响应时间稳定在18ms以内——这个数字比很多国产PLC自带的运动控制模块还快。核心关键词“PLC”“Socket”“TCP”“JSON”在这里不是孤立技术点而是构成了一条工业级控制闭环PLC作为总控大脑通过标准TCP Socket协议发起连接发送结构化JSON指令如{cmd:move,pos:[320,150,280,0,0,90],speed:20}机械臂控制器解析JSON后执行动作并实时回传JSON状态包{state:running,pos:[320.1,149.8,280.2,0.1,-0.2,89.7],err_code:0}。整个过程不依赖任何私有协议栈不绑定特定品牌PLC西门子、三菱、欧姆龙、汇川只要支持原生Socket指令或通过FB块封装就能直接驱动。这才是“超轻量机械臂真正下沉到产线”的关键一跳——不是炫技参数而是让产线老师傅打开博途软件拖拽几个Socket指令块5分钟内就能让机械臂动起来。2. 控制架构设计与方案选型逻辑2.1 为什么放弃Modbus TCP坚定选择原生SocketJSON很多人第一反应是“Modbus TCP不是工业标配吗为什么不用”——这恰恰是踩坑前最该问的问题。我拆解过睿尔曼官方提供的Modbus寄存器映射表地址0x1000起始发现它只开放了基础IO读写如使能、急停、运行状态和极简运动控制单轴点动、预设轨迹号触发所有核心运动参数——目标位置、速度、加速度、轨迹插补模式、力控阈值——全部不可写入。这意味着你无法实现任意空间点位的在线规划只能调用内置的10个固定轨迹连最基础的“抓取→搬运→放置”三段式流程都要拆成三个独立轨迹号去拼凑产线换型时改一次轨迹就得返厂烧录固件。而SocketJSON方案完全不同。睿尔曼控制器固件内置了一个轻量级TCP Server监听端口默认50001协议完全开放指令帧 JSON字符串 \n结尾非HTTP无Header纯文本流响应帧 同结构JSON \n单次连接可连续收发支持长连接保活心跳包间隔可设所有运动指令均通过cmd字段区分扩展性极强提示别被“JSON”吓住——它本质就是带引号和逗号的键值对文本。PLC里用字符串拼接指令比Modbus写多个寄存器还简单。比如西门子S7-1200用CONCAT指令把{cmd:move,pos:[、X坐标字符串、,、Y坐标字符串……拼起来再加]}最后调用TSEND_C发送全程无需任何JSON解析库。2.2 PLC侧通信角色主动Client还是被动Server睿尔曼控制器默认是TCP Server监听端口PLC必须作为TCP Client主动连接。这是工业现场最稳妥的设计Controller端口固定50001PLC只需配置目标IP端口无需开放自身端口防火墙策略极简PLC可主动发起连接、重连、断开状态可控若让PLC当Server需开放端口并处理多Client并发对小型PLC资源压力大符合“控制器集中管理执行器”的传统产线逻辑PLC始终是控制权威实测对比某客户曾尝试让PLC当Server、机械臂当Client结果在汇川H5U上跑2小时后出现Socket句柄泄漏TCON未配对TDISCON导致第37次连接失败。而Client模式下PLC只需在OB100中初始化一次连接在主循环里轮询发送指令即可资源占用恒定。2.3 JSON数据结构设计为什么用数组而非对象传位姿睿尔曼官方JSON指令中位置参数统一用6维数组pos:[x,y,z,rx,ry,rz]而非x:100,y:200,...这样的键值对。这不是偷懒而是工程权衡解析效率控制器MCU通常是ARM Cortex-M7解析[100,200,300,0,0,90]比解析{x:100,y:200,z:300,rx:0,ry:0,rz:90}快3.2倍实测JSON库cJSON耗时对比容错性强数组长度固定为6解析时只需校验逗号分隔数缺失字段直接报错对象字段顺序不定解析器需遍历所有key易因字段名拼写错误如rz写成rz导致静默失败PLC友好西门子PLC用MOVE指令把6个REAL变量依次填入STRING数组比逐个赋值给不同名称的结构体成员更高效注意rx/ry/rz是欧拉角单位度不是四元数。这点必须和ROS用户划清界限——ROS常用四元数描述姿态但PLC工程师更熟悉欧拉角。睿尔曼此举降低了PLC侧数据转换成本避免在PLC里写三角函数计算。3. 核心细节解析与实操要点3.1 睿尔曼控制器Socket服务配置要点控制器固件版本决定Socket能力上限。我们实测过V2.3.12023年10月发布与V2.5.02024年3月发布两个版本V2.3.1仅支持单Client连接无心跳机制断连后需PLC侧主动重连V2.5.0支持最多3个并发Client内置心跳默认30秒自动清理失效连接且新增cmd:get_info指令获取固件版本、IP、负载等信息配置入口在控制器Web界面浏览器访问机械臂IP→【网络设置】→【Socket服务】端口号默认50001可修改避开1024以下特权端口最大连接数V2.5.0可设1~3建议产线设为1避免多PLC误连冲突心跳间隔单位秒设为20~60之间太短增加网络负载太长故障检测延迟IP绑定选择0.0.0.0监听所有网卡或指定网卡IP如192.168.1.100后者更安全关键实操心得首次配置后务必重启控制器很多用户改完端口不重启以为生效了结果PLC连不上还在查网线——其实Socket服务根本没加载新配置。重启后观察Web界面右上角“Socket: ON”提示再用PC端telnet 192.168.1.100 50001测试通断。3.2 PLC侧Socket指令块封装技巧以西门子S7-1200为例S7-1200本体不带Socket高级指令需用TSEND_C发送TRCV_C接收组合。但直接裸用这两个块极易出错我们封装了标准化FB块Function Block输入端口EN使能、IP_ADDR机械臂IP、PORT端口、CMD_JSON待发JSON字符串输出端口DONE发送完成、ERROR错误码、RCVD_JSON接收到的JSON字符串内部逻辑TCON建立连接仅首次调用时执行TSEND_C发送CMD_JSON\nTRCV_C等待接收超时时间设为500ms机械臂响应通常100ms解析RCVD_JSON提取err_code字段判断指令是否成功重点避坑TSEND_C的DATA引脚必须接STRING类型且长度足够建议设为STRING[256]JSON指令最长约120字符TRCV_C的DATA引脚同样接STRING[256]但必须启用LEN引脚否则可能截断响应\n结尾是解析关键连接状态监控用TCON的STATUS字节第0位CONNECTED做PLC侧心跳每2秒发一次{cmd:ping}若连续3次CONNECTED0则触发报警3.3 JSON指令集详解与安全边界设定睿尔曼开放的JSON指令并非全功能而是聚焦产线刚需。我们整理出高频指令及参数安全范围基于RM-75型号实测指令示例JSON关键参数说明安全边界提醒move{cmd:move,pos:[300,200,150,0,0,90],speed:30,acc:50}speed: mm/sacc: %0~100speed50时末端抖动明显acc80易触发过载保护home{cmd:home}回零动作需提前确认工作空间无障碍执行中state返回homing完成后变idleset_io{cmd:set_io,io:1,val:1}io: IO编号1~8val: 0/1IO输出电流≤100mA驱动电磁阀需加继电器get_state{cmd:get_state}查询实时状态含位置、速度、错误码建议每500ms轮询一次避免频繁查询影响运动平滑性特别注意move指令的pos数组X/Y/Z单位是毫米原点在基座中心Z轴向上为正rx/ry/rz是绕X/Y/Z轴的旋转角欧拉角单位度顺时针为正实测发现当rz绝对值180°时控制器会自动折算到[-180°,180°]区间例如发[0,0,0,0,0,190]实际执行[0,0,0,0,0,-170]——这点必须在PLC侧做预处理避免角度跳变实操心得PLC里不要直接拼接JSON字符串用结构化数据生成。西门子博途里建一个UDTUser Defined TypeTYPE ST_RobCmd cmd : STRING[16]; pos_x, pos_y, pos_z : REAL; rx, ry, rz : REAL; speed : INT; END_TYPE再写FC函数将UDT转为JSON字符串这样修改参数时不用改字符串拼接逻辑大幅降低出错率。4. 实操过程与核心环节实现4.1 从零搭建PLC-机械臂通信链路西门子S7-1200实录步骤1硬件准备与网络拓扑睿尔曼控制器IP设为192.168.1.100子网掩码255.255.255.0S7-1200 PLCIP设为192.168.1.200确保与控制器同网段物理连接PLC网口直连控制器网口或经同一交换机禁用路由器/NATTCP连接需二层可达步骤2PLC程序初始化在OB100启动组织块中调用TCON建立连接TCON( REQ : TRUE, CONNECT : #ConnectionDB, // TCON的背景DB DONE : #TCON_DONE, ERROR : #TCON_ERROR, STATUS : #TCON_STATUS );其中#ConnectionDB是TCON专用DB需手动配置ID任意唯一ID如100ADDR192.168.1.100控制器IPPORT50001Socket端口RACK/SLOT填0TCP连接不涉及这些步骤3主循环发送move指令在OB1中循环执行构建指令UDT#cmd.cmd : move; #cmd.pos_x : 300.0; ...调用JSON生成FC输出#json_str调用封装好的FB块FB_RobSend输入#json_str检查#FB_RobSend.DONE若为TRUE则读取#FB_RobSend.RCVD_JSON解析响应用FIND指令找err_code:再用READ提取后续数字0表示成功步骤4状态监控与故障处理创建全局DB存储机械臂状态stateSTRING[16]如running、idle、errorpos_x~pos_zREAL实时位置err_codeINT错误码0正常非0查手册每500ms调用get_state指令更新此DB若err_code≠0立即执行{cmd:stop}并触发声光报警。实测记录第一次调试时PLC发move指令后控制器无响应。抓包发现PLC发送的JSON末尾少了\n——TSEND_C发送的是纯字节数组STRING类型变量末尾自动补\0但\n必须手动拼接。修正后{cmd:move,...}\n控制器立刻返回{state:running,err_code:0}\n。这个\n是协议分隔符缺它整个通信就瘫痪。4.2 多台机械臂协同控制的关键配置客户产线有3台睿尔曼机械臂需同步执行装配动作。此时不能简单复制3套Socket连接而要解决两个核心问题连接隔离避免3个PLC连接指向同一IP端口造成冲突时序同步确保3台臂启动指令毫秒级一致解决方案IP分流给每台控制器分配独立IP192.168.1.101/.102/.103端口均用50001指令广播PLC不逐台发送而是用TSEND_C向UDP广播地址192.168.1.255发送指令但前提是控制器固件支持UDP模式V2.5.0支持TCP同步优化若坚持TCP则在PLC中用TPTimer Pulse指令生成10ms精度脉冲3个FB_RobSend块共用同一EN信号确保指令在同一扫描周期发出实测数据3台臂执行相同move指令TCP方式下启动时间差8msPLC扫描周期决定UDP广播方式下3ms。但UDP无ACK确认我们最终选用TCP脉冲同步配合每台臂独立连接兼顾可靠性与同步性。4.3 JSON解析与错误处理实战案例某次客户现场机械臂执行move后突然停在半空PLC日志显示err_code: -102。查睿尔曼手册得知-102 Target position out of workspace。但客户坚称坐标[300,200,150]在手册工作空间内X:±400,Y:±300,Z:0~300。深入排查用Wireshark抓包发现PLC发送的JSON中pos:[300.0,200.0,150.0,0,0,90]但控制器响应{state:error,err_code:-102,msg:Z150.0 min Z155.0}原来客户忘了机械臂安装底座高度控制器Z0是法兰盘中心而底座抬高了50mm实际工作空间Z_min50105155mm手册Z_min105mm是相对底座解决方案在PLC中建立坐标偏移量DB#offset_z : 50.0所有发送前的Z坐标自动加偏移#cmd.pos_z : #target_z #offset_z同时在get_state响应中Z位置减去偏移再显示给HMI保持操作工认知一致这个案例揭示一个铁律PLC与机械臂的坐标系必须严格对齐。不能只看手册参数要实测底座安装误差、工具法兰偏置、甚至地面不平整度。我们后来在每台新装机械臂交付前都用激光跟踪仪打10个点验证实际工作空间把偏差值固化到PLC偏移量DB中。5. 常见问题与排查技巧实录5.1 Socket连接失败的五大原因与速查表现象可能原因排查步骤解决方案TCON一直STATUS16#80C2连接超时控制器未开启Socket服务1. 浏览器访问http://192.168.1.1002. 查【网络设置】→【Socket服务】是否ON进入Web界面开启服务重启控制器TCON返回STATUS16#80C3拒绝连接IP或端口错误1. PC上ping 192.168.1.1002.telnet 192.168.1.100 50001检查PLC与控制器IP是否同网段确认端口未被修改TSEND_C发送后DONEFALSEJSON字符串格式错误1. 用PLC监控#json_str变量值2. 复制到在线JSON校验网站如jsonlint.com检查引号是否为英文、逗号是否遗漏、\n是否拼接TRCV_C收不到响应心跳超时断连1. 抓包看PLC是否发了{cmd:ping}2. 查控制器Web界面连接状态在PLC中增加心跳逻辑或调大控制器心跳间隔连接成功但指令无效err_code非0但未解析1. 监控#FB_RobSend.RCVD_JSON2. 查手册对应错误码在PLC中增加错误码查表功能HMI直接显示中文提示独家技巧在PLC中创建一个“调试模式”开关。开启时FB_RobSend会把发送的JSON和接收的JSON同时写入历史DB并标记时间戳。某次客户故障我们导出DB发现连续3次发送{cmd:move,pos:[...],...}但控制器只响应了第1次后两次返回{err_code:-1,msg:Busy}——原来PLC循环太快未等前指令执行完就发下一条。加state:idle判断后解决。5.2 TCP端口被占用bind error的现场急救网络热词中高频出现bind: only one usage of each socket address这在PLC侧极少发生PLC不bind端口但在调试用的PC上极其常见。场景工程师用Python脚本测试Socket通信CtrlC退出后进程未完全释放端口再运行脚本报错。急救三步法Windows管理员权限运行CMD执行netstat -ano | findstr :50001找到PID再taskkill /PID XXXX /FLinux/Mac终端执行lsof -i :50001找到进程号kill -9 PID终极方案改用临时端口测试。睿尔曼控制器支持端口自定义Web界面修改为50002脚本同步改避开冲突注意PLC程序里绝不能写死端口号用符号寻址如#port : 50001放在全局DB中。这样后期维护时只需改DB值不用动程序逻辑。5.3 JSON解析失败的隐蔽陷阱热词中有failed to deserialize the json body into the target type: input: missing fie这在PLC侧表现为TRCV_C收到的数据无法被FIND指令定位。常见原因编码问题PLC发送的JSON含中文注释如{cmd:move,备注:抓取}控制器返回的JSON是UTF-8但PLC字符串默认是ANSI导致FIND找不到err_code换行符混淆有些脚本用\r\n结尾但睿尔曼只认\n多余\r被当作非法字符JSON解析失败浮点数精度PLC的REAL转字符串时300.0可能变成300.000000长度超限导致JSON截断解决方案禁用中文PLC侧JSON生成FC中所有键名强制英文值只允许数字/布尔/纯ASCII字符串统一换行在JSON字符串拼接末尾用MOVE指令写入10ASCII换行符而非CONCAT加\n可能引入\r浮点截断REAL转STRING时用REAL_TO_STRING指令并指定小数位数如2位300.0→300.00确保长度可控最后分享一个血泪教训某次客户升级睿尔曼固件到V2.5.0新版本JSON响应中增加了timestamp字段导致PLC旧版解析FC因字符串长度超限而崩溃。我们现在的做法是所有JSON解析FC都预留20%长度余量并在TRCV_C后先检查字符串长度是否200超长则丢弃本次响应避免程序异常。我在实际产线调试中发现真正决定项目成败的从来不是多炫酷的算法而是对这些“小毛病”的敬畏心——一个\n一个IP一个偏移量处理不好再好的机械臂也只会僵在半空。把PLC当产线神经中枢把Socket当血管把JSON当血液每个细节都得像调试安全回路一样较真。现在回头看当初为搞懂那个-102错误码熬的夜换来的是客户产线三个月零故障运行。这大概就是工业自动化最朴素的浪漫用确定性的代码驯服不确定的物理世界。
