码垛机项目在自动化产线里属于看着简单、实际坑比较多的设备类型。我见过不少项目机械部分都装好了电气程序却拖了几个月最后卡在垛型切换不灵活、计数错位、立体库交互不稳定这些小问题上。最近整理了一套西门子S7-1200写的码垛机与立体库联动程序结构清爽、注释做得比较到位想着把程序核心模块的设计思路和实现细节拆开聊聊给正在搞同类项目的朋友一个参考。先说清楚这套程序是干什么的。码垛机负责把来料按预设垛型一层一层堆到托盘上堆满一垛后把满垛输出同时触发立体库入库请求立体库那边通过堆垛机把空托盘和满垛在库位与输送线之间搬运。整个系统涉及码垛机本体X/Y/Z三轴或机器人、输送线、托盘供给、立体库堆垛机、库位管理PLC这几个部分。程序要解决的三个核心问题垛型怎么算、动作怎么排、和立体库怎么通信。1. 程序总体框架从I/O分配到任务分区先别急着写代码把控制架构理清楚比任何技巧都重要。S7-1200的CPU选型直接决定了项目能不能顺利落地我这条产线用的是CPU 1214C DC/DC/DC配了一个SM 1223 数字量模块扩展输入输出点外加一个CM 1241 RS485模块备用实际通信走的Profinet这个口子后来没用上。一套码垛机程序输入输出点看起来没多少真列出来会发现比预想多得多X轴前限位、后限位、零点开关Y轴左限位、右限位、零点开关Z轴上限位、下限位、零点开关再加上夹具加紧到位、夹具松开到位、托盘到位传感器、来料检测、满垛检测、输送线对接光电、急停、复位按钮等等光数字量就有三十多个点。如果用本体自带输入输出不够用所以模拟量模块倒不是必须数字量扩展反而是刚需。程序结构上我按功能拆成了六个FB块加两个全局DB最核心的规矩是一条每个FB只干一类事不搞一个大FB从头写到尾。这六个FB分别是FB100_ModeSelect运行模式切换手动/自动/回原点FB200_PalletPattern垛型计算与计数管理FB300_AxisCtrl三轴运动控制按轴分别实例化FB400_GripperCtrl夹具动作控制FB500_LineConv输送线与托盘供给控制FB600_WMSLink与立体库WMS/堆垛机通信这种分法有个直接好处出问题能快速定位。比如垛型乱了直接查FB200夹具不动作查FB400和立体库通信超时查FB600。不用从头到尾翻梯形图翻半天。S7-1200和S7-1500有一点不一样1200的编程更偏向用FB的Instance DB来管理数据厂家推荐的做法是“每个FB一个背景DB”但我在这个项目里用了一个技巧把所有FB的背景数据统一放到一个共享DB里每个FB分配一个UDT。这样做的原因是1200的CPU内存有限多个重复调用的背景DB会浪费内存用UDT做静态数据块程序运行更轻量而且打开一个DB就能看到全部状态调试时不用切来切去。这个做法用好了很顺手用不好容易乱关键是把UDT的名字和结构定义清晰和FB的接口保持严格对应。2. 垛型计算与堆垛计数程序里最烧脑的部分垛型计算是整个码垛程序的大脑也是最能体现程序“结构清晰”的地方。所谓垛型说白了就是每一层怎么摆。常见的有同向叠垛、交错叠垛砖墙式、旋转90度叠垛还有复杂的混合垛型。这套程序支持按行列定义任意矩形垛型通过参数配置不做死每一种箱子尺寸。先看我是怎么组织数据的。在全局DB里建了一个数组pallet_cfg[MAX_LAYER].rows // 该层行数 pallet_cfg[MAX_LAYER].cols // 该层列数 pallet_cfg[MAX_LAYER].offset_x // 该层在X轴方向偏移 pallet_cfg[MAX_LAYER].offset_y // 该层在Y轴方向偏移 pallet_cfg[MAX_LAYER].rotate // 是否旋转90度为什么要按“层”配置而不是按“垛”配置因为码垛机的堆叠顺序是从底层往上每一层的行列数可能不一样。比如有些箱子承压能力差底层要摆多几个箱子分散压力上层可以少摆几个。这种需求在饮料、化工、建材行业特别常见。按层配置灵活性就出来了。接下来是计数逻辑。核心变量就一个layer_count当前层数、box_count_per_layer当前层已放箱数。每一层的步进逻辑是这样的来料检测到箱子到位Z轴下降抓取夹具夹紧Z轴上升Z轴运动到目标坐标X、Y由当前层号当前箱号计算出来Z轴下降放箱夹具松开Z轴上升box_count_per_layer加1如果box_count_per_layer等于当前层的rows * cols说明这层放完了layer_count加1box_count_per_layer清零如果layer_count等于总层数说明整垛完成触发满垛输出信号这个逻辑看着简单实际写的时候最容易翻车的是目标坐标的计算。坐标公式是X_target base_x col_index * (box_length gap_x) layer_offset_x Y_target base_y row_index * (box_width gap_y) layer_offset_y其中col_index是当前箱在该层的列号0到cols-1row_index是行号。如果你用的是FB内部的临时变量去算一旦网络扫描顺序不对算出来的坐标就会跳变。我见过有人把坐标计算写在运动指令后面的网络段里结果每次扫描都重新算一遍运动过程中坐标被刷新最后箱子放歪。正确的做法在启动一次“取箱-放箱”循环之前先把目标坐标锁存到专门的坐标变量里整个循环过程不刷新直到放箱完成确认后才更新计数并计算下一箱的坐标。这就是所谓的“先算后动算完锁存”。关于旋转垛型这里的rotate参数控制的是箱子在夹具上的姿态。如果箱子长宽不对称比如600x400旋转90度后摆放尺寸就变成了400x600坐标计算里的长度和宽度要互换。这个互换不能放在坐标计算那里做应该在参数初始化的时候就换算好否则每次扫描都判断一次旋转状态逻辑绕来绕去容易出bug。还有一个常见的坑二进制码垛Box 1和Box 2交错叠。这种情况要用到垛型表轮询也就是把每一层的行列定义做成一个二维数组pattern_table[pattern_id][layer_no].rows pattern_table[pattern_id][layer_no].cols pattern_table[pattern_id][layer_no].offset_x pattern_table[pattern_id][layer_no].offset_y pattern_table[pattern_id][layer_no].rotate程序运行时按“产品编号”查找对应的垛型表然后从0层开始一层一层往上跑。产品切换的时候只要数据初始化做得好程序不用改一行设备就能换产。这个设计对多品种产线特别实用。3. 三轴运动控制与夹具互锁顺序逻辑是码垛机的生命线码垛机的运动控制不像运动控制卡那样做插补和轨迹规划用的是步进/伺服驱动器的方向脉冲控制或者变频/伺服的位置控制模式。这套程序针对的是伺服驱动器走位置模式的情况PLC给目标位置和启动信号伺服到达后返回到位信号。每个轴独立做成一个FB实例化三次FB300_AxisCtrl实例化为Axis_X、Axis_Y、Axis_Z是整个程序里复用性最高的模块。这个FB的核心状态机是IDLE待机 MOVING移动中 POS_WAIT等待到位确认 BRAKE_WAIT等待抱闸释放确认 FAULT故障暂停为什么要在MOVING和IDLE之间加一个等待状态因为伺服的“到位”输出和实际停止之间有一个跟随误差和稳定时间。如果PLC收到到位信号立刻进行下一步实际机构可能还在微动这时候夹具下降抓箱位置偏差就出来了。我的做法是在收到伺服到位信号后再延时200毫秒左右确认轴稳定才允许进入下一步动作。这个延时参数在FB里做成可调变量现场按机械刚性调整。三个轴之间要有严格的互锁不然轻则撞到夹具重则机械损坏。互锁逻辑的核心是任何时刻只有一个轴在运动。虽然伺服系统本身在位置模式下可以多轴同时运动但码垛机的机械结构通常刚性一般同时动X和Y轴容易产生振动甚至共振。我把三轴的运动请求做成互锁队列一次只放行一个轴。实际项目里X轴和Y轴同时运动的需求真不多——箱子从A点搬到B点路径是先上升、再平移、再下降。Z轴上升到位后X/Y轴平移再Z轴下降。既然工艺流程本来就是这个顺序强性单轴运动并不会影响节拍反而让调试省心了很多。在程序的自动流程里运动指令是以“步骤号”为索引的每步只能触发一个轴的运动请求。夹具控制有个容易被忽略的细节夹具的夹紧/松开检测开关必须做成“开闭双检”。也就是说夹紧信号和松开信号是两组独立的传感器不能只用一个气缸磁性开关。为什么很多现场只在气缸上装了一个磁性开关夹具夹紧时导通、松开时不导通看上去没问题但一旦信号线断线程序永远收不到松开信号就会误判夹具还在夹紧状态后果可能是带着箱子直接撞到立体库货架。双检测的好处是夹紧位置传感器到位才允许Z轴上升松开位置传感器到位才允许Z轴下降放箱。有一个没到位程序就停下来报故障绝不往下走。宁可停机排查也不带着隐患硬跑。Z轴的手动/自动回原点Home逻辑也是单独做成一个FUN的。回原点的顺序有讲究Z轴必须最先回原点因为它决定夹具高度X/Y轴后回原点。如果X/Y先动了Z轴还在半空很容易撞到托盘或输送线。4. 注释体系的建立程序可读性比聪明更重要标题里特意点出了“注释齐全”这方面我的感受特别深。西门子1200的编程环境下注释不是写在哪里都能长久保留的有些地方的注释会在下载时被覆盖有些则不会。我吃过亏之后整理了一套注释规范直接决定项目移交后的维护成本。第一层变量注释。在PLC变量表里每个I/O变量、M变量、DB变量都必须写注释。这个注释是跟随符号名走遍程序的FB块内部访问外部变量时梯形图里会自动带出中文注释。很多工程师这一步偷懒结果程序拷到别人电脑上一看全是地址完全没法看懂。其实这层注释写起来最轻松就是“X轴伺服启动”、“托盘到位传感器”这样的中文描述写清楚就有80分。第二层DB块变量注释。1200的全局DB和FB背景DB支持在变量表的“注释”列里写说明这一层我习惯写得细一些每个变量至少写清楚“它是干什么的”“单位是什么”“什么时候更新”例如pallet_cfg[1].rows // 第1层行数由HMI配方画面写入程序启动时读取 pallet_cfg[1].offset_x // 第1层X轴偏移mm用于偏置摆放一般为0 layer_counter // 当前已堆的层数0表示空托盘达到pallet_max_layer时触发满垛 box_counter_layer // 当前层已放的箱数达到rows*cols时层数1这种注释写在DB里还有一个好处在线监控时变量值和注释列一起显示维护人员看着监控表就能读出整个程序的当前状态。第三层程序段注释。每个网络段Network的段标题必须写清楚“这一步在做什么”段注释里写清楚“为什么这么做”以及“关联的联锁条件”。这两者是有区别的段标题是给快速浏览的人看的索引段注释才是给深挖逻辑的人看的说明书。我见过太多人段标题写了“控制输出”等于没写正确写法是“Z轴下降条件取箱完成且松开放箱确认且无急停故障”。第四层FB块的接口注释。FC/FB的输入输出参数注释尤其重要这是外部调用者唯一能看到的接口说明。比如FB300_AxisCtrl的使能信号注释必须写明“该信号在上电后应保持为TRUE否则轴会急停”而不是简单写个“使能”。还有一个容易被忽略的点程序上传下载时的注释丢失问题。S7-1200如果只上载程序块注释信息不会自动带上来需要另存为带注释的源文件。源文件建议用TIA Portal的“生成源文件”功能定期导出到项目文件夹。我通常会在程序定版后做一次源文件备份连同注释一起存档。不要等到设备停产检修了才发现PLC里的程序打开了全是没注释的地址。注释的最终目标是一个没参与这个项目的工程师拿着这台PLC的程序能在半天之内搞清楚产线的工作流程、每个按钮的作用、每个报警的含义。如果做不到这一点注释工作就没做到位。5. 与立体库的交互逻辑数据通信永远要设超时保护立体库联动在码垛机项目里是配合最频繁的部分。码垛机完成一垛后要把满垛送到立体库入库口立体库里的堆垛机再过来取走放到指定库位立体库还能把空托盘送到码垛机的托盘供给工位。这套衔接流程的程序逻辑说难不难但涉及两个PLC或者PLC与上位机之间的配合最容易出问题的地方是通信数据的稳定性。我采用的是Profinet IO方式S7-1200做IO Controller立体库那边集成了Rofinet的Profinet IO设备模块通过GSD文件导入组态。这样做的最大好处是两个PLC不需要各自编写复杂的通信代码直接在I/O地址里读写数据就行。程序里我分配了32字节的输出区和32字节的输入区输出区码垛机→立体库入库请求、入库货位号、满垛到位信号、托盘请求、出库请求、状态字运行/故障/急停输入区立体库→码垛机入库允许、入库完成、托盘到位、出库完成、堆垛机状态、报警字看起来就这么点数据重点在于通信超时保护。Profinet IO本身有看门狗机制断线了会报IO错误。但业务层面的“没有回应”和物理层面的“断线”是两码事。比如码垛机发出入库请求立体库那边因为堆垛机忙没来得及处理这不算断线但程序等久了就会堵料。我给它单独设了一个“任务超时定时器”每个请求发出后启动5秒计时5秒内没收到对应确认程序进入“通信等待故障”状态除了急停和复位所有输出切断并在HMI上报“入库请求超时”。这个超时时间为什么是5秒不是拍脑袋定的是结合堆垛机从库位跑到入库口的最大时间实测约3.2秒再加上安全余量算出来的。如果设置太短正常的任务就会被误判为超时设备老是无故停机设置太长真故障发现得慢产线堵箱时间太长。调这个参数的方法很简单让堆垛机停在最远的库位发一次入库请求掐表看多久能收到确认乘以1.5倍余量。还有一点要特别提醒和立体库交互时数据要“边沿触发”而不是“电平触发”。比如“入库请求”信号应该是发出一个脉冲而不是持续置位。持续置位的问题在于如果立体库那边在收到信号后还没来得及处理你已经复位了信号就丢了反过来如果你一直置位立体库处理完一次又处理第二次就可能重复入库。我用的是一个标准的“请求-应答”握手协议码垛机置位请求信号同时开始计时立体库检测到请求边沿回一个“已接收”信号码垛机收到“已接收”后复位请求信号立体库检测到请求复位复位“已接收”这个握手看着多了一个来回但通信不会丢信号也不会重复触发。现场调试时我经手的几次丢垛问题全是分不清电平触发和边沿触发造成的。还有一个立体库联动里非常实用的逻辑任务队列缓冲。码垛机的节拍通常比入库快如果码垛机堆好一垛立刻发请求而堆垛机正在忙码垛机就只能等等久了输送线还会堵料。我在程序里加了一个可存储三个任务的小队列FIFO码垛机完成一垛就把任务写进队列然后去做下一垛立体库处理完一个任务再从队列里取下一个。这个设计把两台设备的节拍解耦了缓冲区用全局DB数组实现索引用环形头尾指针程序简单且可靠。6. 程序调试与故障排查记一次实际调试记录的复盘最后聊聊调试阶段的经验。这个项目从通电开始算了算大概用了一周半完成单机调试两天完成与立体库的联调。调试过程中踩了几个典型坑所有这些坑背后都有一条共同的经验程序里所有的运动和通信动作都必须有状态反馈不能靠猜。第一个坑X轴伺服的手动JOG速度设置太高。手动模式下点动X轴速度设成了自动模式的80%结果一按键就冲出去差点顶到护栏。后来把手动速度统一设成自动模式的15%并且给每个轴单独加了软限位在程序中用比较指令强制限制目标位置不依赖硬件限位。这个经验不值钱但很实用手动速度慢一点调试工人才有反应时间才敢放心大胆地试按钮。第二个坑空托盘的垛高检测判断失误。托盘本身有一定高度码垛机空托盘到位后Z轴回归零点参考的是地面高度没有考虑托盘高度结果第一箱放下去直接砸到了托盘边缘。排查后发现程序在“托盘到位信号”触发后自动加了一个Z轴基准高度偏移但我在手动调试时没有更新这个偏移参数。后来放弃了“绝对基准”的做法改成每次托盘到位后先做一次Z轴慢速探底用Z轴带抱闸的伺服堵转运矩触发记录实际托盘表面高度再按这个高度计算第一层放箱的高度参考。虽然每次托盘到位多花了几秒钟但是可靠了很多。第三个坑通信数据被莫名修改。排查了半天发现是触摸屏HMI在配方画面里误写了DB块的参数把垛型的行数和列数都写成了0程序跑起来坐标全部算错。解决的办法是在HMI的数据记录里把配方变量的写入权限做了分级需要密码才能修改垛型参数普通操作员只能查看。另外在程序里增加了参数合法性校验读到行数或列数为0时自动报“垛型参数错误”而不是往下执行。像这种参数问题程序里做防呆比人盯人可靠得多。常见问题我整理了一个速查表送给现场维护也合适现象可能原因排查步骤整层放完后无法进入下一层layer_count计数与pallet_max_layer比较逻辑错位在线监控FB200中layer_count和当前层号核对层号在放箱前还是放箱后加1X轴放箱位置每层偏移越来越大坐标计算公式里用了临时变量没有锁存或offset_x被循环累加检查“计算坐标”和“运动执行”是否在同一个扫描周期确认offset_x不是自增变量夹具夹紧后Z轴不上升夹紧到位信号没有反馈到FB400或乱线时被误触发手动单步模式强制夹紧看传感器信号是否变化再用万用表量传感器输出入库请求发了但立体库无反应通信字地址组态错位或Profinet设备未连接在监控表看输出区字节是否变化在线诊断Profinet IO设备状态手动模式能操作自动模式一启动就报警“顺序错误”自动启动条件里检测了托盘未到位或Z轴未回原点把自动启动的“预条件”逻辑全部展开逐条看HMI状态字哪个条件不满足就查哪个还有一个维护建议程序中所有报警文本统一放到HMI的报警组里PLC里只输出报警编号整数每条对应一个错误文本。不要用PLC程序直接拼字符串显示到HMI那样改动文本必须改PLC程序再下载维护麻烦且容易下载时把运行状态打断。个人在实际调试中体会到码垛机与立体库联动程序的调试顺序很重要先手动、后半自动、再全自动、最后才做异常测试与恢复测试。异常测试包括急停恢复、通信断开恢复、托盘不到位恢复、夹具打不开恢复。每个恢复流程都必须在程序里验证过“恢复后能接着原来的步骤继续执行”而不是从头再来一遍。生产场景里拔掉一根线跑了半小时的线体要能从故障点接着干如果每次故障恢复都从第一箱开始堆那产线一天得浪费多少产能。