S7-1500与S7-1200分布式控制在20轴包膜机中的应用

接到包膜机项目的时候，我先大概看了下设备布局和传动链——20个轴，5段工艺，一条产线从膜卷上料到成品输出超过12米，客户要求用西门子1512做总控，外加5台1214C分布在各工位，配维纶触摸屏，投标时就定了博图V17编程。第一个念头其实是“一台1512全包了不行吗”，但真正把轴控制周期、IO刷新负载、现场布线这些账算清楚之后，我坚定改成了“一主五从”的分布式方案。

这篇文章把这套系统的组态逻辑、通讯规划、程序架构和现场调试里踩过的坑完整捋一遍，既有干货也有教训，适合正在做包装线、多轴设备或者刚接触S7-1500+S7-1200分布式控制的朋友，尤其适合那些被“多PLC通讯”和“轴同步”困扰的工程师。

1. 为什么20个轴要拆成“1主5从”：包膜机的真实负荷分布

1.1 一台包膜机的20个轴都干些什么

很多朋友对“20轴”的第一反应是一堆伺服电机排队转就行了，实际上包膜机的20个轴分得很散：膜卷放卷、张紧辊、送膜牵引、过膜纠偏，这是送膜工段；纵封辊、上下压合、辅送轴，这是纵封工段；横封辊、飞切刀、色标追标辊、毛刷压料，这是横封切刀工段；进料输送、包装输送、剔除机构、推料轴，这是输送理料工段；转盘、开合工位、出料带、堆叠挡板，这是旋转下料工段。

我把它们分给了1台主站和5台从站，每台1214C负责自己工段的4个轴。具体划分如下：

这个分配不是随手拍的。横封和切刀这一组最特殊：它们既要高速连续运动，又要时刻跟着输送线速度走，属于全线的“同步心脏”。我把它们单独放一台1214C，让这一台的扫描周期和运动控制中断不被其他轴的逻辑干扰，实际调试时这个独立工位的价值一下就体现出来了。

1.2 分布式不是炫技：算完刷新周期再选型

有人说一台S7-1512带20个V90伺服绰绰有余，CPU性能摆在那儿。说得没错，但我算的是另一笔账。

博图里每个伺服轴一旦做成工艺对象，就会占用运动控制中断组织块，20个轴全部塞进一个CPU，等于每几个毫秒就要把所有轴的位置环、速度环、状态机全部过一遍。再加上整线逻辑、报警、配方、HMI通讯，OB1的循环周期会被明显拉长。而包膜机横封这个位置，对扫描周期的抖动特别敏感——周期一旦抖动超过几毫秒，封口位置就会漂。

从站独立之后，每台1214C只需要照顾4个轴，它的运动控制中断可以做得比较快，而且不跟主站逻辑抢时间。主站1512只做决策和数据汇总，不直接参与轴的底层刷新，CPU负载更低，逻辑反而更稳定。

分布式也有代价：多5套从站程序、多一份通讯设计、联调时主从关系要理清楚。但如果把20个轴集中在一个柜体里，伺服动力线和编码器反馈线全部从12米设备的两头拉到主柜，电缆成本和施工难度也相当可观。折下来分布式在电气施工上反而省事。

还有一个核心支撑点：S7-1200固件4.0以上支持做“智能IO设备”，也就是一台1214C可以同时是Profinet IO控制器（在本工位管4台V90），又是别人网络里的IO设备（被1512管理）。这个特性让“主从分布式”真正成立，而不是靠PUT/GET那种非实时通讯硬拼。

2. Profinet组态与站点规划的细节：从IP规划到智能IO设备的配置

2.1 一条Profinet总线上的分层网络

我在博图V17里建了一个Profinet网络，通过一台工业交换机组网，把1512、5台1214C、维纶触摸屏、工程师站全部串起来。Profinet走RT模式时用交换机完全没问题，成本比直连更低，排查故障也方便。

地址规划是开工前就定死的，我强烈建议所有多站项目都这么做：

