ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

S7-1500在新能源Pack产线中的程序架构设计与调试

S7-1500在新能源Pack产线中的程序架构设计与调试 1. 这条Pack线到底是什么样的项目1.1 项目背景从电芯到电池包的旅程先说结论这条“新能源pack线”就是新能源汽车动力电池包Pack的组装生产线。电池包不是从天上掉下来的它是电芯经过模组、装配、固定、线束连接、气密测试、EOL测试等一系列工序后最终封装成的一个带外壳的高压储能单元。咱们说的“pack线”就是干这事儿的产线。我接到这个项目时整条线的控制架构已经定了主控制器用西门子S7-1500配套ET200SP远程IO触摸屏用精智系列现场一堆伺服轴、变频器、拧紧枪、气密仪、EOL测试设备其中不少设备要靠Profinet和I/O点通信握手。这里说的“S1500”其实就是西门子S7-1500系列PLC的通俗叫法项目里大家也经常这么简写它在整条产线里相当于人的大脑和中枢神经。这条线解决的问题很直接把几十个电芯模组按工艺顺序放进托盘经过自动搬运、自动拧紧、自动涂胶、自动测试最后下线一个合格的电池包。整个节拍大概3到5分钟一个包中间任何一个环节掉链子整条线就得停。所以PLC程序的稳定性和可维护性比单纯“能跑起来”重要得多。这篇内容适合谁看如果你是刚接触新能源产线的电气工程师、PLC调试新手或者正在做S7-1500项目的朋友我把这条pack线程序里头最核心的设计思路、功能块写法、调试踩过的坑一条条捋清楚希望能让你少走点弯路。1.2 为什么选S7-1500而不是200 SMART或者300很多人问pack线用200 SMART不行吗或者老300还可以再战实际对比过才知道S7-1500在新能源产线这种场景下优势太明显了。先看运算能力和存储。S7-1500的CPU主频高工作存储区起步就是几百KB程序复杂点、配方数据多点也不怕。200 SMART的存储小、指令集简单做单机设备绰绰有余但到了pack线这种多工位、多轴、多通信的场合程序量一上来200 SMART的先天不足就露出来了。再看通信能力。S7-1500自带的Profinet接口性能好而且支持多个接口并行。pack线上Profinet IO设备数量经常超过二三十个包括伺服驱动器、变频器、远程IO站、智能仪表。S7-1500头一个接口带IO设备第二个接口可以连HMI、做编程口分工明确网络负载也不容易挤在一起。第三TIA Portal软件平台。1500只能在博途里用但博途的生态确实好PLC、HMI、变频器、伺服、驱动统一软件配置变量共享调试效率高。老300用Step7也能干但新时代的电池产线项目图纸、程序、HMI的集成化要求很高博途这套流程明显更顺。1.3 这条产线的工艺布局与设备拓扑搞清楚工艺才能写程序。pack线的工艺流程大致可以分成这么几段模组上线AGV或人工把模组放到上线工位。模组搬运机械手或桁架机器人把模组抓取到托盘上。托盘输送托盘在滚轮线或倍速链上依次流过各工位。拧紧工位把模组固定到电池包下壳体。涂胶/焊接工位视工艺不同有的做导热胶涂布有的做Busbar激光焊接。线束连接与装配低压线束、高压连接器、BMS安装。气密测试通过气密仪检测包体泄漏。EOL测试终检测试包括绝缘、耐压、通信等。下线和缓存。设备拓扑上S7-1500作为主站通过Profinet连接各分站ET200SP远程IO柜伺服驱动器比如西门子V90或第三方伺服ABB变频器走Profinet或Modbus TCP拧紧控制器如Atlas Copco、博世力士乐走Profinet或开放协议气密仪、EOL设备走Profinet或者以太网TCP机器人控制器一般走Profinet IO或者TCP/IP2. 程序架构先把框架立起来2.1 程序块的划分OB、FC、FB、DB怎么组织写S7-1500程序最忌讳的一件事就是把所有逻辑全堆在OB1里面。pack线程序量大如果都写在OB1里后面维修排查能查到崩溃。我的习惯是严格分层。OB组织方面我用的是OB1主循环只做“调用”工作不写具体逻辑。OB10时间中断用于定时执行的逻辑比如定时上报、定时汇总。OB30到OB35循环中断用于需要周期性处理的模拟量采集、伺服轴状态刷新、通信任务。OB40硬件中断接急停按钮或安全继电器的硬件输入。OB80、OB83、OB86、OB87故障处理OB分别处理时间错误、IO访问错误、机架故障、通信错误。OB100启动OB用于初始化变量、设置初始模式。很多人忽略故障OB这是一个大坑。一旦Profinet设备断线S7-1500默认会进入STOP整条线直接宕机操作工一脸懵维护人员还得翻看诊断缓冲区才知道怎么回事。我在项目里加了OB86之后单个从站掉线时CPU不会停机程序可以继续跑非故障区域同时报警画面弹出“某工位通信中断”维修可以带着备件直奔现场。FC和FB的划分我的原则是FB负责“有状态”的重复逻辑比如一个工位的流程控制、一个伺服轴的动作序列。FB有自己的静态变量Static可以记住当前工位走到哪一步了下次调用还能接着走。FC负责“无状态”的纯计算或转换比如模拟量工程量换算、Barcode字符串解析、报警文本拼接。DB的规划要认真做尤其背景数据块。每个FB调用时TIA会自动生成对应的背景DBInstance DB比如FB100“拧紧工位流程”的实例DB是DB100。这个DB里保存了工位状态机的当前步号、每个步骤的完成标志、错误标志。调试时看着DB里某个INT型“Step_No”跳到几就能定位程序卡在哪一步。2.2 数据管理不是所有变量都要塞到全局DB里新手容易犯的错是把所有变量都建在全局DB里几百个Bool、几千个Int密密麻麻看着都头疼。pack线动辄上百个I/O点、几十台设备状态变量管理不好程序根本没法维护。我建议把数据划分成这么几类分别放硬件I/O变量表通过PLC变量表定义名称写成“工位号_设备名_信号类型”比如“S02_拧紧枪_RunSignal”、“S03_托盘到位_Sensor”。设备状态DB每个工位一个DB保存这个工位所有设备的运行状态、报警码、当前模式。工艺参数DB存放所有可以调整的工艺参数比如扭矩值、涂胶速度、测试时间。这个DB最好有“配方”概念一个产品型号对应一组配方。报警管理DB所有报警的编号、文本、触发时间、确认标志都集中到这里。通信数据DB跟ABB变频器、拧紧设备、机器人通信的数据单独放方便排查通信问题。数据规划的意义在于程序里任何一条报警能不能快速定位维修人员能不能通过触摸屏按工位查到设备状态交接班记录问题的时候能不能直接看出是工艺问题还是通信问题这些都靠数据管理。2.3 状态机编程思路一个工位一个状态机pack线工位逻辑复杂如果用常规的“置位复位”写法程序会越来越乱。我的做法是每个工位都做一个小型状态机用整数型变量代表步骤号通过CASE指令跳转。比如拧紧工位的状态机步骤号大概长这样Step 0等待托盘到位信号Step 1托盘夹紧Step 2拧紧轴下压到位Step 3拧紧枪就位信号Step 4启动拧紧程序Step 5等待拧紧结果OK/NGStep 6抬起拧紧轴Step 7托盘放松、放行每个Step下面写“进入这个状态需要做什么动作”、“如果动作完成跳转到哪个状态”、“如果超时跳转到报警状态”。这样排查问题就变成一个纯“查状态机”的过程——看当前Step走到哪了没往下走就是上一步的完成信号没来再查具体是传感器问题、执行器问题还是通信问题。这种写法的好处我多说两句第一程序逻辑清晰调试不用从头到尾捋梯形图只需要查状态机的步号。第二维护性好。后面工艺升级比如加一种新的拧紧程序只需要新增一个Step老逻辑不动。第三时序可控。状态机天然把“一步一个动作”的顺序约束住了不会出现两个工位同时动作导致撞机。3. 核心工艺功能的程序实现3.1 托盘输送与工位交互逻辑pack线的托盘输送常见的是倍速链或滚轮线。托盘到位后PLC控制阻挡气缸stopper升起托盘停下然后定位销把托盘锁死工位开始干活。这段逻辑看似简单其实有几个细节值得注意。第一个是托盘到位信号的判断。最好用两个传感器一个预到位慢速进入区一个到位准确停在阻挡器前。程序里要有延时确认逻辑防止托盘刚到边缘时信号闪断造成误判。我一般这样写托盘进入预到位传感器ON开始减速或通知前段工位“不要放行下一个”。托盘到位传感器ON延时500ms后再置位“托盘到位确认”变量。锁紧定位销后才允许工位动作。第二个是“忙/闲”握手信号。相邻两个工位之间建议交换一组IO信号本工位忙Busy、本工位请求放行RequestRelease、下一工位空闲NextIdle。这组握手信号能防止前一个工位还没干完活下一个托盘就怼进来。可以用Profinet IO也可以直接用硬IO看现场距离。第三是安全互锁。如果两个工位有交互动作比如机械手从上一个工位抓料托盘只有在上一工位完全释放的情况下才能移动。这个互锁建议同时做在PLC程序和硬线上——硬线互锁是最后一道保障绝对不能省。3.2 拧紧工位的程序细节pack线里拧紧是很关键的一步。模组固定、Busbar连接、壳体螺栓扭矩和角度都有严格工艺要求。程序里要处理的主要是启动信号、拧紧枪状态反馈、结果读取、数据追溯。以Atlas Copco拧紧控制器为例它跟PLC的通信方式一般是Profinet IO或者现场总线IO控制器会把每个拧紧步骤的结果映射成一组输入信号OK/NG、扭矩值、角度值。PLC这边要做的启动拧紧给控制器一个“拧紧启动”信号同时把当前要执行的拧紧程序编号比如P001、P002发给控制器。等待完成控制器执行完毕反馈“循环完成”和“结果OK/NG”。读取结果把扭矩值、角度值从控制器上传到PLC数据区记录到追溯DB。判定如果NG软件互锁防止托盘流到下一工位。这里有个坑拧紧程序号和扭矩值之间的关系拧紧控制器里存的是“程序号参数”。我遇到过现场工艺员改了一套拧紧参数但PLC发过去的拧紧程序号没改结果所有螺栓都按旧扭矩拧。后来我在HMI上加了“拧紧程序号选择”和“当前扭矩设定值对比”操作工每次换型前要看一眼才彻底解决。另一个坑是拧紧结果超时。有些拧紧程序带反转、带重拧延时比较久。如果PLC的等待超时设太短会把正常拧紧误判为故障。建议超时时间按最长拧紧程序的1.5倍来设宁可在两天后暴露真问题也不要天天误报警。3.3 与ABB变频器及第三方设备的通信处理pack线现场很少只有西门子一家设备。ABB变频器、第三方伺服、检测仪表、机器人混着用。我的经验是能走Profinet就走Profinet通信数据量大、速度快、诊断方便不能走Profinet的用Modbus TCP兜底S7-1500自带的Modbus TCP功能块MB_CLIENT、MB_SERVER很好用。跟ABB变频器走Profinet时需要在博途里装ABB的GSD文件把变频器组态成IO设备。ABB变频器映射过来的数据一般有状态字、输出频率、电流、故障码。PLC那边要做的启动时先给变频器发“使能运行”信号。把给定量写到输出数据区频率用十六位整数表示。实时监控状态字判断变频器是“运行中”“已停止”还是“故障”。ABB变频器的故障码有时候不会直接变成Profinet的标准故障字而是要从映射的“故障代码”寄存器里读。我在HMI里做了一张故障码对照表维修看到“F0002”就知道是过电压不用再去翻变频器手册。第三方设备通信的最大坑是“通信中断后数据不更新”。有的设备回传数据时维持最后一帧数据不变但PLC没判断时间戳。如果PLC只用这个“最后数据”做逻辑比如读扭矩值读到9999这种异常值就会出大问题。稳妥的写法是在通信数据块里放一个“心跳”计数变量对方每100ms加1PLC每循环检查这个心跳是否在跳。心跳超过500ms不变就判定通信超时闭锁相关工位动作弹出报警。我在多个项目里用这个方法效果很稳定。3.4 安全程序与急停逻辑pack线里有人工上下料工位有机器人搬运区安全等级一般要求PLe或者SIL3所以S7-1500F故障安全型是标配或者外部接安全继电器完成硬线安全。如果用的是普通S7-1500安全回路必须靠外部硬接线PLC程序只能做“非安全”级别的互锁。我经历过一个项目机械手区域的安全门没关严由于安全信号直接进了安全继电器机器人被强制停止但PLC这边还认为“安全门关闭”导致输送线继续把托盘送进了机器人区域。这就是典型的“安全与PLC逻辑脱节”问题。正确的做法是安全继电器的输出触点同时给PLC一个“安全回路通”状态输入。PLC里用这个状态去联锁所有相关工位动作任何安全条件不满足相关工位步进电机的使能信号全部切断。程序里任何工位的“启动”条件都必须包含“安全回路通”为ON。另外急停之后复位有个讲究急停复位不是简单“按钮拉起来”就完了。程序里要做“急停复位请求”“复位按钮”“复位确认”三拍逻辑。第一拍急停按钮复位后操作工按下“复位”按钮第二拍HMI弹出提示“请确认所有工位无人、无异常”第三拍操作工再次确认程序才恢复运行。这样可以有效防止误复位导致设备突然动作。S7-1500F的话程序里就要用F-FB比如标准库里的“F_1OO_3”、“F_2OO_3”来做安全逻辑评估安全I/O进F-group故障安全程序单独放在F-runtime group里。调试这种程序需要在TIA Portal里把F-security的密码和版本管理做好这又是一个细致的活儿。4. 调试过程中的痛点与排查方法4.1 Profinet通信断连的排查套路调试中遇到最多的就是Profinet设备突然“红灯闪烁”PLC报IO设备故障。这类问题我建议按下面这个顺序排查先看报故障的是哪个设备。在TIA Portal的“在线诊断”里双击“Profinet IO System”看哪个设备状态异常这个最直接。看物理链路。网线是否松动、水晶头是否氧化、交换机端口是否亮灯正常。pack线现场电磁干扰大有时网线走线跟动力电缆捆在一起通信就容易闪断。看IP和设备名。Profinet设备的IP和Device Name必须和组态一致。很多故障是因为更换设备后新设备没有下载配置导致Device Name对不上。看拓扑。走交换机时检查是否有环路Profinet协议对网络抖动敏感。我用的是SCALANCE X系列交换机网络拓扑尽量做成星型不要在产线上串太多级。最后才考虑IO模块本身故障。比如ET200SP的底座端子接触不良这需要用备件替换确认。这段排查流程从“软件诊断”到“物理检查”效率最高。4.2 程序下载与在线修改的坑S7-1500在线修改程序很方便但也不是随便点。我踩过几次坑之后总结几条经验修改程序前先备份当前项目尤其带配方、带位置轴数据的时候。下载程序时如果CPU在RUN模式并且修改涉及DB新增或删除变量一般会要求“停止CPU”。要提前通知产线操作工把托盘上的料清完设备复位再下载。在线修改时如果弹出“需要复位CPU”一定不要直接复位。先检查CPU的保持性数据格式对不对或者备份当前配方数据否则复位之后配方可能丢。改程序前先离线比较。TIA Portal里可以用“离线/在线比较”把修改前和修改后的逻辑差异看清楚再下载避免把同事改好的逻辑覆盖掉。另外有一段血泪经验不要在产线生产高峰期做在线修改。看起来是“改一个小Timer”但下载瞬间CPU会有几十毫秒的停顿有些设备比如拧紧控制器可能因为通信超时就报故障了整线跟着受影响。宁可停机20分钟也不要在线偷摸改。4.3 报警程序与HMI交互设计pack线的报警设计我强调一点报警信息要“有上下文”而不是简单一句“设备故障”。我习惯的做法是在报警触发时同时保存报警工位号设备名称当前状态机步骤号附加信息比如超时值是10秒、当前值是12.3秒这样维修人员一看HMI的报警行就能知道“S02工位拧紧枪状态机在第4步等了5秒没等到完成信号”比单纯“拧紧枪故障”有用一百倍。报警级别我分三类第一类提示Info比如“托盘到达工位3”不打扰操作只是日志。第二类一般报警Warning比如“气密测试压力未达到设定值”产线可以继续跑但要处理。第三类停机报警Fault比如刚才说的通信中断、安全回路断开、拧紧NG机台立即停止黄灯红灯闪烁报警。HMI上每类报警用不同颜色区分同时有“报警确认”按钮。报警确认我建议设计成第一按确认报警声音关闭第二按复位故障条件已经消除后才允许清掉报警。防的就是操作工手快报警还没处理好就按复位结果设备突然又动作危险。5. 一点学习建议如果你刚接触S7-1500想在pack线这类项目上少走弯路我结合自己的体会给你三个方向第一把TIA Portal用熟。不是只会拖个线圈、置个位而是要会用PLC变量表、用背景DB、用UDT用户自定义数据类型、会用交叉引用查变量。TIA Portal的基本功打不牢后面程序量大起来维护成本翻倍。第二背熟状态机编程思路。pack线工位逻辑的一次次实践说到底就是“状态转移加条件判断”。你可以在自己电脑上装博途仿真用模拟量模拟一个简单托盘输送工位练一个两周状态机的逻辑就通透了。第三多到现场蹲守。程序里最好的学习机会在调试现场。跟着老师傅一起排查一个拧紧枪通信故障比你看十遍说明书都有用。看他们怎么用在线监控、怎么判断硬件和软件的分界点、怎么跟设备厂家沟通这些是书上学不到的。我在做这个pack线项目的过程中最深的体会是PLC程序说到底是服务于工艺的程序结构再漂亮如果不懂电池包工艺写出来的逻辑大概率不好用。反过来如果你对模组上料、拧紧、涂胶、测试这些动作都了如指掌PLC程序对你来说就是把工艺翻译成代码。搞懂工艺再写程序才是最稳的路子。如果你正在做类似的pack线项目遇到具体问题比如某个功能块怎么写、ABB变频器通信数据怎么解析、Profinet掉站怎么查欢迎在评论区交流我看到会回复。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进