前阵子帮朋友做了个小型装配线的改造核心设备是一台库卡机器人上位控制用的是S7-1200 PLC。原来机器人一直靠人在示教器旁边按启动键现在要把启动权交给PLC实现真正的“一键开机、自动循环”。这个需求听起来简单但做起来涉及库卡机器人外部启动模式的配置、S7-1200的PROFINET通信、安全回路设计还有机器人程序里的while指令用法。整套东西折腾了几天踩了几个很有代表性的坑今天干脆把完整过程拆开聊一遍给后面接手类似项目的朋友做个参考。项目本身不复杂但“外部启动”这四个字背后的门道比想象中多。你要是只会在示教器上按启动那不算懂外部启动。真正要解决的是PLC怎么安全地把“启动”信号给机器人机器人怎么反馈“收到、正在运行、完成”以及两台设备在异常情况下怎么互相保护。这些点捋顺了项目就成了一大半。1. 项目背景与整体方案1.1 为什么必须做外部启动这套装配线原来没有上位控制机器人自己干自己的活人工放料后按一下启动按钮。后来增加了前段输送线和自动检测工位要求机器人必须等前段信号到位而且要和输送线互锁不能出现“输送线还在动、机器人已经伸手去抓”这种危险情况。这时候如果还靠人工去按示教器上的启动键节拍和安全性都跟不上。于是客户提出一个硬性要求机器人所有动作必须由中央PLC统一指挥包括启动、停止、暂停、复位。这就是库卡机器人的“外部自动运行”模式也叫外部启动。这个模式说白了就是让机器人放弃“人工按键”这个入口改用外部信号来触发运行。S7-1200在这条产线里本身就是主站已经控制着一堆传感器、气缸、变频器再让它同时指挥机器人逻辑上是顺理成章的。1.2 通信方式选型PROFINET还是硬线IO刚接触这个项目的时候我第一反应是走硬线IO。简单直接用PLC的输出点直接接机器人输入点机器人输出点接PLC输入点一对一互不干扰。但真正把IO数量列出来之后发现完全不是那么回事。外部启动不只是“一个启动按钮”。你要有启动请求、启动确认、运行中、完成、故障、复位、安全门状态、急停状态……这一套信号加起来至少十几个点。如果全用硬线控制柜里要多拉一捆线而且以后想加信号就得改线、改端子相当痛苦。库卡KR C4控制柜标配支持PROFINETS7-1200也自带PROFINET口两台设备之间通过一根网线就能把几十个信号传完。所以我最终选了PROFINET方案S7-1200作为PROFINET控制器库卡机器人作为IO设备两者通过工业交换机互联。对比项硬线IOPROFINET通信接线数量几十根端子多一根网线结构简单扩展性加信号要改线软件里加地址就行信号诊断能力基本没有可监控IO状态、通信质量调试复杂度查线方便改线麻烦需要组态、配设备名可靠性物理隔离抗干扰交换机/网线故障会影响通信实际跑下来PROFINET的稳定性完全够用调试时还能在TIA Portal里直接监控库卡发过来的全部IO状态排查问题比硬线方便太多。2. 硬件接线与安全回路设计2.1 硬件准备与网络规划先列一下我这边用到的核心硬件西门子S7-1200 CPU型号1214C DC/DC/DC带两个PN口库卡机器人控制器KR C4配PROFINET接口工业交换机一台千兆百兆无所谓生产线环境建议有管理功能屏蔽网线若干长度控制在80米以内外部急停按钮、安全门开关、安全继电器、中间继电器若干接线前先把IP网段规划好。我这边用的是PLC作为IO控制器机器人作为IO设备两者直接连交换机。IP地址规划如下PLC192.168.1.10KUKA机器人192.168.1.20交换机不配置IP纯二层透传为什么IP要提前规划好因为PROFINET通信建立的前提是设备名和设备IP必须匹配。库卡机器人作为PN设备在WorkVisual里设置设备名和IPS7-1200在TIA Portal里必须填一模一样的设备名一个字母都不能差。后面很多“通信不上”的坑基本都是设备名不一致导致的。2.2 外部急停和安全回路不能只靠PLC这是整个项目里我最想强调的部分。很多人做外部启动以为PLC给机器人一个启动信号就完事了机器人自己的安全回路压根没动。这是非常危险的。库卡机器人本身有一套完整的安全回路包括控制柜上的急停按钮、示教器上的急停按钮、安全门插头、机器人本体限位等等。做外部启动时产线的急停按钮和安全门开关必须并联或串联进这套安全回路不能只交给PLC程序处理。我这边客户提供了一组外部急停按钮外加一道安全门。接线方式是把外部急停按钮的常闭触点、安全门开关的常闭触点按照机器人控制柜X11客户接口的图纸要求双回路接入。这里必须强调每个机型的安全回路接线点不同务必以随机手册为准。我在现场见过有人把外部急停接成常开结果按下急停机器人反而跑了这就是接反了。外部急停硬件回路的意义在于即使PLC死机、通信断开、程序跑飞只要急停被按下安全回路断开机器人会立刻进入STOP状态这是硬逻辑不依赖任何软件。PLC程序里也要监控这个急停状态作为启动互锁条件。但PLC侧只是“逻辑互锁”真正的物理切断靠的是硬件回路。两者要同时做缺一不可。3. S7-1200侧的程序与配置3.1 TIA Portal组态与PROFINET设备命名在S7-1200里把库卡机器人添加为PROFINET IO设备流程并不复杂但有几个细节必须注意。第一步从库卡那边拿到GSDML文件。库卡KR C4安装在WorkVisual软件后通常可以在安装目录里找到对应的GSDML描述文件也可以在配置机器人PROFINET时直接导出。拿到文件后在TIA Portal的“选项-管理设备描述文件”里导入。第二步把GSDML文件里的设备拖到网络视图连到PLC的PROFINET端口上。这时候会要求填设备名必须和库卡机器人里配置的设备名完全一致。我这边用的设备名是大写开头的字符串比如“KUKA_KR”注意不能有中文和特殊符号。第三步分配设备IP地址。S7-1200侧给库卡分配一个IP比如192.168.1.20然后在库卡WorkVisual侧也改成同一个IP。这个过程有点像两台电脑联网两边IP必须在同一个网段但PN通信还要匹配设备名比普通网口通信多一层。第四步看IO模块结构。库卡机器人作为从站会暴露一组输入输出字节。常见的配置是10个字节输入、10个字节输出也就是80个开关量点。你需要根据机器人的信号映射表把这80个点分配到PLC的I/O地址上。TIA Portal里有一个小坑默认的IO地址可能和机器人内部映射不一致。比如机器人侧$OUT[1]对应的其实是PLC侧第3个字节的第1位如果你不去核对信号表程序里调了一天也找不出为什么不动作。3.2 PLC控制块的核心逻辑通信组好之后PLC程序的核心就是状态机。我这边给机器人定义了几个关键信号信号方向PLC地址含义PLC - 机器人机器人输出DB1.DBX0.0外部启动命令PLC - 机器人机器人输出DB1.DBX0.1信号复位PLC - 机器人机器人输入DB2.DBX0.0机器人已就绪PLC - 机器人机器人输入DB2.DBX0.1机器人运行中PLC - 机器人机器人输入DB2.DBX0.2机器人已完成PLC - 机器人机器人输入DB2.DBX0.3机器人故障这里必须说明PLC侧和机器人侧的“输入输出”是反的。从PLC角度PLC输出是发送给机器人的信号所以在机器人侧看就是输入。PLC输入是接收机器人的信号机器人侧看就是输出。我在现场见过好几个新人搞反方向。控制逻辑用SCL写状态机最合适简单直观。核心流程是CASE step OF 0: // 空闲状态等待允许条件 IF 机器人已就绪 AND 急停_正常 AND 安全门_关闭 THEN step : 10; END_IF; 10: // 等待启动按钮/上游信号 IF 启动请求 THEN 机器人_外部启动命令 : TRUE; step : 20; END_IF; 20: // 等待机器人回已启动握手信号 IF 机器人在运行 THEN 机器人_外部启动命令 : FALSE; step : 30; END_IF; 30: // 运行中等待完成信号 IF 机器人已完成 THEN step : 40; END_IF; 40: // 完成处理 机器人_信号复位 : TRUE; IF NOT 机器人已完成 THEN 机器人_信号复位 : FALSE; step : 0; END_IF; END_CASE;这里最重要的就是“握手”逻辑PLC发出启动命令后不会一直保持这个命令而是等机器人回一个运行确认信号然后立刻把启动命令撤销。为什么要这么设计因为如果启动命令一直保持为TRUE机器人程序里那个等待启动信号的while循环会第二次直接通过导致程序连续跑两遍。这种“启动-确认-撤销-执行”的握手方式是所有外部启动项目的通用套路习惯之后会觉得非常自然。3.3 配置文件与参数外部加载的思路调试过程中我同事顺口说了句玩笑话“所有配置文件都要采用外部加载启动参数就跟--spring.config.additional-location一样不能焊死在程序里。”虽然是拿Java配置来调侃但放在PLC项目里特别贴切。S7-1200的DB块初始值是可以在线下载修改的但这还不够“外部加载”。更规范的做法是把地址表、节拍时间、位置偏移量、工装参数全部放进一个独立的DB块做成“配方”或者“外部参数区”。这样现场调参时只需要修改DB值或者下载配方不用去动控制逻辑更不用重新编译整个程序。我这个项目里专门建了一个DB_Recipe数据块里面放着启动握手持续时长运动完成后的停止等待时间机器人抓取位置坐标偏移量节拍超时报警阈值调试时如果发现机器人动作太快或者太慢直接在TIA的在线监控里改数值不用动一行逻辑代码。这一点在后续维护中非常加分客户自己也能在监控画面里调整参数不用动不动找厂家。4. 库卡机器人侧设置与程序编写4.1 KRC4外部自动运行模式配置机器人侧的配置是整个项目的重头戏也是很多人容易卡住的地方。库卡机器人要进入外部自动运行模式需要做两件事配置通信接口选择外部自动模式。通信接口在WorkVisual里配置。库卡KR C4支持多种总线协议PROFINET只是其中一种。在WorkVisual的项目树里找到“PROFINET”配置项添加IO设备设置设备名和IP然后分配输入输出字节数。我这边分配的是10字节输入、10字节输出对应80个点足够用了。分配完成后还需要做信号映射。库卡机器人控制器内部有系统变量$IN和$OUT分别对应机器人的物理输入输出。通过PROFINET通信过来的信号要映射到这些系统变量上机器人程序才能读取。举个例子我在WorkVisual里把PROFINET输入的第1个字节的第0位映射到$OUT[1]这样PLC侧给这个地址发TRUE时机器人程序里读到$OUT[1]就是TRUE。反过来机器人程序里把$IN[1]置为TRUEPLC侧就能收到对应输出为TRUE。这里有一个新手常犯的错误直接在WorkVisual里定义了IO但没有激活配置或者激活后没有重启控制柜。库卡很多配置必须重启才会生效重启之前你会一直怀疑是自己程序写错了。配置完成后在smartPAD上把运行模式切换到EXT外部自动。这样机器人就不会响应示教器上的启动键所有启动逻辑都交给外部信号。4.2 机器人主程序while指令的正确用法机器人程序我这边用的是KRL语言核心就是while指令的循环等待。整个程序大概长这样DEF MAIN_PROG() ; 初始化先确保输出复位 $OUT[2] FALSE $OUT[3] FALSE $OUT[4] FALSE ; 循环等待外部启动信号 WHILE $OUT[2] FALSE WAIT SEC 0.05 ENDWHILE ; 收到启动信号给PLC回一个“运行中”确认 $OUT[3] TRUE ; 等待PLC撤销启动命令避免二次触发 WHILE $OUT[2] TRUE WAIT SEC 0.05 ENDWHILE ; 开始执行工艺程序 HOME_POSITION() GRAB_PART() MOVE_PLACE() HOME_POSITION() ; 执行完毕输出完成信号 $OUT[4] TRUE WAIT SEC 0.2 $OUT[4] FALSE END这段程序里的whlie指令用了三处每一处都有讲究。第一处是等待启动信号这里没有用IF而是用WHILE是因为机器人必须停留在等待状态直到PLC发出启动信号。如果这里用了IF那么机器人会在执行到IF的瞬间检查一次信号不满足就直接往下走了根本等不住。第二处是等待PLC撤销启动命令。这一步非常关键否则机器人会陷入“启动信号一直为TRUE程序刚跑完一遍又立刻开始下一遍”的无限循环。用WHILE把启动信号等成FALSE相当于做了一个边沿触发只在PLC发出“从FALSE到TRUE”的这个瞬间才启动一次。第三处是完成信号保持时间。用WHILE或者WAIT SEC让完成信号保持一小段时间确保PLC那边能稳定捕获到然后再复位。这个时间太短容易丢信号太长又影响节拍0.2秒是权衡后的经验值。这里还要特别提醒一个while指令的坑在库卡KRL中while循环体内必须要有等待语句比如WAIT SEC 0.05否则机器人控制器可能报实时性错误甚至导致系统停止。原因是KUKA的执行系统需要保证每个循环周期都有时间片释放出去死循环会占用整个解释器。4.3 信号握手与运行流程总结整个协作流程在逻辑上分五个阶段PLC确认安全条件急停正常、安全门关闭、机器人就绪给机器人发外部启动命令。机器人检测到启动命令为TRUE进入运行状态同时给PLC回“运行中”信号。PLC收到“运行中”信号后撤销启动命令。机器人检测到启动命令已撤销才开始执行真正的工艺动作。机器人动作完成把“已完成”信号发给PLCPLC确认后复位所有信号系统回到空闲状态。这个握手机制的好处是两台设备之间任何时候都是“一问一答”不会出现“PLC以为机器人动了其实程序还在等待”的误判。后面联调时只要看到某个信号卡住基本就能快速定位到是哪一台设备的逻辑有问题。5. 联调过程与常见问题排查5.1 第一次联调我们遇到的四个坑联调之前我觉得配置都做好了程序也写完了应该能一把过。结果真正通电一调试问题一个接一个冒出来而且都是很典型的。第一个坑是PROFINET通信始终建立不起来。TIA Portal里PLC侧一直报IO设备不可用但网线明明连好了IP也能ping通。查了半天最后发现库卡WorkVisual里配置的设备名是“kuka_KR”而TIA侧填的是“KUKA_KR”一个字母大小写不一致通信就不认。改回来之后立刻恢复。这个坑非常隐蔽因为IP ping通会让你误以为通信正常实际上PROFINET还要求设备名严格一致。第二个坑是启动命令一直为TRUE。最开始我把PLC的启动命令直接做成一个保持信号没有做握手撤销结果机器人程序里第二处while等待PLC撤销启动命令的逻辑永远等不到FALSE机器人就跑完一遍之后直接卡在那边。后来把启动命令改成“发出后等确认再撤销”的逻辑一切就正常了。第三个坑是信号映射搞反。在WorkVisual里我一开始把PLC的输出映射到了机器人的$IN上结果机器人程序里读的是$OUT导致启动信号怎么都不触发。后来核对信号表才发现机器人输入输出方向的“主语”不同重新映射后就好了。第四个坑涉及到安全回路。机器人控制柜报安全门报警但外部安全门明明是关好了的。一查发现外部急停按钮的常闭触点接错了一组导致安全回路有断点。这里不得不再次提醒安全回路的接线一定要对照随机手册不能凭经验。5.2 常见问题排查速查表我整理了一份实战速查表方便大家在现场快速排查。故障现象可能原因检查顺序和解决办法PLC侧报设备不可用PROFINET设备名、IP、硬件连接先用网线直连PC测IP再核对设备名是否完全一致最后看交换机是否正常机器人始终不启动没有进入EXT模式检查smartPAD上的运行模式是否切到外部自动机器人程序卡在while等待启动信号没到或者映射方向反了在TIA监控PLC输出是否发出在WorkVisual里看对应信号是否映射到$OUT机器人反复执行同一个动作PLC启动命令没有撤销检查PLC是否执行了“收到运行中信号后撤销启动命令”机器人报急停故障外部急停/门回路断开检查外部急停按钮常闭触点、门锁信号按照手册图纸逐一测量信号有时收到有时收不到握手时间太短完成信号保持时间不够把完成信号保持时间从0.1秒提升到0.2秒以上修改参数后机器人不生效程序没有重新编译或激活下载配置后重启控制柜再试5.3 联调时的安全操作顺序现场联调时我习惯按这个顺序来既能保证安全又能快速定位问题先把机器人模式打到T1手动慢速示教器上手动执行一遍工艺程序确认轨迹和点位都没问题。这一步很关键因为外部自动模式下的运行速度更快如果点位有问题在手动慢速阶段就能发现避免高速状态下撞机。然后改成外部自动模式但把机器人的速度倍率调低到10%-20%。PLC给启动信号观察机器人是不是能正确等待、启动、完成。确认逻辑没问题后再把速度倍率慢慢提上去。整个过程必须安排专人站在急停按钮旁边一旦发现异常立即拍停。库卡机器人的防碰撞、安全回路都很完善但人的判断永远是最后一道防线千万不要省这一步。6. 一些个人的实操心得项目最后交付的时候客户跟我说了一句“原来觉得机器人外部启动特别神秘看你们搞完好像也没那么难。”确实这个项目的难度不在于某一个点而在于把多个环节串起来。PROFINET通信、安全回路、信号握手、机器人程序控制任何一环出了问题机器人就是不给面子。如果要我说最有价值的经验大概率是两句话第一安全回路永远是第一优先级所有外部启动都必须保证物理急停链路可靠第二信号握手比程序动作本身更重要PLC和机器人之间一定要做到“一问一答”不要试图用“长时间保持一个信号”来省事。另外调试过程中真的不要嫌麻烦最好把每一步的修改都记录下来。我这次因为改了很多次IO映射和信号名称差一点搞混。后来建了一张信号对照表PLC地址、机器人系统变量、实际用途三列每次修改都同步更新后面排查问题快了很多。如果你手头正好也要做类似的库卡机器人和S7-1200协作项目不妨把重点放在通信配置和安全回路上程序逻辑反而最不容易出错。外部启动做得好生产线才能真正解放人工。希望这篇记录能帮你少走几个弯路。