这里有两个容易踩的坑。

第一，Profinet设备名和IP地址是两回事。组态时必须先给设备分配设备名，设备名不匹配，PLC就报“设备不存在”或者“设备名错误”，不管IP通不通都不行。我见过有人把设备名改成“PLC_A#1”，下载时报“设备名无效”，后来才发现Profinet设备名不允许#号，老老实实改成字母加数字。

第二，S7-1200的固件版本直接影响功能。智能IO设备至少要求固件4.0以上，我现场用的4.5。固件太低，传输区数量不够。V90伺服也挂在同一个网络里，每台1214C带4台V90，联网调试时先给每台V90分配设备名和IP，并且单独记一张“伺服地址分配表”。伺服这玩意儿掉线比PLC更频繁，不提前排好地址顺序，现场能找到你想哭。

2.2 S7-1200“既当控制器又当设备”的组态要点

在博图里的操作核心有几步：

1. 在每台1214C的属性里勾选“智能IO设备”，并在传输区里定义数据映射区。
2. 1214C作为本工位的Profinet控制器，去扫描连接自己的4台V90伺服。
3. 回到主站1512的项目视图，把5台1214C拖进Profinet网络，分配设备名并组态为IO设备。

传输区的字节长度要提前算好。我用的是每台从站与主站之间8个字状态上送 + 8个字命令下发。这里的“上送/下发”都要站在主站视角理解：主站输出命令（从站侧是输入），从站输出状态（主站侧是输入）。

传输区在从站侧可以映射到I/Q区、M区或DB块。我建议映射DB块，因为程序里读DB变量有符号名，比直接啃I/Q地址直观得多。每台1214C的智能IO设备传输区数量有限，8个字输入+8个字输出完全够用，后续要扩配方或者报警记录，再补几个字也不难。

还有个容易忽略的点：S7-1200做智能IO设备的同时又是本工位的控制器，过程映像分区（PIP）要合理规划。有次从站里运动控制中断被莫名拉长，伺服在高速时轻微抖动，查到最后是IO刷新区域太宽，伺服输入输出报文和智能IO设备传输区挤在同一个过程映像分区里。建议把V90伺服报文放到OB1中常规读取，传输区单独安排，这样中断周期不会被IO刷新拖住。

3. 主站与从站的“通话协议”：指令区/状态区设计与读写时序

3.1 先定义接口区，再写业务逻辑

主站和从站之间到底是直接访问I/Q地址方便，还是统一接口区合理？我的经验是后者。直接访问I/Q地址写起来少几行，但程序一多就会失控：从站程序改了某个轴的内部逻辑，主站还在按旧地址读数据，联调时根本找不到是谁的问题。

我在这个项目里采用了一套“轴接口”结构，每个从站内部按“模拟一个伺服轴”的思路建模。主站与从站交换的每个字，定义成统一结构体，包含：命令字、目标位置（REAL）、目标速度（REAL）、加减速（REAL）、状态字、当前位置（REAL）、当前速度（REAL）、故障代码（UINT）。

命令字按位定义，这参考了PROFIdrive标准里的STW1/ZSW1设计：

这套结构放在主站全局DB里，例如DB_CMD_TO_SLAVE_1到DB_CMD_TO_SLAVE_5。主站逻辑只需要读写一个UINT命令字和UINT状态字，完全不用关心从站内部怎么实现。车间维修电工看地址对应表也容易理解，哪台从站状态字bit4亮了，就是那台从站有报警。

3.2 命令握手和从站应答：避免重复执行的坑

定义了数据区还不够，还有一个关键问题：数据是周期刷新的。主站下发一个启动命令，从站怎么知道这是“新指令”，而不是上一次没变化的旧值？靠持续置位是不行的——从站会重复执行。

