库卡机器人外部启动与S7-1200 PROFINET通信实操指南

前阵子帮朋友做了个小型装配线的改造，核心设备是一台库卡机器人，上位控制用的是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控制柜标配支持PROFINET，S7-1200也自带PROFINET口，两台设备之间通过一根网线就能把几十个信号传完。所以我最终选了PROFINET方案：S7-1200作为PROFINET控制器，库卡机器人作为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地址规划如下：

• PLC：192.168.1.10
• KUKA机器人：192.168.1.20
• 交换机：不配置IP，纯二层透传

为什么IP要提前规划好？因为PROFINET通信建立的前提是设备名和设备IP必须匹配。库卡机器人作为PN设备，在WorkVisual里设置设备名和IP，S7-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角度，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]置为TRUE，PLC侧就能收到对应输出为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 信号握手与运行流程总结

整个协作流程在逻辑上分五个阶段：

1. PLC确认安全条件（急停正常、安全门关闭、机器人就绪），给机器人发外部启动命令。
2. 机器人检测到启动命令为TRUE，进入运行状态，同时给PLC回“运行中”信号。
3. PLC收到“运行中”信号后，撤销启动命令。
4. 机器人检测到启动命令已撤销，才开始执行真正的工艺动作。
5. 机器人动作完成，把“已完成”信号发给PLC，PLC确认后复位所有信号，系统回到空闲状态。

这个握手机制的好处是，两台设备之间任何时候都是“一问一答”，不会出现“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 常见问题排查速查表

我整理了一份实战速查表，方便大家在现场快速排查。

5.3 联调时的安全操作顺序

现场联调时，我习惯按这个顺序来，既能保证安全，又能快速定位问题：

先把机器人模式打到T1手动慢速，示教器上手动执行一遍工艺程序，确认轨迹和点位都没问题。这一步很关键，因为外部自动模式下的运行速度更快，如果点位有问题，在手动慢速阶段就能发现，避免高速状态下撞机。

然后改成外部自动模式，但把机器人的速度倍率调低到10%-20%。PLC给启动信号，观察机器人是不是能正确等待、启动、完成。确认逻辑没问题后，再把速度倍率慢慢提上去。

整个过程必须安排专人站在急停按钮旁边，一旦发现异常立即拍停。库卡机器人的防碰撞、安全回路都很完善，但人的判断永远是最后一道防线，千万不要省这一步。

6. 一些个人的实操心得

项目最后交付的时候，客户跟我说了一句：“原来觉得机器人外部启动特别神秘，看你们搞完好像也没那么难。”确实，这个项目的难度不在于某一个点，而在于把多个环节串起来。PROFINET通信、安全回路、信号握手、机器人程序控制，任何一环出了问题，机器人就是不给面子。

如果要我说最有价值的经验，大概率是两句话：第一，安全回路永远是第一优先级，所有外部启动都必须保证物理急停链路可靠；第二，信号握手比程序动作本身更重要，PLC和机器人之间一定要做到“一问一答”，不要试图用“长时间保持一个信号”来省事。

另外，调试过程中真的不要嫌麻烦，最好把每一步的修改都记录下来。我这次因为改了很多次IO映射和信号名称，差一点搞混。后来建了一张信号对照表，PLC地址、机器人系统变量、实际用途三列，每次修改都同步更新，后面排查问题快了很多。

如果你手头正好也要做类似的库卡机器人和S7-1200协作项目，不妨把重点放在通信配置和安全回路上，程序逻辑反而最不容易出错。外部启动做得好，生产线才能真正解放人工。希望这篇记录能帮你少走几个弯路。