我用的是“翻转位握手”机制。主站每次下发新命令，把命令字的bit6翻转一次（0变1或1变0）。从站检测到bit6变化，就取走目标位置和速度参数，开始执行指令；执行完成后，把状态字bit7也翻转一次作为应答。主站看到应答位跟随自己的刷新位变化，才认为命令执行完成。

实际调试中最容易翻车的地方就在这个握手。有次从站回零命令发了，从站一直不应答，查了很久发现是命令字的“新命令标志”和“轴使能”被我放在了同一个字的两个位上，而主站在下发参数时不小心先把bit0清了一次，命令字没有按预期变化。后来我把所有命令处理改成“先写参数，再写命令字”，命令字永远是最后一个被写的数据，从站只要检测到bit6变化，参数一定已经就位。

完整的发送时序是：按下启动按钮 -> 主站把目标位置、速度、加减速写入命令块 -> 翻转刷新位 -> 从站收到后取参并执行 -> 执行完翻转应答位 -> 主站确认应答 -> 画面显示运行中。每一步都能在监控表里看到，我在维纶屏上专门做了个“通讯监控”页面，把每一站的交换区数据原样显示出来，调试期帮了大忙。

4. 维纶触摸屏同时对接1512和5台1214C的参数处理

4.1 多节点通讯架构：让一块屏同时管6台PLC

维纶触摸屏与西门子S7-1200/1500通讯，EBPro里选择SIEMENS S7-1200/1500以太网驱动，直接用TCP/IP读写PLC数据块。关键约束是S7-1500必须在CPU属性里勾选“允许来自远程对象的PUT/GET通讯访问”，否则触摸屏读不出值。

但这里有个现场需求：一块屏要同时看主站1512的信息，还要能看到每一台1214C的单独状态，怎么设计？

我的做法是在维纶屏上建6个通讯节点：节点0连主站1512，节点1~5分别连五台1214C，每个节点指定各自IP和驱动类型。画面变量通过节点前缀区分，比如变量“主站_DIAG”属于节点0，“从站1_状态字”属于节点1，完全可以在一个画面上完成整线监视。

但多节点方案的坑是通讯负载。屏幕每周期轮询的变量越多，整机响应越慢。6个站点、每站几十个变量，维纶屏CPU和网络负担都不小。我的优化策略是：

• 主站汇总数据区，把5台从站的关键状态（运行/故障/回零完成/当前报警码）全部汇总到主站DB里。
• 主监控画面只读主站汇总区，进入某个工位详细画面时，才去读对应从站的详细数据。

这样屏幕响应速度和通讯稳定性好了很多。另外要记得给每台1214C也打开“允许来自远程对象的PUT/GET通讯访问”，不然HMI读从站时会时不时出现“读取失败”，而PLC之间的Profinet通讯一切正常，这种现象最让人抓狂。

4.2 变量、地址与报警文本的组织方式

我把画面变量分成三类：状态显示类、参数设置类、报警类。

状态显示类直接映射主站汇总DB的状态位、速度、位置；参数设置类存放工艺参数，例如膜长、切刀速度、温度、补偿量，放在主站DB配方区，由HMI读写；报警类是根据从站上送的故障代码，在HMI上查文本库显示中文报警信息。

这里要特别提醒一下EBPro里的地址格式。S7-1200/1500驱动访问DB地址时，要写清楚DB号和字节偏移量，比如DB100.DBD40对应一个REAL变量。最容易搞错的是将S7-300时代的字地址习惯带到S7-1500上：S7-1500的DB寻址基于字节偏移，如果按字地址写，画面数据会整体错位，读出的全是乱数。

报警文本我是这样组织的：每台从站把故障代码（1=伺服报警、2=急停、3=回零超时、4=膜断）上送到状态区的一个UINT位置，主站汇总后放进报警管脚。维纶屏的事件登录根据故障码切换文本，再用LW时间戳记录触发时刻。这套做法比在屏里逐位写报警条件省事得多，后期加新故障码，只需在PLC端和文本库各加一条记录。

调试HMI时有个高频问题需要提一下：在博图里做HMI仿真一切正常，但维纶屏上按钮没反应。多半原因是按钮被设成了“只在本地切换页面”而没有指定PLC位地址，或者按钮对应的是LW本地内存而不是真正的DB/M区地址。另外离线模拟和在线模拟行为不一致，按钮在线模拟正常但下载到屏里没反应，按照“按钮的PLC地址和节点指向 -> PLC的PUT/GET权限 -> 防火墙/网线”这个顺序排查，基本都能定位。

5. 20轴运动控制的程序架构：谁决定、谁执行、谁监视

5.1 轴接口FB：让20个轴长成一个样

20个轴如果每个都单独写逻辑，那是给自己挖坑。我做了一个“轴接口FB”，在每个从站里实例化4次，输入输出完全一致：输入是使能、回零请求、目标位置（REAL）、目标速度（REAL）、加减速（REAL）、报警复位；输出是使能完成、回零完成、到达位置、运行中、故障代码、当前位置、当前速度。

FB内部封装了限位判断、驱动器使能时序、回零流程、故障锁存和复位。之所以要把使能、回零、走位置拆开，是因为V90这类伺服的使能时序很讲究：必须先给使能，等驱动器反馈“使能完成”，再执行回零或绝对定位，否则一使能就可能飞车或者报“跟随误差过大”。

具体时序我用的是以下流程：

1. 从站收到命令字bit0后置位伺服使能。
2. 轮询驱动器状态字，确认使能完成。
3. 如果是回零命令，按“回零速度 -> 零点开关/堵转信号 -> 找零 -> 设置当前位置为零”顺序完成。
4. 如果是绝对定位，先确认回零完成标志，再写目标位置并触发启动位。

FB里的故障锁存我特意设计成“不能自动复位”。故障必须由主站发清除报警命令字才允许复位，而且命令要用脉冲信号持续3秒，保证操作员能看到报警。很多自动复位方案看着省事，实际是安全隐患——设备故障还没处理完就自动恢复，容易出事。

5.2 电子同步与色标追标：封口定位是怎么稳的

包装线上最讲究的莫过于横封和切刀与输送线的同步。输送带速度一变，横封辊和飞刀必须跟着变，否则每个包装袋的封口位置会漂移。我的方案把同步关系做到三层：

第一层，主站采集主输送变频器的实际速度（Profinet读取或模拟量反馈），做平滑滤波后作为“运行线速度参考”广播给所有从站。

第二层，PLC_C中的横封和切刀轴，配合编码器反馈计算主轴线位置，用电子齿轮/凸轮方式与主轴耦合。

第三层，色标传感器检测包装膜上的色标记号，作为追标修正触发点。如果切刀相位和预期差超过一定角度，就进行一次相位修正。

关于相位修正PID我有话想说。最初完全依赖色标信号修正，结果发现设备低速时没问题，高速（每分钟200包以上）时，色标信号从传感器出来到PLC程序处理，再到伺服调整相位，固有的滞后效应被放大。这个滞后在低速只有几毫米误差，高速时就是十几毫米的封口偏移。后来我把修正窗口做成“按当前线速度动态增益”——线速度越快，修正量按比例放大。修正量等于PID输出的基准修正量加前馈补偿（基于当前线速度计算）。改完之后，高速封口位置才算稳定下来。

这段调试的经验教训是：先从“不追标”开始。把色标修正功能关掉，先看纯电子齿轮下的同步精度能不能稳定在一个合理范围。如果纯电子同步误差就大，问题大概率出在主轴位置采样或周期抖动上，这时候调PID修正没有意义。先把纯同步调稳，再逐步加大色标修正力度，否则会陷入“越追越抖”的死循环。

6. 现场调试中的三类磨人问题与我的处理过程

6.1 Profinet掉站排查：从网线到看门狗

这套系统第一次送电联调，最头疼的就是Profinet站点随机掉线。一开始怀疑交换机性能，后来排查才发现问题出在细节上。

第一次掉站，我先把从站1的Profinet连接断开，把笔记本接到交换机上持续Ping 1214C的IP，发现偶发断包。查网线，发现水晶头是自己压的，屏蔽层没有压接到位，重新压头之后断包消失。Profinet排障的第一件事一定是物理层——网线、水晶头、交换机端口指示灯，不要一上来就怀疑配置。

第二次掉站是软件层面。我把设备名从合法的下划线风格改成带特殊符号的名字后，博图下载时报“设备名无效”。Profinet设备名只允许字母、数字、短横线和下划线，不能有#、空格等国标之外的字符。在IO设备属性里重新分配设备名后问题解决。

第三次是看门狗时间。从站偶尔在高压伺服动作时掉线，查下来是网络在某个瞬间处理不过来，IO刷新周期被拉长。我把从站和V90的IO刷新时间从默认16ms调整到32ms，看门狗接受时间放宽到3倍刷新周期，从此再没出现过掉线。这里要强调：Profinet RT不是越快越好，要为整条网络留出余量，过短的刷新周期和看门狗时间会让系统变得脆弱。

6.2 断电重启后的回零互锁与同步再建立

这套设备调试初期最烦人的问题是“随便断一下电，所有位置都得重新回零”。伺服驱动器本身带绝对值编码器，理论上位置不会丢，但整线同步建立在主站计算的虚拟主轴基础上，一旦从站重启，主站和从站之间的同步关系就断了。重新上电后如果直接恢复绝对位置，切刀相位和输送线相位对不上，一启动就切歪。

后来我设计了完整的三层回零策略：

1. 上电后全轴必须先回到“安全位置”，这个阶段只允许手动模式，自动启动按钮被互锁。
2. 自动模式启动条件里加一条“所有参与同步的从站回零完成”，未完成时启动无效。
3. 回零顺序从后往前：先回动力轴（放卷、输送），再回同步轴（横封、切刀），最后确认相位锁定。

回零完成后，主站把“整线自动就绪”标志置位，维纶屏上显示绿色“同步就绪”。这个设计帮我们避免了好几次误操作，客户操作工反馈说：“断电重启之后知道先看那个同步就绪灯，不再盲目按启动。”

6.3 博图版本、许可证与下载兼容的现场规矩

博图项目从出厂到现场难免要调整，但电脑上的版本和现场设备不一致会让下载变得很痛苦。我遇到过博图V17工程被V18打开后提示升级，升级后再用V17就打不开了；也遇到过STEP 7 Basic许可证被其他西门子软件占用，启动时卡在许可检查。

我的习惯是固定一台调试笔记本装博图V17，现场所有PLC下载都用这台电脑，绝不混用。如果启动博图时报“找不到许可证 STEP 7 Basic”，多半是授权被其他软件占用了，重启Automation License Manager服务或重新激活授权即可，不用重装系统。

另外，博图的HMI仿真和维纶屏是两套独立系统。很多人在博图里把PLC程序仿真跑通，以为触摸屏这边也稳了，结果到维纶屏上下载后按钮没反应。博图HMI仿真按钮无反应，往往是因为仿真HMI和PLC仿真没有关联到同一个Profinet网络，或者按钮的IO域没有绑定到真实PLC地址。对现场调试而言，不要依赖仿真，老老实实下载到真实硬件上验证，一次排除一层问题。

最后再分享一个这套项目里我养成的小习惯。我在每台从站的FB里都留了一个调试数据跟踪区，把最近30次命令和对应的应答时间戳全部记录下来，主站通过汇总区上送到维纶屏的“通讯诊断”页面。客户调试或售后远程判断问题时，不用动PLC程序，直接看这个页面就能知道是哪一层链路断了。这个设计本来只是给自己留的后路，后来成了售后和客户操作工都依赖的诊断工具。做类似多PLC项目的同行，建议哪怕多花半天时间，在一开始就把这种诊断接口留好，后面的调试和维护效率会完全不同。